Hi everybody and a good day to you! 

As we entered our last week of our first production sprint, we worked hard on getting the last of our mechanics into the game and we refined more of our character models, and made sure there's more detail in our house.

Art

This week, Gwynne has worked more on making the house. She tried various techniques when making the wall pieces, for example, making it tileable pieces of each 1 meter which nicely fit together. After making those building blocks, and tweaking them quite a few times, she figured this wouldn’t work so well and would take quite some time to place every single block in the correct place. She decided to come up with a different method, which included some calculation, but the placing of the walls would be much easier. She created different wall sizes, for the walls that were in the blockout, for example, walls of 2 meters, walls of 1 meter, 3 meters and more. The calculation was needed to make sure it was not exactly 2 meter, but a little less, so that the door openings would not be too tight. After all of this, she finally had the correct blocks, and were placed at the correct place.

Aside from making the finished house walls, she started modelling the rest of the furniture. The house will have tables now, a big one that functions as the dinner table, and a small table that can be placed in the living room.

Xander mainly focused on making all the RFXS systems which almost completed it all. He made custom textures in Phothoshop and used the FX graph package in unity to make the particle systems. The systems he made are the exorcist movement, ghost movement, salt throw, salt breaking and button smashing. At last he spend some time unwrapping some of his previous models.

Sina firstly watched some tutorials about animation in Blender and how to build them up for Unity. We needed 3 Animations for or Characters: Idle, walk and a walk with object- animation, so she created those as separate 'actions' on the same Rig in Blender. The export to Unity however turned out to be rather difficult, because in her model everything seemed fine, but in unity it did not work. After a lot of troubleshooting, she was not able to fix it completely, so she came up with a backup-solution and exported the animations as separate meshes, which works better.

Programming

As for programming Jentl did the following. The win conditions for both the ghost and exorcists have been implemented, accompanied by a change to the game timer. In addition, significant work has been done to improve the spawning of objects around the map, which has been extended to include a specified number of ritual items. He has also spent time thoroughly testing the game and addressing any issues identified during the process, resulting in a smoother gameplay experience.

Hi everybody, Jef here!

This week has been jam-packed with getting the main gameplay mechanics working and building the final version of the current sprint.

I started the week of with reworking the Grabber and Grabbable scripts. Instead of ray casting for an item, a trigger is used. This fixed the issue of not being able to cast a ray against objects that are really close to / inside the player.

Grabbable script.


Grabber script.

I then went about improving the code base and removing as much dependencies as possible. I reworked the player logic and hierarchy. When a button is pressed on a new input device (keyboard/mouse or controller), a player prefab gets spawned and input gets bonded to the correct device. This new player prefab handles the character selection and player management. When a team is chosen (either via an UI event or an InputAction), the correct character prefab (ghost or exorcist) gets spawned and parented to the managing player prefab. We previously had to bind methods (OnMove, OnItemInteraction, ...) to the corresponding UnityEvent of the PlayerInput component in the inspector. This gets messy and is very bug prone, so to remedy this, all methods get bound via code to their corresponding InputAction. This InputAction is a serialized InputActionReference variable that can be set in the inspector, to easily set the InputAction that triggers the method without having to dive into the script (You are welcome artists).

After this, I split the ButtonMasher script into three scripts: Masher, Mashable and MashableUI. The Masher script is responsible for handling input and player feedback when the player presses the mash button (mash button can be set in the inspector). It has a dependency on a Mashable, this is the Mashable that the player is currently interacting with and can be changed via a method call. The Mashable script is responsible for Starting, keeping track of and finishing the mash event. It fires an appropriate UnityEvent for each of these three states. It has no dependencies. The MashableUI scripts sole responsibility is managing the UI slider showing the mash progress. It has one dependency on the Mashable.

The last bit of game logic added was the Dueler script. This script is responsible for the button mashing duel between the owning exorcist and possessing ghost. When the ghost presses the posses button when in range of an exorcist and their ability off cooldown, the duel will commence. Both players have to mash as fast as possible to fill the opponents mash bar. Whosevers mash bar gets filled first, loses the duel and gets stunned. Ghosts get stunned for longer than exorcists do, this is to increase the risk of them trying to stun.

To wrap up the week (and the first sprint, hooray!) I merged all the development and art scenes into the main scene, which can be played in the latest build attached to this devlog! That’s it for me, later days