GameDev: Reacting to the dangers of Mole Munch
|
Hi! This week, I have been working on making Mole Munch feel more like an actual game by applying consequences to messing up, and a score based on the amount of vegetables the mole has eaten. First and foremost my task was to apply a game over screen which activates when the player collides with either gardener or flooding water. This was all fine and dandy, but by adding consequences to messing up, it became very important that the game treats the player fairly. Look at any game, and you will see that the more ”random damage” a game features, the more forgiving the HP system is. For example, in Super Mario you only have one to three hit points. All dangers are clearly communicated and there are no unavoidable dangers. If you mess up, it’s your fault. Now look at a game like Doom. Here, enemies are shooting at you with instant hit weapons, making it impossible to completely dodge all bullets. Here it is not a question of if you got hit or not, it is a question of how much you got hit. As a result, doom features a percentage HP bar and constant health packs so that you can replendish your health. So what category does Mole Munch fall in? All damage in Mole Munch is clearly telegraphed, but a number of testers (me included) felt that it was very brutal getting killed in just one hit. Especially getting used to the quick water spreading takes a while, and before you get used to the game gardeners seem lightning quick! To mend this, we decided to include an HP system so that players can take multiple hits. It is not as simple as changing a few numbers that represent HP and activating the game over state only when the numbers are at zero, though. In order to implement HP, one also needs to figure out the details. How do we communicate to the player that they have gotten hit? How does the player get out of harms way after getting hit? How is getting hit multiple times in a short time span avoided? How is HP represented? To answer these questions, I turned to a bunch of other games to see how they answered them. I looked at games like Super mario bros, Shovel knight, and old arcade games with multiple hit points in general. In most of these cases, the game has a small cooldown when getting hit where the player flashes from transparent to solid multiple times. During this time, the player is safe from harm, giving them time to get away from harms way and assess the situation. By implementing this, I had the reaction-to-.getting-hit question partly answered! To add an extra little ”oompf!” to the damage reaction, I decided to also try to implement a knockback effect from getting hit. This would propel the player safetely out of the gardeners reach, and also make it even clearer that the player has messed up. With invisibility frames, the flashing effect, and the knockback, the first three questions had been answered. In regards to how to represent HP, I decided to go for an old fasioned HP bar alá Legend Of Zelda at the top of the screen. I mostly just needed to implement HP quickly and figured it was a solid way to do it since so many games before had successfully done it. These kinds of things are what makes a design document so useful. Right now, we are slowly moving beyond our design documents scope, forcing us to design features independently in the midst of crunch. Before this week, we had all features clearly documented, enabling us to focus on implementing them rather than designing them. Ideally we would have a designer go through the features planned for the next milestone and update the design document. No time for that at this stage of the process though! Next week, more polishing, balancing and perhaps a difficulity progression system will be added.. maybe! Thanks for reading! |


