Hello! Thank you for reading the second devlog to Housekeeping Rumble. Once again, I'm Peng Chung the solo developer of this project. By the time this post is released, the game will have released its version 0.5.2.  The prototype build is attached to this dev blog, so have a look if you have the time! 

While the project is still in development, I'm excited to share some updates about the game, as well as a few problems and solutions I've encountered along the way.

Stacking up The Base

As a recap, the game started off as a school assignment to create a beat-em-up game, The objective is to create an iterative build each week, have it playtested, receive feedback and improve on the next one. After version 0.4.0 was released, the assignment is required to have "Roguelite / Rogue-like" as an additional genre. Hence, the game was further built on including randomizing elements.  

Firstly, to implement the randomness of a rogue-lite game, the original level was split into different sections and randomly arranged in each playthrough.  In order to fulfil the premise of the game, which is cleaning the castle, the player's main objective was changed to sweeping off dust on the floor using their wind-based attacks. Players will go from door-to-door after each cleanup and move on to the next section.

While the player can completely ignore enemies after they finish cleaning, there is an incentive for the player to defeat enemies - Defeating enemies will yield the player significant number of Coins, which can be exchanged with a  number of items from the Shop. This Shop chooses 3 random items to display, each with its specific cost and abilities.  Items can also be separated into two categories, Equipment and Curses.  Equipment provides a direct buff to the player upon purchase, while Curses tremendously powers up the player but hinder other parts of their abilities.

(Example of an Equipment , indicated by a green glow.)

(Example of a Curse, indicated by a purple glow.)

Additionally, a hub world is created as a starting point for the player every time they restart the game. Lord Cthulhu and a training dummy resides here, serving as the tutorial area, giving the player more gameplay tips and prefacing the premise of the game. The player can keep hitting on the training dummy to practice their attack moves.

While there are no additional levels and enemies built onto the game, the features and system mentioned above helps to further build up from the existing gameplay base. With these mechanics implemented, tested and debugged, it serves as a solid foundation to easily implement any additional levels, enemies, cleaning tasks, items and abilities in the future, should they fit in the game's premises.

Polishing and Grinding

As with the previous version - Throughout each week, I find friends and classmates to playtest and ask for feedback on each game iteration to improve on further ones.  One of the most significant feedback received (that are gathered from all the iterations thus far) is that the player's attacks and movements still felt unresponsive.

Upon further inspection, it seems that players were pressing attack or movement buttons before the attack frame was completed under a few assumptions: 1) They assumed that they could cancel their attacks at any time. 2) They assumed the attacks frames had already finished when they pressed the button. This puts the player in a high danger risk due to unresponsive controls. The gif below shows the  observation in slow-mo.

(A player tried to press the Dash button (Shift) when it seemed like the character has finished its attack animation, but ultimately failed.)

To remedy the problem, two solutions were introduced.:

1) Attack frames come out and end much sooner - While players are near the end of an attack animation, they can tap any buttons to advance to their next movement/attacks.

2) Implemented Input Buffering.  Input Buffering is typically seen in fighting games - When a player sends an input while the current execution is ongoing, it will simply hold onto that input until said execution is finished. This aids player into executing combos without needing to be frame-perfect. From the player's perception, it will look like the game always reacts to the player's input. The gif below shows the input buffering in slow-mo.

(The player pressed the Dash (Shift) button before the attack animation is finished. Once the attack is done, it is then player dashes out of the enemy.)

Moving Forward

After 3 weeks of development, the assignment has concluded its overview and research on the roguelike / rogue-lite genre. For the next few weeks, the game will see itself implemented with the platformer genre. However, since said genre has already come with the predetermined game design, I have briefly planned out to continue building on more content for the game, which includes:

• More Enemies and Levels
• More Items
• More Cleaning Tasks
• Potential Mini-Boss Level
• Sound Effects

And that's all. Thank you for taking out the time to read such an extensive post. I hope this helps you gain some insights into the development of your own game projects too. All the best!

Best regards, 

Peng Chung <3