Game development Week 6+7 Devlog

This devlog was meant to be done prior to the testing session,  but oh well!

Patrick Work

Most of the changes prior to the testing session involved audio in some way. I've added new sound effects for the player dashing, shooting, and collecting a power-up. For the music, the game switches between two tracks depending on whether you're currently fighting, and the terraria desert themes seemed appropriate for this particular parched looking level. I also added menu music, of which the balatro main theme was placed as a temporary track there. From here, I made sure everything was in place before setting up the itch page for the testing session, and making a build for it (the icon for the itch page, and the blue color scheme).

After the testing session, I made several changes based on the feedback given. Firstly, the power-ups spawned have less of a delay before you can pick them up, as some people were confused and initially thought they were uninteractable. There were a few fixes to be made for the audio tracks, such as when the player respawns, and when they switch to the menu. There was another issue in which switching to the menu from the level and attempting to play the game again would incorrectly load the cutscene, which was fixed by resetting the time scale for the game. Another issue based on feedback, was that the key doors were somewhat hard to visualize, as the keys were imbedded onto the doors, but the doors were viewed from above. I changed them to display the key on top of the door so its easier to figure out.

The tutorial and player dialogue was also slightly modified to better indicate what was being mentioned and avoid vagueness (telling the player they can hold mouse to shoot, for example). And per a feedback request, shift was also added as a dash button, as it would go otherwise unused.

Finally, I changed the menu music to be the terraria space theme, as it seemed fitting for the game's theme and Kler's menu artwork. The references and links to the tracks are on the game's main page.

Liam Work

Most of the changes I have made were based on feedback given during the testing sessions and bugs we discovered while testing our game. Some of the feedback mentioned that the mosquito enemy should have an indicator or some kind of tell before its attack. An indicator would make it easier to know when it is about to attack, as without it, the player has to time their attacks, which can be too much to keep in mind. So, I made it so the enemy glows for about one second before attacking. This makes it much easier to predict than relying on timing alone.

The other change was to fix a bug that wasn't game-breaking but could ruin the player experience. As seen in the GIF, sometimes the mosquito enemy would just float when it performs its attack. It would return to normal after hitting a wall or the player, but the issue would repeat during the next attack. This was a difficult bug to pinpoint where it could be happening in the script. 

The change I made doesn’t fully fix the bug, but now the enemy will eventually charge if it has been floating for a bit and will perform the next attack normally. However, the following attack may result in floating again. From what I’ve observed, the bug seems to occur when the enemy has been active for a while, so it somewhat relies on the player finishing the room quickly before the bug appears.

When I was implementing the bounce-off-wall behavior for the mosquito, I had forgotten to reset a variable to false after the wall bounce. This prevented the direction from being recalibrated for the next charge. Although the issue is still present, it seems to occur less often or only after the enemy has been active for an extended time.

Kler's Work

Bug Fixing(Fun)

The image is now explainable, and bullets no longer phase through enemies — this was resolved by stretching the collider to ensure proper collision detection.

I added an invincibility feature to make testing and marking the game easier, allowing the player to avoid taking damage during evaluation.

I fixed the mosquito problem by freezing the Y value in Rigidbody3D, which prevents it from drifting into space, especially during dashes. I also made it pause briefly before dashing to disable the player-following behavior, because when it tries to follow the player while dashing, it causes stuttering or hesitation.(still buggy)

Ending of the game, UI.

I implemented the end-of-game UI, which displays the game credits once the player finishes the game. It serves as a conclusion and acknowledges the people involved in the game's development.

James - 

This week, I got to showcase our game at the UTAS Capstone Project Expo. It was very impressive to see everything that each of the teams had worked on. Seeing the level of quality of the capstone projects showed me the level of quality that is expected of us next year once we start our own capstone projects. I also loved seeing lots of people coming to our area and getting the chance to play our game, and what people outside of the KIT207 unit thought of our game