A rough doodle of a thought


A thousand little playtests in your head

How do you begin designing a game, and how do you iron the kinks out? In this article, I explore the imaginative process underpinning early ideation as it occurs to me.

9 minute read

Design is Vague

Certainly, anyone who has ever imagined a new system of play, or an improvement to an existing one, could style themselves as a game designer. In the effort of putting my thoughts somewhere safe, I’ve been ruminating on what design means to me as a mechanical process. Empathy is an oft touted, yet muddlingly vague concept: “Put yourself in the player’s shoes in order to make a good game” – not untrue, but not very discrete or practicable advice. Rotes of advice such as this can easily become a box-ticking exercise during iteration if you don’t understand what you’re gaining by following it.

I’ve spent a few years now developing services to support online games, and one thing that’s struck me through innumerable playtests is how features are disappeared and resurfaced. The rationale behind these decisions tends to eventually click, but it’s not immediately apparent from the outside looking in just why this happens.

When I have an idea, I often enter that magical state of ‘flow’ where my stream of consciousness leads me to make many small decisions in my head, in the span of a few minutes. I realise I often do it while in the shower or out walking – I’m typing this article on my phone in the corner of a pastry shop.

When it comes to games, I’ll imagine myself as the player, moving through the world. It only exists in that way for me; I am the player. I’ll keep going until I find something that doesn’t work – a frustration or a roadblock. Like that episode of Black Mirror, ‘Hang the DJ’, where an algorithm imagines a couple together enough times to figure out how compatible they are. That’s really where it starts.

Failure and balance

I had an idea for a short-play online game where one invisible player would try to sneak to the other side of a task-filled room, while another player with a gun stalked around trying to find and shoot them. I liked the idea because it meshed the mischievous and social elements of Among Us and old Garry’s Mod levels.

The concept of the game. A person with a gun stands guard in front of a podium with a button, surrounded by traffic cones also blocking a doorway

It also helped that the idea was set in a single room. By literally constraining the design space to a Portal-esque test chamber, I could reason with the problems more concretely. Many online games with more ambition invite more questions haphazardly shuffled under the category of “later”, and I wanted to “fail-fast”.

We’re good at finding problems with things. As human beings, we’re always seeking to minimise our own discomfort, and therefore it’s quite easy to determine what’s not-fun about something. When designing an online game, you can use this quirk of nature to balance a design and arrive at a place where it’s fun for all parties. By asking cyclically: “how does this affect Team A?” and “how does that then affect Team B?”, you can make a more informed guess about an idea's longevity.

Round One

Take the game idea above – I imagine myself as the invisible player, nervous about the situation, immediately sprinting to the victory area. The hunter is surprised and upset to have been taken off-guard. It’s unfair, so the first concrete feature is to put a gate on the victory area – perhaps the sneaker needs to pull a lever which will be visible to the hunter.

Round Two

Iterating now, I’m imagining myself as the hunter. There is a single lever in the room. I have no other point of reference. I stand patiently by the lever with my gun cocked. The sneaker sees no way forward and quits the game, and I’ve figured out I need a way of misleading the hunter – perhaps I need two levers. I take a bite of my sausage roll and begin walking.

Round ???

This process repeats until I have a full, satisfying chronology, in which I’ve invited every silly idea that didn’t upset either player to manifest its presence in the game world. The hunter has a minute to move props around the room – traffic cones that tip over if bumped into, a pool of paint to leave footprints if stepped in, a pot plant to set off the sneaker’s allergies. The sneaker creeps to the back of the room and picks up a ball to throw and knock something over – a distraction! They dash to the first lever, then the second, bullets whizzing by their ear as they make it across the finish line. GGs are shared – it was a close call; they’ll get you next time.

Whether or not this idea would be a hit lies in its execution, and to some degree, the state of the world. What matters for now is that I have a flexible idea, a core loop can’t be immediately broken, and I’ve stepped through the scenario enough times to identify patterns of repeating elements.

A number of random items that might exist in the game, such as a potted plant, cat, button, lever, traffic cone, marbles and a laser beam

