About [PRESSURE]

[PRESSURE] was made as a true creative outlet; the first time I’ve used games to get something off my chest and out of my head.

It was made during a stressful month. As usual, I had let work and responsibilities pile up, each delayed no more than practical, until they formed a collective tower threatening to collapse and crush me like a roach. I would spend a day worrying about my commitments and spend the night regretting how much more work I could have accomplished if I didn’t worry so much.

On a sleepless Thursday (in Seattle, hyuk), half-in and half-out of the sheets, counting more precious sleep-hours drifting away, I decided what to do. The half-formed idea that had been bouncing around my unconscious came fully to the forefront: I would make a game about walking forward while being crushed. It would be unwinnable and as annoying as possible. I moved to the couch, opened my laptop, hunched over and began coding. My goal: to create a game that would induce a state of panic and convey exactly what I felt at that moment.

By morning I had the man walking and the red wall descending. By the end of the day I had him getting crushed and the basic input, a prompt to hold and release alphabetic keys, escalating in number required at a time. Here I ran into my first problem: modern keyboards can only reliably accept two input keys at a time. Because many keys are wired with the same switch, and this wiring varies between manufacturers and models, I was forced to limit the number of alpha keys. This was not enough escalation to induce a state of panic.

It led to a better solution: I added arrow keys as a secondary mechanic. Now, asking the player to both hold letter keys and press a series of arrow keys got into a pat-tummy-rub-head scenario that is tangentially similar – it’s off-putting in a way that would be helpful to my experiential goals. I had to go further.

The detachable head was a shower idea. It fits the scenario, mechanically, it’s a different type of input, and it adds a bit of humor and surprise.

Playtesting taught me a few things: not all of the mechanics were as self-explanatory as I had hoped, and players were more stubborn than I had anticipated.

The letter keys worked very well. With obvious and immediate feedback, and no other distractions, everybody picks up the first mechanic quickly. The game is effectively paused until the player proves they can hold a letter key. The arrow mechanic is more difficult, but it was eased along because the player already understands the feedback for success and the arrows disappear immediately. Originally, screwing up arrow input made the wall drop faster. However, players were able to mash the arrow keys, not entirely understand why it worked, and just work through a suddenly-red-game. The head mechanic proved the most difficult to teach. The player is required to hold Space when the head is within arms’ reach, and not let go of the head until they are forced to by a stepping forward (a success). This is made more difficult because players tend to let go of Space at the same time as they let go of the letter keys. I had to add a delay to the head release (which will bar success) that was long enough that a near-simultaneous release would still be successful, while still being immediate enough that a player sees that letting go of Space lets the head go. I also began fading in the Space graphic as the head got closer, to indicate when it should be pressed, but it was probably too subtle for notice. With these changes in place, the game teaches itself effectively to all.

The second problem, that of stubborn players, was more tricky to solve. I had always intended [PRESSURE] to be a minute or two long. You play, you figure it out, you see all the surprises, and you throw in the towel, having experience the defeat I intended. But-surprise-people don’t like to lose, and don’t expect to be playing a game they can’t win. Originally, about half of the players would play for five minutes or longer, until I broke all my designer instincts and intervened, telling them that no, really, it was okay to stop. I had to strengthen the message of failure. The “music” and the graphical effects have always been part of [PRESSURE], discarded assets from other projects that found use in this game. But I had to make the transitions into the pounding state more effective. I smoothed the curve of events – originally, the player starting to stretch triggered a near-full-blown glitch state and pounding music. I rearranged when new mechanics are added. Crucially, I implemented an geometric difficulty curve, so that at around thirty steps the game truly does become impossible (and neatly fits with the true fact of thirty-three foot-pounds, reinforcing the bit of flair at the end). After a tester mentioned they had forgotten about the “ESC-give up” notice in the corner (which was very intentionally left on screen the entire time), I started growing it as the game proceeded, so that it was very clear what I expected the player to do.

All these changes increased the percentage of players experience the game properly and quitting after a spell – down from fifty to about twenty percent of players who refused to quit. I have a feeling, though, that that twenty percent are players psychologically unwilling to lose. One player told me that he detested giving up so much that he would in fact quit the program through the Task Manager rather than hit Escape! Against force of will like that, well, I might just admit defeat.

But so what? [PRESSURE] does what I wanted it to – makes everyone feel as nasty I do, sometimes.