Thanks to feedback from our sessions with Katharik and Elias, we had decided to refactor parts of our game. Two important parts we discussed were an update to the Tool HUD, as we received the feedback that the feedback when switching tools seemed unclear. For that reason, instead of one button used to swap between the two, we decided to map two buttons to both of our respective tools. One of our programmers, Koren, created a mockup of how it could alternatively work, and our current HUD uses that design as its basis. Additionally, we received feedback that our Knitting Needle being grid-locked and our Yarn Trap not being grid-locked felt dissonant, so we decided to try out an alternative method of deploying Yarn Traps.

Besides the redesign for the Tool HUD, we also needed indicators for how many tools were currently deployed. 3 Yarn Traps and 1 Knitting Needle can be deployed at a time, and we needed a way to convey that to the player (alongside with how many are currently deployed). For this, we added an inventory indicator on the side to show how many items are currently being used. However, because this sprint was shorter than our usual ones (due to the need to conduct playtesting sessions), there is a known bug in which enemies destroying the Yarn Traps would not properly reflect in the UI. The bug does not affect the functionality of the mechanic itself, and has been fixed at the time of writing.

For the Yarn Trap, we decided to try out having the Yarn Trap autocomplete itself when you place it down, rather than for the player to place down both ends of the Yarn trap. This would help the problem of it feeling dissonant to the Knitting Needle, but may change depending on the feedback we get from the playtests and our design intentions.

In terms of other edits we changed from feedback, we did things like lock the Y-axis of the Knitting Needle, made it so guards stop moving after being eliminated by the Yarn Trap, have the camera pan to the goal area, fixed the aspect ratio of the UI, and many other minor but relevant changes to our game’s polish. By eliminating edge-cases and confusing parts of our game’s presentation, it allows players to fully focus on the experience and provide feedback on that. 

For our playtest, we also got our polished level in the game. This will help us showcase the mechanics in an appropriate environment and test out the design itself, hopefully detecting any loopholes and quantifying the enjoyment of puzzle solving with our mechanics.

There were a few bugs that we encountered so far during playtesting, most of which were from the new Tool HUD. As of writing, all of the main ones that we encountered have been fixed, but playtesting was very helpful in both finding these bugs and other gameplay-related problems that we should consider. For example, our players reported being frustrated with the player movement speed, and we have decided to both increase the speed a little and also change the size of the map to leave less “dead” time between the player getting to the actionable parts of the map. 

This week, we conducted playtests for our game and had players fill out surveys to analyze their enjoyment of the game and their opinions on the different aspects of our gameplay, which will help us decide the next steps in any changes or game direction for the rest of our game. Overall, this sprint has given our game a lot of polish and has pushed us forward in the right direction, as getting to finally see our game fully come together has helped solidify our image of our game while being able to get valuable feedback on its current state.