Paws of Fury

Paws of Fury was a submission project for a one-week game jam that I led comprised of talent that I met through other online projects, co-workers, and Discord communities. Our objective was to deliver a playable prototype that could also be used to socialize and test the gameplay loop for future iterations. In this 2D  player versus player (PvP) game, two players individually roll and bounce a circular cat or dog while collecting healing, damaging, and mobility items to take out their opponent’s lives.
Submission for Design Buddies’ first game jam
Qualitative research, rapid prototyping, UX/UI Design, game development
December 16 - December 24, 2020
Project Lead
- Managed a team of four (two developers, one character/environment artist, one UI designer); delegated project responsibilities and addressed roadblocks

- Coordinated daily stand-ups to keep the team on track with in-scope necessities for the MVP deliverable

- Developed the game’s framework in GameMaker Studio 2 for features such as player physics and item behaviors

- Designed the player’s end-to-end game flow to define all necessary player functions within each room and reduce
scope creep for future ideas

- Collaborated closely with the artist and UI designer to define the game’s look and feel for consistency among all the visual components
Our first focus was quickly defining and polishing the gameplay loop in the allotted game jam timeframe. There was also a requirement for the game to fall in the theme of “community”. Key decisions in shaping our roadmap included:

- PvP focused so we could take the time to fully refine one core aspect of the game

- Local mulitplayer with controls that were compatible with cloud gaming applications to be played during the covid pandemic lockdown

- Inclusion of some RNG elements specifically within the item spawning to keep the loop refreshing while encouraging a casual approach to the game

- Use of rolling physics as the ‘quirk’ factor in the game to introduce a level of mastery and challenge to the otherwise cookie cutter PvP concept
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
Coding Crunch
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
Art Direction
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.
One obstacle I came across early in my UX career was the challenge of designing around technical constraints.
I set out on this project with a personal goal of using this game jam as a learning opportunity to dive as deep as I could with object oriented programming to help me work with game developers in the future.

After the game jam ended, I also reached out to peers for external player feedback if we ever wanted to pursue this project further:
- Item silhouettes could use a vertically rising level of opacity/transparency to visually show the exact moment at which it would be attainable. This would reduce the cognitive load for players so they wouldn’t need to mentally time when the item becomes fully spawned.
- Migrating over to Unity, where we could add more features such as unlockable cosmetics that could be tied to the player’s account
- Increase the number of players
- Adjust room/character model size and add a variety of rooms. too hard to jump through the space between platforms
- Improve collision knockback so upon collision, the game gives a boosted player more advantage against a non-boosted player
- Playable on mobile
- Based on the qualitative responses we received, the general unspoken consensus seemed to be that as a result of us creating a fast and replayable experience, players wanted the ability to “pick up and play” while hanging out or socializing with friends without the need to commit long hours at a time
- Although not stated during any feedback, I would also want to revise some of our UI to be more accessible. We experimented with a tool that converted hand-drawn lettering into text, but this proved to have some severe limitations in flexibility when implementing across our various game screens

Being in a position to directly affect the development was extremely rewarding and allowed me to apply a user-focused mindset to shape the game’s execution and quickly test changes.