2024 Game Maker's Toolkit Game Jam

Happybara credits screen. Credits for Happybara: Programming (TeckHybrid, Aadithya Pradeep, Domochico), Character Design (MeyMey), UX/UI Design (Destructionaut (Duffy Austin)), Music & Sound Design (JohnL, Yaoyang Liu). Logo by me.

I took part in the Game Maker’s Toolkit 2024 Game Jam this past week, and it was a unique experience creating a viable product over 4 days. This was my first time working on a team of this size for this kind of project, and it gave me a new perspective and appreciation for teamwork and communication. Our submission, Happybara, can be played here.

The initial design of the game (left) and the final product (right).

Our biggest focus was ensuring that we managed our scope. A lot of us were first-time designers and developers for a game, so we had high hopes but little perspective on the amount of work that goes into creating a minimally viable product. From my experience, I know that ideas are only as good as your ability to execute them. I was lucky enough to work with Kevin Barney, an experienced development team manager, who also had this perspective.

We both came into this game jam to gain experience. While winning a game jam would be excellent, I just wanted to put my skills to the test and make something with a team!

Our team of 6 (later 7!) began brainstorming how to express the prompt. We discussed ideas involving construction, giant robots, and wrestling. Our artist felt most comfortable drawing cute and organic things, which guided us to ultimately go with an interpretation of the theme as [development of a character over time as they deal with anxiety.]

This phase was important for our project because it introduced a major theme: scope creep. A lot of the team hadn’t worked on a project like this before, so they had lofty ambitions for what we were capable of. Kevin and I were quick to point out that our goal should be to create a solid product; we can only run after we learn how to walk.

We had 3 developers, two sound designers, one character and environment designer, and one UX/UI designer (myself), all across the globe in different time zones; communication was key to ensuring we had a viable product. I impress this upon everyone I work with: oversharing is good to do in these working arrangements. It's best to know everyone’s limitations in skill or scheduling to better allocate time and energy. No one is going to worry you aren’t pulling your weight if you need help.

As we discussed ideas, my role as the UX designer was to identify how the user would interact with the game and how it would meet their needs: 

• How did our idea interpret the theme: “built to scale”? 

• What would the player’s goal be?

  • How would they accomplish this goal?

  • What would be the things that stopped them?

• How do you win (if there’s even a win state at all)?

• How do you fail (is there even a fail state)?

• What is the player going to see at any given time?

• What is the most critical information they need to know to understand the system?

This was an ongoing job as we each worked on our components to develop the game; each time we touched base, we got a clearer look at what each person’s vision for the final product was and asked more questions to better define the user’s experience. 

This got me mocking up different menus and screens:

Mockups of different menus and screens.

If I had more time, I would have created storyboards, user flows and/or journeys to break down what the different phases of the experience would be. This could help define things earlier on.

A user flow made in hindsight to show how a user might move through the game

We decided to make a movement puzzle game where you move your avatar around the map to protect the memories of the person whose mind you were in. Negative emotions would try to corrupt memories, and you’d bounce them back out of the arena, defeating them. 

The key info for the user would be what world and wave they were on and how many enemies remained. Below are the mockups I made for this. The fraction representation was more within the technical skills of our team, so we went with that. I was careful not to include too much numerical clutter on the screen so there was less strain on the user when under pressure playing the game.

Mockups of different variations on the HUD. The last image shows a variation on the dash cooldown visual cue that we ultimately didn't go with.

It was great working with such a motivated group of people, as it helped keep everyone engaged and on-task despite the time difference between our different team members. We had to be vigilant to keep scope creep in check, though, as that motivation also meant that we could anticipate being able to get more done than we actually could. Both Kevin and I made sure to voice this frequently to ensure that we had a solid foundation for anything that could be added on later, even after the completion of the game jam. Striving for more is a great thing to want, but it shouldn’t come to the detriment of quality.

Because of the fast pace of the game jam, several choices had to be made by the dev team that couldn’t be undone quickly by the submission time. To display scale, we have the player avatar and later the arena grows to reflect an increase in the character’s confidence. Some of the devs thought this wasn’t clear, so they added a “Confidence” bar on the left-hand side of the screen. I thought this was redundant given the abstract nature of the design, but was told that it would be too difficult to remove in the allotted time. 

The final in-game HUD. I don't think the Confidence bar on the left side of the screen adds anything to the user experience and can be jarring, but there wasn't enough time to remove it when this was brought up. Different HUD elements, including a visual cue for how confident the player avatar is, would be tested through A/B testing to see which is the most pleasing.

I compromised with its inclusion because it did nothing to detract from the final design, and it’s more important to deliver a functioning product than one that looks good. In the future, I want to make sure that communication with the dev team is open so that we can avoid something like this, and impress upon them that we don’t want to overload the user with feedback, especially in products that require a fast pace. This is where the additional sketches, user flow and journey map would come in handy.

With more time, I think that a more unified vision could have been established with more sketches, storyboards, a user flow, and a journey map. These could have better solidified the gameplay loop and UI from the start so that we could avoid unnecessary features, and better anticipate what assets we’d need during development.

As we neared the deadline, I sought out other ways to contribute to the product; we didn’t have enough time to source playtesters, so I spent my evenings going through builds of the game and recording bugs and gameplay issues in Trello for the dev team to address when they were active on the project. I noticed bugs like enemies not being vulnerable to attack when they entered the game arena. When I attacked as they crossed the threshold, my avatar would pass through them and would be propelled into the arena as I bounced off the boundary. There were other bugs as well as the game not progressing when all enemies were defeated, and the memories that needed protection spawning right next to where the enemies entered the map, making the game unwinnable.

I tracked bugs and gameplay issues in Trello, along with other tasks and responsibilities.

I also noticed quality-of-life issues like the camera was zoomed in too much so the player couldn’t see where enemies were approaching from and the memories that needed protection would go out of frame so the player wouldn’t know when they were in danger or how they might fail if a memory is destroyed off screen. We weren’t able to address all these bugs or quality-of-life issues, but I was able to make a record of them, and we could address them in a later build after the game jam.

Ideally, I would have liked to gather a small pool of testers from outside the team to perform A/B testing for the different designs, and perform a usability study where I could observe and report on how the different choices did with the playtesters. 

On top of that, I designed the logo and gathered screenshots for the itch.io page.

With the game jam over, I’m satisfied with the work I did in UX/UI and working with an international team. I learned to take the initiative to impress on my teammates what’s important for good UX/UI, learned to manage the scope and scale of a project, and to plan ahead during different phases of the project to be able to properly test to gain better insight during a short period of time. I want to take these skills with me into future game jams, hackathons and in my professional career.

If you have any questions or want to learn more about my UX/UI design process, don't hesitate to reach out through my website or LinkedIn!