Extracting patterns

In this case, I can draw a distinction between static objects that can be interacted with, and placeable objects that move, make noise, and potentially produce visual effects. I can continue to elaborate on these two lists, constantly re-sorting them in my head as a function of how fun I think they are for both parties, and how much hassle they’d be to prototype. I’ll pick three at the top of each list to form part of my ‘vertical slice’ and invent a shorthand lexicon for them – my interactables, and my placeables. Building a mental framework like this helps you to prototype and iterate quickly, in addition to explaining your idea to bemused friends and colleagues.

I briefly consider if the lists are mutually exclusive to the hunter and the sneaker, or if both parties should be able to interact with both types – perhaps when both levers are pressed, the gate opens for a finite amount of time before closing and resetting them, meaning a keen hunter can sabotage the sneaker’s progress. Is that going too far?

Going too far

Contrary to most advice, I think it’s important to let your mind wander into the future when ideating. Seeing all the ideas meld together into a blurry picture of the ‘final product’ can be useful in avoiding decisions that would render parts of it unrealizable. It’s painful to have a great idea mid-way through a project, and decide it isn’t feasible because it wasn’t included in the plan from the get-go. It’s equally as painful to ‘finish’ something, only to have somebody point out a glaring flaw in retrospect. In the idea above, having followed a particular line of thinking far enough, I can begin to judge the idea on its principles: the hunter relies heavily on sound (and ergo headphones), making it immediately less accessible to specific demographics of players who may have disabilities, or simply prefer to play unbridled on their television. Will it be possible to pivot?

Two beach shores, one with the tide washing in a collection of flotsam, and the second with the tide out leaving only a single shell and green bottle

I like to think of it likes waves on a shore. At night, when the tide’s out, you can see everything left as it was at the end of the day – a big collection of rocks and shells tumbled over each other, the lauded ‘final product’. Then, when the next day starts proper, the waves come and wash all the smaller things away, leaving behind the heaviest and stalwart ones.

It’s important to have a vision of how things will look at the end, otherwise, you can end up with a mess of bolted on features from iterating without a clear direction. How will matchmaking work? Will Twitch viewers be able to mess with the game? Will I ever want to make an object that is both interactable and placeable? Can I think of a catchy name? If you ask these questions now to get an idea, and then pull back, let them wash away, you can focus on what’s important. Everything else? “It’s been thought about, yeah”. My key goes into the lock on my front door, and I’m ready to write it all down and sketch the level onto grid paper.

The “Real” World

Game design, among many things, is about the interplay between systems that evoke feelings. The space between is crucial – they can’t be considered in isolation.

For example, once you think you’ve hewn some maxims about, say, difficulty curves and randomness, you must consider them together for a specific design to see if there are exceptions to the rules. If you believe game should challenge you by becoming more difficult, and should include elements of randomness for variety, given a target audience of e-sports fans, will a very difficult game of chance frustrate players seeking to improve their skills? It all falls apart and lends credence to the importance of actual – not imaginary, playtesting.

A broken funnel spilling water messily into a glass bottle, a metaphor for only some ideas making it into the final product

Many of the ideas I had in my head, the ones that survived the initial culling, will still need to be tested with other people. Many will be discarded before then, and if enough are without replacement, then the whole idea will be too. Because this is such a quick process, this kind of conclusion is less disappointing than it is informative, given some ideas may be revived in more appropriate context later on. Singular mechanics may act as the seeds for other brand-new ideas in the future.

Recall that this whole process is in the effort of empathising with the player. A poor design is unsatisfactory, as it will always be uncovered by players – you can’t sneak a broken idea past a million critics. The most empathetic thing you can do for a player is to never ask them to trade their time for an experience you know is wrought with frustration, irrespective of the graphics or marketing budget. With an analytical mindset, and a desire ask “why?”, “why does this work so well and how can I prioritise it?”, “why doesn’t this work and can I change it until it does, or will the idea be improved by removing it?”, you can follow your own cyclical path to something truly worthwhile.

 Creative Commons License