Action, Adventure


1 Player


4 Weeks of Production, 2020


12 Developers

Game Description

On their way to baseball practice, a father and child stumbles upon a massive, alien, robot-invasion.


In a valiant attempt to save his child, the father gets abducted by the evil robots, the Dodgeballians. With their trusty baseball bat in hand, it is now up to The Kid to fight their way through town to save both humanity and their dad!

The game became a finalist in the Rookie Awards 2020 (Game of the Year - Console & PC).

My Responsibilities

User Experience & Interface: I took responsibility for the UX in the game which included all UI, affordance, and mechanical feedback (rumble, flashing when damaged, camera shake, and more).


Visual UI Scripting (UE Blueprints): Along with planning the UI I was also responsible for building it. I reused the menu script from Robotage and improved it.

What am I most proud of?

I personally think the feedback, effects and overall feeling of the game was the best part of the game and I believe that our focus on UX and that sense of smoothness contributed greatly to the overall quality of the game.

Swing Mechanic

The swing mechanic was the star of our gameplay, and so we made sure to focus on it. Our goal: strong and satisfying strikes. Before nailing down the swing mechanic, we decided to try different functionalities:


Manual Aim

Automatic Aim

Semi-auto Aim

  1. The swing shoots incoming balls exactly where the player is aiming. After playtesting we noticed that this made the game too difficult, especially with movement and dodging in mind.

  2. The swing automatically aims at the closest target. We soon noticed that for our game, this felt a bit unsatisfactory and gave the player a sense of lack of control.

  3. We decided to combine these ideas. When the player swings their bat, the ball will find the best target closest to where the player is aiming.

Taking Damage

After taking damage, the player is invulnerable for a few seconds before they can take more damage. We visualize this with spatial UI, the player flashes in red for the duration of the invincibility.

We found a few problems with the health bar. The player was so immersed in the gameplay that it was hard to see it unless we had the health bar displayed around the character. Yet, if too large it would block the player’s view of incoming projectiles.

To solve these problems, I firstly made sure that to keep the health indicator hidden whenever the player was not in combat or when the player already had full health.


I also tried out several types of health indicators before settling on life hearts. I believe that they, in our case, more clearly show how much damage the player can and has taken.


Taking Damage


Back to normal


The playtesters also proved this in the playtesting sessions. By trying different shapes, we were able to adapt our design to whatever gave the best results.

Many testers told us that the original health bar was a bit difficult to read. It was hard to tell exactly how many hits you could take before dying.

Some testers would also mistake the green progress bar for stamina instead of health. We tried red but it would too easily blend into the warm colors of the environment.

By combining the fixed heart shapes with a less vibrant but still contrasting green color, we were able to achieve the best results and solve our problems.

The Main Menu

The main and pause menu are variations of the menu created for Robotage. It is compatible with keyboard, mouse, and gamepad and it features sub-menus like instructions, options and credits.

We struggled with adding certain parts, like the save system and the visuals, which lead to the menu feeling a bit incomplete. I believe we could have avoided this issue with better planning and art direction.


Something like a flowchart for the navigation as well as keywords or key art for the UI would have helped us a lot as well. It would have saved us a lot of time.


Tracking: The spectating developer took notes while siting alongside the playtester, occasional recording of the playtest, and a short survey after the session.

Playtesting Build: The playtesters played through each session with the latest build of the game and we built at least twice a week.

UX Research: Playtesting Plan

Goal: As mentioned before, we focused a lot on the swing mechanic. Our biggest playtesting goal was to get player feedback on how we could perfect the feature.

Playtesting Type: Unguided playtesting alongside a quietly spectating game developer. On occasion we also recorded the session to be able to go back and analyse the material.

The Playtester: A mix of both experienced and inexperienced gamers and game developers to get a bigger variety of feedback.


We tended to focus on teenagers and young adults because of the game’s playful and fast paced theme. We also tried to get as many new players as possible to get more clean impressions of the overall design.

Playtesting Results

Along with learning what we could improve about the game, the scheduled tests also allowed us to obtain a deeper understanding of player behaviour and psychology.

We also improved our ability to recognize good feedback (factual and statistic) versus personal opinions, and in that case our ability to understand the root cause behind certain opinions.

Please see the previous sections to read more about the details of the feedback received, and how we decided to adapt our design!