Don't Be Trashy.
You play as Danny Dregs, a down-on-his-luck ex-convict who is trying to make his way to meet his probation officer. Unfortunately, you have an overactive metabolism, and needs to consume food for energy. Some foods, though, produce garbage that you have to carry along until you find a bin. Be careful - if you litter, the police will come after you!
Garbage Daze was developed in a multidisciplinary team of five for a Game Design module in the Centre for Digital Media. I was the developer as well as level designer. In this small team, we brainstormed and made many decisions as a unit, chipping in with our varied backgrounds and experiences.
Two months. That was the time limit we were given to conceptualize a game and produce a playable vertical slice for a mid-level stage. The fun factor was the most important thing we had to consider, and we had to ensure that the game had intuitive controls, strong affordances and good balancing of difficulty.
We made use of quick-to-produce, physical prototypes to test the core mechanics of the game. The visuals of the game were definitely not great at this point (looked kind of shabby, actually), but it allowed us to visualize the mechanics, and test that the core loop was actually fun. After getting people to try the prototypes, we were able to rapidly change them and conduct further tests to solidify the concept - all before any time-consuming coding or asset creation was done.
Minimum Viable Product (MVP) & Early Level Design
When we were sure of what we wanted, I coded a simple grey-box side-scrolling prototype. We stuck to minimal graphics and put the emphasis on testing whether players understood the different elements in the game, and observed how they interacted with the prototype.
To help us design the initial level, an interest curve was plotted to visualize how we could gradually build up players' interest in the game. Using this curve, I designed the placement of the items and walls, and later refined the level based on players' predicted behaviours (learnt through playtesting). I wanted the users to learn specific strategies inherent in the mechanics through experiencing the impact of their actions. For example, attempting an easier route would result in the player collecting too many of the red circles, increasing their avatar's size and preventing them from passing through narrow gaps.
Increasing Fidelity and Features
While the mechanics and level design were being iteratively improved on, the artists were not just sitting on their hands. An 8-bit-like nostalgic style was decided, and original art, animation and music were created to replace the grey boxing in the early prototypes. I worked tightly with the artists to import these assets. Replacing the square shape of the early avatar with the irregular shape of the character produced some unexpected problems with collision detection, and I adjusted the code to produce a smoother gameplay experience. Optimization of both the graphics and the code was also key at this point to ensure that the loading and generation of the assets in-game did not slow it down.
We brought our fancier-looking prototype for a test drive. We received compliments about the art, but observed that players frequently got frustrated when they were stuck at points in the game when the size of their avatar grew so much that they could not proceed forward or backward, and were forced to restart the game.
Thus, we introduced a new mechanic, littering, that would reduce their avatar's size and allow them to move on. We decided that the action needed to produce a consequence, and we came up with the idea that littering would cause a police helicopter to chase after the player for a short period of time. Interestingly, this became one of the most popular features of the game, as players were thrilled by the chase.
A-B testing was also carried out to simplify and tighten the mechanics, such as using two versions of the game to test whether the presence or absence of an energy and time bar changed their experience of the game. We found out that many players ignored the time bar, and were confused when they ran out of time and lost the game, so we removed that feature.
The final step in the process was to improve the game's balancing, and to improve on our affordances.
Garbage Daze was aimed both at players who had a huge amount of experience in platformers, as well as those who played them less often. We had to offer sufficient challenge for the experienced players, while not frustrating casual gamers. We playtested with people with varying levels of gaming experiences. By observing their rate of successfully beating the game, we adjusted the difficulty through changing game parameters such as speed, jump height, and levels of garbage generated from the in-game items.
To better teach the mechanics to the players intuitively, we introduced design features that implied what each element in the game did. For example, we made the bin's lid open when the player went near it, indicating that they could throw their garbage there. We also coloured the energy bar with a gradient, giving a sense of danger at low energy levels. Finally, we used fruits vs bottles/newspapers to differentiate between items that did not generate garbage, and items that did. A floating indicator appears when an item is collected, signifying its energy and garbage level. With these affordances, players were able to understand the game without any text instruction.
What I have learnt
Through this project, I learnt the importance of playtesting during game design. Being so involved in the process, and constantly testing the game myself, there is the danger of underestimating its difficulty, since as I already know the level and strategies inside-out. Observing how players interact with the game, however, can uncover new opportunities in making it more fun, and quickly surface areas that need improvement, particularly points that confuse or frustrate the players.
The strategy of low-fidelity and rapid prototyping was effective in this project in ensuring the viability and entertainment value of the game before going into production. If we had not conducted user tests early on to support the process, more effort might have been spent re-doing assets and adapting code if we only found out later that we had to make massive changes to the game.