Deciding an Engine
Although none of us had prior experience with the tool, we decided to use GameMaker Studio 2 (GMS2) for this project. Unreal Engine 4’s robust 3D features weren’t needed and there seemed to be more resources online with GMS2 over the Paper 2D system. We considered Unity since the developers both had C# experience, but ultimately decided that GMS2’s proprietary language was intuitive enough to pick up that it allowed for quick, iterative experimentation.
Coding and Prototyping
After hours of YouTube tutorials, I did a simple blockout of the room collision and began working on the player movement. The rolling velocity would be a healthy challenge that was just a matter of adjusting parameters once the initial framework was set up after learning some principles from Asteroid tutorials (acceleration and deceleration). Getting the bounce velocity proved to be more difficult since there were more behaviors to consider, such as the speed and angle of which objects collided and the type of colliding objects (player or wall). Watching a few Pong tutorials really helped shape up the bounce angles upon collision. We internally tested the movement and continued refining until the parameters land on a sweet spot where it wasn’t frustrating to the individual player to control but allowed the movement to add a layer of challenge where the player couldn't simply start and stop their character on a dime.
Item & Player Behavior
The game consists of three item types that are triggered or collected upon contact:
Treats - heal yourself for one life
Yeet Feet - boosts your next jump
Kachow - damages your opponent for one life
We quickly realized that spawning items freely posed a few problems such as constantly being able to heal incoming damage if treats spawned too frequently. The spawning mechanic also heavily affected the ‘meta’ of how aggressive or passive players approached the game. We decided upon a soft hierarchy that gave top priority for Kachow, the damaging item, as it was the one-way ticket to winning the game. To drive the importance of Kachows, this item would spawn infrequently compared to Yeet Feet, the boost utility, so players had time to collect boosts and prepare to contest Kachows when they did appear. We completed the end-to-end game experience with two days to spare, giving ourselves time to play against each other via Parsec (cloud gaming) and iterate on the item mechanics:
- Treats should only spawn when at least one player is hurt. This meant that if one player is still at full health, there was a decision to be made on whether they wanted to guard the treat or go for a Kachow that could potentially spawn at the same time
- Treats despawned after a few seconds to create a sense of urgency
- Yeet Feet, which gave a boost to the player’s jump, would always spawn within jumping distance while the other two items could spawn further away. This required the player to prioritize Yeet Feet as a key utility in order to gain an advantage over their opponent
- Treats would first spawn as a black, untouchable silhouette so players could start contesting or plan their strategy. This also removed the random chance that an item could spawn on top of a player who would be instantly rewarded
We grounded our visual thematics around three synonyms: bubbly, energetic, and playful. I worked closely with the artist to review artboards for the all the background art as well as item and character designs to be colorful while retaining readability among all the art assets. GMS2’s sprite system made it convenient to import her initial sketches to test within our prototype early on where we ensured that the objects all matched their sketches’ sizes and collision boxes. We also explored different flat and shaded art styles as well as vector or hand drawn assets. We landed on a flat hand drawn style that was doable in our time constraint while keeping the uniqueness that came with hand drawn designs.
I used Figma in our first meeting to quickly sketch out the room for the main gameplay to align all team members on the vision. I kept the information architecture as simple as possible, checking that the player would never run into any ‘dead end’ scenarios. I made a list of different groupings to show all the necessary UI and HUD elements within each screen and created a Trello board to keep track of our collaborative efforts (e.g the background splash art should properly frame the main menu UI). Fortunately, we all had agile experience and were comfortable with the idea of “failing faster” to reach our desired outcome with each step. Menus were designed with the intent to be fully navigable with just the keyboard, an accessibility decision made to accommodate for cloud gaming where multiple mouse inputs would conflict with one another.