The Mechanics

More about Bound.

I'm designing Bound as a first person walking simulator in Unity 2018. The player character is a transman, home from college for fall break. Desperate to get in decent shape, he's taken a trip back to his middle school to go jogging on their public track. Unfortunately, he's made the unhealthy decision to do this in a binder. The experience that I'm trying to replicate is divided into two parts: the introduction where the player navigates the character to the track and gets situational context through narration, and then a strenuous, key smashing mini-game while the character is actually running. My goal is to recreate the physical and mental stress that running in a binder causes through this mini-game. No matter how well the player performs, the game still concludes with the character passing out.

Building the mini-game.

Because the core of Bound is the running portion, I decided to dedicate my first week of development to whiteboxing it. As I move forward with this project, it's important to me that I'm representing a transgender experience as accurately and genuinely as possible. Spending extra time refining this mini-game will help me achieve that.

What's the premise?

The player must manage three different meters; speed, oxygen, and consciousness. The faster the character is running, the more quickly they run out of oxygen, and also the more quickly they begin to feel light headed. The game prompts the player with keys to press to maintain a steady pace and keys to press to take a deep breath. It's up to the player to press the correct keys as fast as they can, to keep the character conscious for as long as possible. It's important to note, there are no plans to give any sort of incentive for players to play again and see if they can "last longer" for a "higher score." That would send the wrong message and detract from the experience.

Why key smashing?

With the development time that I've allotted, I know that my feasible target platform is PC. This means that for player input, I'm constrained to a keyboard. Key smashing is the most physical activity that you can do with that input device. I thought that this would effectively communicate the feeling of running or physical activity to the player. 

The evolution.

This is what the original whitebox looked like. The pace keys were "W," "E," and "R" while the breathe keys were "B," "N," and "M." What was wrong here? Well, those keys aren't exactly intuitive. It would be ridiculous for me to assume that players have memorized all of the specific key locations on a keyboard. Not only that, but the key prompts were much too far away from the meters. The prompts require all of the players attention, affording them almost no time to notice the levels of each meter.

The next iteration was much more successful in terms of information accessibility. The player's focus is drawn directly to the center of the screen. The proximity of the key prompts and the meters makes it so the players know how they're performing. The color of the meters help differentiate them and associate them with what they are meant to represent. The pace and breathe keys had also been changed to the "WASD" and arrow keys, the most common control scheme used for movement in computer games. This meant that their locations are far more familiar. There was still one issue, though. The placement of the pace and breathe prompts were opposite of where a player would put their hands on the keyboard.

The current whitebox was amended to reflect the physical layout of the input device. Overall, this decreased the difficulty of the mini-game because players no longer had to account for the inverted mapping of the prompts.