Speak to Me!

A Rant on Dialogue in Games

Video game storytelling is a nascent field. If we’re honest about it, we don’t really know how to do it. At least not well. Most of the time we just give up and copy film.

Why?

Because it’s comfortable to wrap ourselves in the cozy vernacular of the Hero’s Journey, three-act structure, and cinematography in general. It feels much safer. When we look at the interactivity of our medium and how it’s going against the grain of the stuff we’ve borrowed we are forced to excise the interactivity violently because it risks disrupting our carefully constructed “cinematic” experiences.

One of the worst offenders is dialogue. Something screenwriters have basically perfected for their media, but something we struggle with to such an extent that we still can’t agree whether we should even give our protagonists a voice or not.

So let’s talk about talk. In video games.

“Speak to me! Speak!” T-Bird gets what Eric Draven thinks he deserves, in The Crow.

Parser-Based Dialogue

In parser-based adventure games like Leisure Suit Larry, and in many text adventures, a significant part of the attraction is to experiment and explore. To find your way through the game one misspelled sentence at a time and see what happens when you decide to say stupid or offensive things, or to come ever closer to the story’s conclusion.

With the ELIZA Effect in mind, there may even be a certain level of emotional connection involved. But beyond even that, a parser-based game will often seem larger (or smaller) than it really is, based on the types of answers you get.

At their best, you’ll feel that anything is possible. This was certainly my own experience playing Starship Titanic. Clever or hilarious responses that made me feel like I was interacting with the game world. Like the designers had anticipated every clever profanity I could conjure up from my teenage mind.

At their worst, it’s the same as the trial-and-error segments in many adventure games where you try to figure out where to use the odd things in your inventory and you’ll have to bash your head against the keyboard until the right sentence falls out.

But one thing to be said about this style of dialogue is that it was a ton of fun, and though it requires typing – which is somewhat awkward in modern gameplay – it was a very direct form of communication. Certainly more direct than what we’ve gotten used to since.

Information Dumps

“It is important to remember that your story is working in unison with gameplay. The more your story can be told through gameplay, the better. Much like the film axiom ‘Don’t say it, show it,’ you should be thinking in a similar fashion for the game: ‘Don’t show it, play it.’”

Flint Dille and John Zuur-Platten

Including many of the games that did parser-based dialogue, games have always done a lot of exposition for some reason. You know what I mean:

In the world of Fantasyland, the slime elves come from a 1,000-year lineage. Before they arrived in the land of Snowplace in the southern parts of Fantasyland, they spent several centuries Frowning and Despairing onboard Seaweed Ships – boats made not of wood but of seaweed from the bottom of the Dark Evil Ocean – sailing across stormy seas and sometimes resorting to piracy out of boredom. Then the mysterious Crown of Mystery suddenly shattered into three fragments for reasons, and you – our only hero and hope – must venture forth to find those fragments before it’s too late. Also, if you want that broadsword, that’ll be 500 gold pieces please.

It can be called lore or background or even be confused for narrative depth, but it’s really just information dumps and they rarely serve any purpose beyond feeding you the stream of words many narrative designers somehow insist on having. They’re there partly because they’re insanely cheap to produce when all the systems are in place, and partly (presumably) because many writers simply enjoy writing the stuff.

Of all the things we’ve taken from Hollywood, the ideal to “show, don’t tell” is somehow a thing we skipped. For all that is holy, we should stop doing infodumps.

Basically, if something needs to be stated directly and explicitly, it’s most likely too convoluted to be worth keeping.

State-Based Dialogue

“Us game designers are envious about movies for some reason – but film and cinema, they can’t do a lot of emotions because it’s simply an empathetic thing, theater, it’s technology. The format doesn’t allow certain emotions nearly as well as games.”

Nicole Lazzaro

Film excels at empathy. When the monster in a horror movie shows its ugly mug, we don’t get to see it – we get to see the reactions of the protagonists. But not before the monster’s been hyped up by the characters’ mounting distress. The suspenseful music helps too, of course.

Characters can be sad, happy, angry, or they can display a wide range of other emotions, but you – the viewer – will only ever display empathy. Good actors will make you feel, but you’re not an active participant. You’re not there in any active sense.

This is the style of media we grow up on, making it more intuitive to go straight to our cinematic inspirations when we want to tell stories in games. And we don’t just emulate it conceptually, but concretely. We have long-since introduced the idea of a separate dialogue state where the game pauses, potentially zooms in, and the camera work can then be directly influenced by Hollywood cinematography (in 3D). Or at the very least, set the game into a restricted state where we can maintain directorial control.

State-based dialogue has been around even longer than fake IDs. (Image from Ultima VII: The Black Gate.)

The button-to-action immediacy of real gameplay is turned off, and the camera snaps to a view of whoever is talking. Usually kicked off with an impersonal greeting or a reminder of central story beats to make sure that the player is on the same page as the character about to speak.

You know the ones. “Have you done the thing I asked you?”

Mass Effect, which is the game in this screenshot, does address one issue that most state-based dialogue suffers from, but it doesn’t solve it. The problem of repetition, where you have to convey the same dialogue line multiple times even though it’s only said once in the presented fiction.

Typical state-based dialogue interaction looks something like this:

  1. A Non-Player Character (NPC) starts the conversation. Usually prompted by player activation, and sometimes by an initial Player Character (PC) dialogue line, but it’s often an NPC that starts a conversation from the perspective of the content being displayed.
  2. The NPC speaks a line.
  3. A number of alternative dialogue responses appear. The player must read each alternative to understand what can be said.
  4. The player selects one of the possible alternatives.
  5. The PC speaks the chosen line, repeating the same content that the player has already read and selected.
  6. The NPC responds, either taking the player back to 2), or ending the dialogue state.

It needs five separate steps for a single conversational exchange. It’s as if we had to watch actors quietly reading their script before saying their lines. Not very cinematic at all.

Mass Effect addresses #3 by stating the intent of each option instead of reprinting the whole prompt. This eliminates part of the reptition, but not the requirement of having to first read and then choose before a line is spoken. But it can sometimes cause frustration as well, when the shorthand doesn’t reflect what the player actually intended to say.

If you’d watch the dialogue state and not read text, these steps invariably makes state-based dialogue look more like drawn-out staredowns than conversations. But the alternatives aren’t necessarily better. Not as long as we have very specific stories to tell.

Please register for the court, evidence exhibit #2: a screenshot from The Witcher 3: Wild Hunt. The cinematic heritage is probably never clearer than in The Witcher 3. What makes it different from Mass Effect is that it embraces it more fully. You’ll often have several characters take part in the conversation, and you only choose the lines for the usually brief and very direct Geralt of Rivia, The Butcher of Blaviken. It’s a much more passive experience, but actually benefits from this since it leans into its cinematography. Embraces it. It’s using the game’s systems for cutscenes wholesale and therefore blurring the lines between the different types of narrative content the game offers. You can’t draw a clear line between cutscenes and dialogue, and this increases the value of both.

It’s much more fluid, but through production value. It’s more like a movie, and therefore its “movie parts” feel better. The dialogue is still experienced in a separate state and still suffers from the same problems of any other state-based system.

Though the production values have improved dramatically, this style of dialogue is what we’ve been stuck with. Those five steps haven’t changed at all between 1992 and 2022.

How state-based dialogue looks like when characters wait for player input.

Elimination Dialogue

The very worst that dialogue states have to offer is where you need to say very specific things because the writer or designer demands it. The whole game won’t progress until you have eliminated all the wrong choices and been forced to make the right one.

In some types of interactive fiction, this is perfectly fine, because your interaction prompt serves mostly to parcel out text into more easily acceptable pieces.

It also makes sense from the perspective of cinematic inspiration, of course, since the intentions of the writers and designers take precedence over those of the player playing the game. In film, the frames will always be served in the right order. If you look at it like that, it’s the logical conclusion to a decades-long battle between systemic interaction and cinematic gameplay; the two arch-rivals of video game direction.

Nag Lines

Sometimes we do have dialogue that’s allowed to stay free from the state-based restraints. But we do tend to use this very irresponsibly. A nag line is a style of repetitive and often extremely obtuse calls to action from the game system, communicated using lines of dialogue.

Once “I think we need to open the red door” has played, you’ll soon hear, “maybe the red door should be opened,” followed by “the red door must have been placed here for a reason,” and finally, “open the red door damnit before I quit this stupid voice acting job!”

For an absolute master class in both satirizing and perfectly gamifying this style of voice over, you should do yourself a favor and play The Stanley Parable.

If you’re playing any other game and you hear nag lines you should back away slowly from your gaming hardware and call the cops on yourself before you are forced to do something drastic.

The Last of Us Part 2 is extremely violent, and also shock-full of nag lines.

Combat Dialogue

“The guiding principle behind combat banter in FEAR is that whenever possible, AI characters should talk to each other about what they are doing. Rather than having an individual character react with a bark, multiple characters carry on a short dialogue that broadcasts mental state and intentions to the player.”

Jeff Orkin

For years, if you talked to anyone about Artificial Intelligence (AI) in video games, they’d toot F.E.A.R‘s horn. An action/horror first-person shooter, F.E.A.R (which’s ridiculous acronym I refuse to spell out) did many interesting things. But it’s maybe even more interesting for what it didn’t do.

Many of the people who praised the AI were saying that it did such smart things and seemed to really understand what it was doing. But as the lead AI programmer – Jeff Orkin – explained, all they really did was tell you what they were doing.

As an example that may or may not exist in the game’s content, imagine two enemies approaching the player at roughly the same time. They’re on opposite sides of the player and one of them starts shooting. Since the AI can use perfect information, it can know the situation and respond to it. Maybe one plays the dialogue line “I’m going in,” and the one shooting responds “I’ll cover you!”

This isn’t because they’re smart, but because those lines are triggered by what gets collected in the game’s current state space. State triggers the dialogue and not the other way around. This type of dialogue is dynamic, interesting, and can make the situation seem more human. For example when an AI can’t reach a certain area and simply says “hell no!”

One tier below combat dialogue you find what’s often called “barks.” Things AIs decide to say as immediate responses to what they’re doing or experiencing. Things like “grenade!” or “reloading!” or other things that advertise changes in their local state.

This is something many games do really well, and the perfect stepping stone towards what modern video game dialogue could be exploring instead of staredowns.

Forced Empathy

Like Nicole Lazzaro points out, empathy is the thing that film does best. When we borrow from cinema it’s natural to think that we also need to do empathy. But when we try to use the empathetic tools employed in this other medium, it falls apart.

This happens in many games, but I’ll use FallOut 4 as an example. As the game begins and you make your character, you’re introduced to your spouse. Once the introduction reaches a close, this spouse is killed brutally in front of your eyes.

In a film, you’d see the sobbing shaking form of the protagonist as the tragedy of the event sinks in. You’d feel for that character. Understand some of what that character goes through, especially if you have a partner of your own.

But in FallOut 4, it’s forced to the point where you’re hammering ESC because you just want to play. You don’t care about this polygonal 3D model since it’s not your partner – you’ve just been told that it is.

Your spouse for the past few minutes is murdered and the game expects you to care.

All we have to do to see how empathy can become player motivation is go back to the earlier instalments of the same game series. In the first two FallOut games, the village where you begin the game is your home. Full of people you care about and who care about you. Later in the story, when those villages are attacked, this becomes personal. A thing you really don’t want to happen.

Please do borrow from cinema. But don’t try to borrow the one thing cinema will always do better than games.

Payload vs. Delivery

I love well-written games with good stories. Unsurprisingly, I’m not alone. People praise the thematic delivery of God of War, the depressive angst and fanaticism of Ellie in The Last of Us Part 2, and how their choices in Mass Effect affects the cultural complexities between Mordin and Wrex. There are many game stories that we remember just as fondly as those from Hollywood or our favorite authors.

But we also often confuse the payload, meaning the content, with the delivery; the state-based dialogue and cutscenes.

We didn’t have the strong experiences in these games that we had because they had cutscenes in them or a clever director saying how things should be. We had them because we were there – we made the choices. If there were no choices to make, then we were at least present enough to not turn off our consoles.

This is the trickiest part of the entire conversation, as most of the praised story games do in fact deliver their content using state-based dialogue. Passive observation. This often makes us equate the delivery format in the games we like with the payload of the delivery. In other words, if we like God of War, our first instinct is to tell our game stories in exactly the same way. Maybe even with the same plot beats or motivations. For example, making a game about delivering someone’s ashes.

It goes the other way too. Where you can fail to see clever features in a game you don’t like because you conflate payload and delivery.

I want to argue that this conflation is the reason we get so many games with state-based dialogue in the first place. When we sit down to make our dialogue-heavy games, we think about the stories we remember, and rather than considering how to invite the player into the experience we assume that our game has to use the same delivery if we want to get the same results.

We keep the staredowns because our favorite games had them too. It seems intuitive that, if you want to make a game that captures the emotional payload of God of War, you copy the delivery. Or even parts of the payload. But that’s really not how storytelling works, or how video games work.

Interactive Dialogue

“[G]ood games writing does three things at the same time: 1. characterizes the speaker or the world 2. provides mechanical information and 3. does this as succinctly as possible.”

Anna Anthropy

When it comes to dialogue, there are some outstanding attempts to make dialogue more interesting that I want to highlight. It’s not an exhaustive list by any means, but it shows that new thinking both isn’t new and doesn’t require a whole lot of thinking. There are countless small experiments we can do before we decide to stick to our beloved staredowns.

Left 4 Dead

It surprises some, but L4D has a fantastic dialogue system. The techniques used are not unique – and they have been around in some form since the early days of immersive sims – but they are unusually well-documented thanks to Elan Ruskin’s excellent GDC talk from 2012. (It’s probably the link I’ve shared the most in my entire career.)

I consider this dialogue interactive because it responds to what’s happening as it happens rather than requiring the five-step process described earlier. It serves as contextual feedback to things in real-time, just like how Jeff Orkin describes F.E.A.R.

L4D’s great writing and dialogue system alleviates the trauma of hearing “Reloading!” repeated 1,000 times per second.

Kingpin: Life of Crime

No one remembers this feature when they think back to Kingpin, but it had what may be the most dynamic dialogue system in video game history.

Here’s what it did. The Y and X keys were mapped to context-sensitive positive and negative responses that you could press whenever you wanted while playing the game and looking at an NPC. It could lead to fights, it could disarm situations; even trigger questlines (such as getting a drunk a bottle of alcohol).

It didn’t work flawlessly, but it promised something that games still haven’t delivered on 23 years later: dynamic freeform dialogue. Something that can stay interactive every step of the way and completely avoids the staredown.

The secrets that reveal themselves in Kingpin: Life of Crime‘s manual.

Cyberpunk 2077

Whenever I write something positive about Cyberpunk 2077, people like telling me I can’t have played many games. But I have, surprisingly, and still think there are tricks used so well in CP’77 that it speaks of what games can be able to achieve with dialogue in the future. It’s a crucial first stepping stone leading us beyond the staredowns.

Ironically, it’s because it leans into its cinematography. Something I’ve already used too many words complaining about. But the difference from other state-based dialogue systems is that it does so carefully and – most importantly – with a great deal of subtlety.

In the scene pictured above, you are introduced to Evelyn for the first time. A character that plays an important role in what’s to come, though maybe not in the way you think. She won’t greet you immediately. She’ll simply sit there and watch, waiting to see how you make your move, and blending into the noisy nightclub background. Instead, you speak to the bartender and ask for Evelyn. Once he hands the conversation over to her, he takes a step back and lights a cigarette as Evelyn leans forward.

This is carefully directed every step of the way, and the lighting and the way the characters signal who you should pay attention to using body language and staging is part of how cinematographers make a living. It’s a bit too locked down and restricted to truly come into its own, but the promise of these types of stage-directed set pieces is that we can finally find a form language informed by how games are played.

Because, what if the stage-direction could be systemic? What if the careful lighting and the conscious choices of idle states tailored for 1v1, 1v2, 2v2, and other dialogue dynamics could become part of our own ludography, so we can finally leave our obsession with film by the wayside? This is what CP’77 promises, by taking a first tentative step.

The other thing that the game does is that it carries its factions, missions, and major plot beats through characters and not through exposition. It borrows from how TV shows can go back and forth between plots and weave a coherent tale through the whole rather than as a linear constant. There’s so much subtlety in writing and presentation at work here that it’s a shame that the game’s other flaws have probably scarred its reputation permanently.

Citizen Sleeper

Games rarely let time affect their storytelling. There have been some examples through the years, from The Hobbit, via Dead Rising, leading up to the example here: Citizen Sleeper.

Taking a cue from the use of clocks in tabletop role-playing games like Blades in the Dark, this title often both communicates things that wait for you around the corner and things that you want to prioritize. It’ll give you a clock and say that it provides a bonus at the end, but it can also simply leave a cryptic clue about something bad that will occur.

Once you reach the conclusion of a clock, usually based on the number of work cycles you’ve completed on the game’s broken down space station, there’s always a tricky tradeoff or some consequences to deal with based on how you handled the clock along the way.

By making choices be more about tiny interpersonal decisions in multiple situations, and the consequences follow based on the sum total, this game manages to tell a very different kind of story and it does so almost entirely through conversations with the game world’s various NPCs.

Telltale Games

Beyond the sometimes excellent writing, there are actually few things I like about the Telltale games. It always felt like a style of game that didn’t evolve but simply stuck to a formula that gradually lost its charm.

With the Game of Thrones outing, and the first episode’s disappointing lack of choices that actually mattered to the story, I stopped playing these games. They were narrative games of the sort where a writer has a story to tell and acts like your interaction makes a difference. I lost the illusion, and couldn’t get it back.

But two things I adore about the Telltale games is that they tell you what matters and they compare your choices to those of other people playing the game.

It’s been said many times that the “Clementine will remember that” cues are not always true, but it doesn’t really matter, because it shows that the characters in the game’s simulation feel how you treat them. The ELIZA Effect again – we care that they care.

It demonstrates that we don’t need to make complex systems to turn dialogue into something more interactive. Sometimes it’s enough just to give clear and timely feedback.

My favorite Telltale game is Tales From the Borderlands – a crazy fun time.

Until Dawn

My favorite out of all the Telltalelikes is Until Dawn. A skillful tribute to the college slasher genre of and one that tells a tight and interesting story about teenagers going to an isolated cabin. The story develops in exactly the ways you’d expect, but what matters is that the ending will vary greatly depending on how you play.

The spectrum goes almost all the way between no one surviving and everyone surviving, all based on how you manage the relationships in the group and whose sides you pick in the group’s many conversations. Clever use of stereotypes, great writing, and dialogue that branches in exactly the right ways. It’s funny, scary, and carries its tropes extremely well.

Structurally, it’s maybe nothing special. It makes use of many passive observation techniques, including quick-time events. But it also shows you how far you can push dialogue as a game mechanic when you respect both your inspiration and the strengths of video games as a medium.

Until Dawn lets you do the type of things that you always yell at the TV while watching a horror movie.

Red Dead Redemption 2

RDR2 is primarily a cinematic experience in its storytelling (just like CP’77 is). But the context-sensitive interactions that you can access during sandbox play make both for interesting situations and for a sense that you’re part of the world. If it wasn’t for the separate mode that requires you to hold a button to access it, it would conjure memories of Kingpin: Life of Crime!

As with R* games since time immemorial, the controls will never quite sit right and you’ll still accidentally rob people when you just wanted to say hi even after several hours of play. But as has also always been the case, this is a big part of the core experience. So many times where things snowballed out of control and I tried to make things right again, the usefulness of dynamic dialogue in a sandbox truly shines.

Disco Elysium

The clever thing about Disco Elysium, or at least one of the many clever things, is that it lets the world and your own mind talk to you. Much of the game’s dialogue is informing you of things about the world, but filtered through the different often untrustworthy parts of your character’s own conflicted mind. You’re literally arguing with yourself.

It gives the game a somewhat dreamy atmosphere, where it can be hard to separate voices in the world from the voices in your head. Not to mention separating truth from fabrication. Furthermore, the whole game is focused around dialogue. You can talk yourself through every scene and feel clever doing it. A confident modern take on what Planescape Torment did at the close of the 90s.

The lesson to learn from Disco Elysium – beyond making sure to have great writers – is to ask who each voice in your game belongs to. What kinds of conversations can be had beyond nag lines, combat dialogue, and state-based staredowns.

Oxenfree

There are so many neat tricks in Oxenfree that deserves mentioning that it feels hard to cover them all. The greatest thing it achieves is to make the ongoing conversation feel thoroughly natural. Characters can switch subjects, abort each other, stay quiet instead of responding, and just keep the stream of words flowing in a way that sounds and feels like real conversations.

As it does this, you’re also exploring an island and getting to know the cast of characters. It’s a great game in many ways, maybe mostly because it blends real-time interaction with an ongoing conversation. Much like an Aaron Sorkin show or The Gilmore Girls, but with interaction.

Interstate ’76

A bit tongue in cheek, but if I didn’t take this moment to praise Interstate ’76‘s fantastic poem button (yes!) I’d be committing a crime.

Stampede, the main character’s good friend and radio operator, responds to your requests for poems with surprisingly deep and thoughtful pieces. They always felt like a clever way to emulate how talkative cars can make you.

Conclusions

As we approach an era where we can offload an increasing part of the content workload onto systems like JALI, Altered, and every experimental thing Embark is working on, it’s time to start looking into truly interactive ways to handle dialogue.

Games are not movies, and they should stop trying to be. But we should keep borrowing the good parts so we can make them better suited for our own work. We just have to remember that our medium is interactive and experiment more, so we may see where it leads us.

Let’s just agree that, 30 years from now, we’re not still using the same state-based dialogue as we’ve been using for 30+ years already. But let’s also agree that you don’t have to do all of that innovation in a single stride. It’s possible to take small steps forward, all the time. We just need to take more of them.

Books for Game Designers

Some cool news in Playtank-land (since I can’t talk about what happens in Tic Tek Toe-land): I’ve signed on with CRC Press to write a game design book!

It’s a book I feel is currently missing and that will fill a critical gap in the knowledge sharing around game design. But to clearly state where I’m coming from, this post will be dedicated to some fantastic books on game design that already exist and that you should read and keep around for future reference.

These are far from all the great game design books out there, but they’re the ones I most often come back to.

Advanced Game Design A Systems Approach

By Michael Sellers

This is one of my personal favorites. I picked this up after the Frostpunk team recommended it greatly in an article on their procedural systems. Systemic games are growing in importance and relevance. Partly because content-driven games have a limited lifetime and are expensive to make.

My biggest takeaways are the practical ways to look at systems as Economies, Ecologies, or Engines, and what this means for your game.

The Deck of Lenses

By Jesse Schell

Not technically a book at all, but a deck of cards serving as a companion to Schell’s The Art of Game Design: A Book of Lenses. The book does a great job of holistically describing games, but the deck turns an interesting read into a practically useful tool.

Each card is a “lens,” with a set of questions you can ask yourself in order to more deeply inform your design. Even questions that may not seem immediately relevant will always make you think.

Challenges for Game Designers

By Brenda Brathwaite (now Romero) and Ian Schreiber

Another favorite and one that I often quote. Not about game design as much as how game design is something you must practice and turn into a practical skill. It’s not about winning armchair duels or playing reference tennis.

Or in the words of the text, “A painter gets better by making lots of paintings; sculptors hone their craft by making sculptures; and game designers improve their skills by designing lots of games.”

Game Programming Patterns

By Erik Nystrom

I know. Your instinct is to say, “but I’m a designer, I don’t need to know programming!”

Yes you do. If you want to make digital games, knowing how games get made and some of the tricks that enable them is extremely helpful. At minimum, it lets you talk to programmers in a more constructive way.

Besides, you can take a peek at Nystrom’s book online for free and not just take my word for it.

Uncertainty in Game Design

By Greg Costikyan

This small book opened my mind. Its examples aren’t exhaustive and many I’ve talked to have argued that it doesn’t have much content. But it doesn’t need to.

It talks about uncertainty as a key element in what make games so compelling to play. You may know it as randomness, competition, hidden information, or in one of the many other forms that the book brings up. The book makes a compelling case for why you should make sure to consider which uncertainties you are employing for your own designs.

The Pyramid of Game Design

By Nicholas Lovell

Games as a Service (known as GaaS) are here to stay. The Free-to-Play business model is compelling for a variety of reasons, all of which Lovell mentions in this book.

Among gamers, these practices are often lamented. But Lovell comes from a different perspective and talks about how turning a game into more than a game – a hobby – is the path to success. Not just introducing mechanics designed to optimize monetization, but rather to hook the player and make them want to come back for more.

Even if you don’t like GaaS, Free-to-Play, or any other of these models, it helps to understand what makes them work.

The Missing Book

Books that focus on specific topics will usually be my favorites. This is why I don’t list Schell’s The Art of Game Design, even if it’s a great book. Because what it does is done by many many books out there: it explains the theory of game design.

For various reasons, I’ve felt that a practical guide to how you do game design is still missing, formatted as accessible tools that game designers use in their everyday work. This is what I’m trying to write and have been trying to write for the past couple of years, even before I was contacted by CRC Press.

But they’ve given me a reason to finish it!

Wish me luck.

It’s (Not) an Iterative Process

“Game design, like most forms of design, is an iterative process. That means that the game is quickly prototyped, played, and refined again and again before it is finalized.”

Brathwaite and Schreiber; “Challenges for Game Designers”

Iteration is a word game developers use to describe the magic that makes games happen. But what we actually do when we iterate, and what we iterate on, isn’t exactly consistent. Rather, “it’s an iterative process” is a dismissive and handwavy equivalent to “God works in mysterious ways.” 

There are dangers to iteration as a solution rather than a process and some may even seem like they’re good things when they’re not.

The Dangers of “It’s an Iterative Process”

One common problem comes from iterating on late-stage production content. Say, a character that took twelve weeks to make and has to be remade because someone wants some large changes; or an in-engine cinematic that’s already been put together and turns out to be too long, too short, or uses the character that needs large changes.

Editing on late-stage content isn’t easy since in-game assets and engine tools are used. Redoing a cinematic can be a painful process. Redoing a character may require revisiting every moment in the game where that character is used, making sure the sword on its back doesn’t cut through its leg while moving or making sure that the colors match what the art director wants.

It may seem trivial to “just” rotate a thing or change a color value, but sometimes it’s not. Sometimes it snowballs into disaster faster than you can spell overtime. If you need a specific card from a house of cards, just pulling it out collapses the whole thing. Same with late-stage iteration.

At one point, this once went so far that a director said “if this is still a problem closer to launch, let’s revisit it.” But, as everyone knows, anything that gets pushed “closer to launch” will be put way down on the list of priorities and the problem will persist into the finished game. In that specific unnamed case, the problem did persist and is in fact in the finished game.

This place is where we often end up when we say, “it’ll be better later,” or some variation of the same. When we hide behind the iterative process itself without thinking too closely on the hows or whats of iteration.

The Dangers of Cheap Iteration

Some things are much faster and cheaper to iterate on than others and can therefore be iterated on for too long during a project’s lifetime. Sometimes because we have people hired to do the iterative job. (Sorry, but game designers are often the baddies here.)

Three specific things stand out:

  • Theoretical design. “Wouldn’t it be cool if” is another theoretical design iteration that doesn’t necessarily have any practical meaning for your project but can still be pushed through at late stages. Designers without practical skills tend to be the worst culprits here.
  • Writing. Writing is rewriting, as they say. A writer can come up with literally anything at a moment’s notice. When writers drive the content, this is what often happens. Five minutes putting words in a document and suddenly there’s another six months of work.
  • Sketch art. Good sketch artists can draw things faster than you can blink, and can similarly introduce new coolness and greatness with very short notice. Of course, they rarely do this spontaneously but because a director/designer/writer-person asks for it.

These three are so cheap to iterate on that it often causes another kind of problem: you never stop iterating on them and by extension the features or content they affect. Especially if you have many meetings of the sort where you talk about your project in abstract high level terms.

Even deep into production of your game, you can still backpedal on some story element, introduce a new character that the creative director came up with for some reason, or change fundamental designs because “wouldn’t it be cool if?”

This is where much of the bad type of iteration comes from, and trickles down through production like acid rain. If you want to know where game development delays come from, this is often it. You probably know it by the name “feature creep,” or “creative vision.”

You should do less of these three once you reach production. Preferably none at all. Do spend a lot of time in preproduction iterating on these three cheap things, and prototype them to your heart’s content while they remain cheap. But once you hit production, you must stop.

The Dangers of Deliverables and Iteration

Deadlines are like Terminators. They can’t be bargained or reasoned with, and they won’t stop until you are dead. This makes them completely incompatible with the loose approach to iteration, where we’ll “fix it later.”

Once you hit the deadline, what you have is what you have – if the iteration didn’t work out, you have nothing, or you are forced to fall back on the bare minimum. Or, worst case, what you have simply isn’t very good.

There’s an idea that things can only be known to be good at the end of a project, when all things come together. But this is only because we often spend our whole project time iterating on production content and don’t force ourselves to iterate early and cheaply.

How Nintendo works on their controls for a very long time, and how art direction can be constructed carefully around communicating your gameplay, are examples of good iteration. Once you hit your deadline, you must know what you have, and you must have already finished all the iteration you needed to do.

If not, whether your game is good or bad will basically be a coin toss. A coin toss based on professional experience, surely, but still a coin toss.

The Dangers of Third-Party Game Engine Iteration

There’s a natural inclination to jump straight into the scripting or programming tools and churn out a playable demo. You open up a third-party engine, throw some ready-made templates into a project, and voila: you can move and shoot stuff! 

This is often great, because it lets you answer hard questions and push your design forward. But chances are that you create a kind of illusion of progress, where making the bare essentials work feels like good progress because you didn’t have it before. But once you try to take the next step, you get bogged down in minutiae that are entirely irrelevant for the iterative work you aimed for. Especially if your engine of choice relies on ready-made packets of logic that can become black boxes for your implementation team. Say, a ready-made AI feature packed with extraneous functionality or a system for handling input that causes high latency.

What happens is that you spend more time fixing the ready-made solutions than you do iterating on your game. There’s also a great risk that you start skipping features you wanted to make because the engine doesn’t have good support for them, or they are too hard to make without extensive refactoring or source code additions.

Or the opposite happens and you start building features based on cool stuff in the engine rather than the game you had in mind. All of it is problematic.

The Dangers of Stakeholder Iteration

For most of us, some kind of external stakeholder pays our salaries. Bless them for that. But they can also be hard to please or not really know what they want. There can also be multiple tiers of stakeholders that are equally hard to please and may have their whole employment hinged on making your life difficult.

There are three specific situations where an external stakeholder will typically ask you to “iterate,” except it’s usually in a visual way and doesn’t necessarily help the game itself move forward.

Best case, you can allocate specialised resources or even use the stakeholder’s own resources to do this iteration. Worst case, you have to reallocate parts of your team from production onto the request.

The following are three situations where stakeholder iteration risks sidelining your project:

  1. In advance of announcements, marketing events, and so on. It’s not unusual to be asked to make a video for E3 or some similar event. Some stakeholders – like game publishers – have marketing departments that do this for you; others will require you to do it yourself. Sometimes it’s planned for way in advance; sometimes you learn about it two weeks before the fact and you have to work overtime or pay expensive outsourcing to do the overtime for you.
  2. When you pitch, game publishers can be especially awful to work with. Sorry, game publishers, but it’s true. They want to see a video, you make a video; now they want gameplay. You make gameplay; now they want to see more, or they invent a buzzword they need you to realise. All for the sum total of $0. Pitching can be desperately frustrating, or as Guillermo del Toro phrased it for movie-making; “it takes Hollywood two fucking years to say no.” Game publishers are the same. This can change to some extent if you have other kinds of stakeholders, but convincing people that you can in fact do what they are paying you to do is an incredibly frustrating process.
  3. Scrambling against competition. Some stakeholder requests are complete shots in the dark. On one project, we were asked to add a train level because Uncharted 2 had just come out to some fanfare, and it had a train level. If you fail to see the correlations in that sentence, you understand how we felt. If you have a good relationship with your stakeholders, you can push back against these types of requests. If not, it’s something you simply have to do. I call these “spot requests,” and they run the gamut between useful fixes and complete waste of time.

Should We Not Iterate?

Yes we should! In fact, we should do a lot more of it. In the past year (2021), I spent a lot of time working on prototyping and finding out where the boundaries are. What is it you need to iterate on? What tools are there to use? How can you iterate faster and in a more focused manner?

I’ll be sharing my findings in a series of posts on prototyping frameworks, in the coming months.

Stages of a Game’s Design

Projects I’ve worked on, large and small, have often demonstrated similar issues with game design in their later stages. Beyond having me in common – which is hard to do anything about when you’re me – one issue has been that the role of game designer changes throughout the project but not all game designers adapt to this change.

When they don’t, they can be part of the cause for delays, miscommunication, and overtime.

To illustrate why, let’s sort a whole game’s creation from idea to launch from the perspective of what a game designer should do. (In my opinion that is – remember subjectivity!)

Ideation

Many designers thrive on ideation. Coming up with crazy mechanics and clever solutions to theoretical problems. Having ideas and working through them at breakneck speed. But ideation has a time and a place, and it’s not a full-on brainstorming meeting three weeks from launch.

Keep it short, sweet, and early.

Exploration

With all those ideas done ideated you take them to your media of choice and you explore them. In-engine rapid prototyping, storyboards, one-pagers, session prototypes, role-playing game prototypes – there are countless ways to explore the fruits of your team’s ideation. This is where you do it.

What needs to come out of this is a means to communicate what your ideas are actually about. Not just material for more ideation.

Commitment

This headline looks scary. Maybe it is. But the thing is that you need to commit to the things that work during exploration and abandon the rest. This is where you do that. In the best of worlds, you can commit gradually through a revised exploration process. More realistically, whatever you have time to explore will also have to be what you commit to. The sad truth is that most games have very little budgeted time for design exploration.

STOP!

The word ‘commitment’ in the previous section is no joke. When you’re done committing you’re committed. What you have by now is some final form for your game. On paper, in prototypes – something. You absolutely cannot go back to exploration or ideation once you pass this line:


If you read this, you’re on the other side of the line. Just remember you chose to cross, wipe the whiteboard clean, and get to it. If you’re caught ideating or exploring on this side of the line, you should be (humanely) punished for it.

Problem Solving

Design is still needed. Ideation and exploration isn’t needed, but figuring out what to do when a button combination doesn’t work or focus testers can’t figure out where to go next is needed. Solving real problems demonstrated by the playable game.

As a game designer, you play your game every day at this point. Focus on finding problems with the design – don’t report bugs and glitches. You can do that too, but it’s a bit too easy to put your tester goggles on and lose the holistic perspective. Instead, make up personas and play like they would. Do dumb things and see what happens. Make checklists of which steps you have to go through to make standard tasks like changing the resolution or looking up which button to press – then try to remove as many steps as possible and filter the game’s information in an understandable way.

Balancing

After solving problems for a while you’ll know all the sliders and variables and spreadsheet details you have to work with. This is a more fine-grained process than problem solving and assumes that you’ve mostly moved on from that stage.

You’re still playing and watching others play but you do so to observe the results of your balancing. Look at this as a polishing phase. By this point the game fundamentally works but it’s not quite ready for mass market. But it’s ready for your fans, if you have them. This is where you can do an open beta or something like it. Discuss the project openly in forums, if you have the luxury of an existing community.

The state of the game outside of the designer’s responsibilities may still be lacking content or features, but you’ll have to be able to look past the most glaring faults and focus on the balancing. It’s getting there, but it’s still mostly for the “true” fans.

Tuning

There comes a point where you need to commit to your project and start going from balancing to tuning. You can no longer listen to fans of your work, but must now start making the game for the market.

Once a game gets out in the wild, you’ll realise how wrong your balancing assumptions were, and the more of that you can do before launch the better.

Consider the 10,000 hours from a different perspective. Your game will be subjected to people’s first hour 10,000 times or more. There’s just no conceivable way that you can predict how thousands of people will try and succeed in breaking your game. Some don’t like the genre, the gameplay, the graphics, or they think it’s a different game than it is because it behaves similarly enough. You must figure as many of these cases out as you humanly can.

Most test players will probably do just as you thought they would, or correspond to one of the personas you devised during problem solving, but some will get stuck, misunderstand something, or just plain dislike everything you’ve tried to do and think you’re a moron. Sometimes loudly.

You may be forced to go back to problem solving at this stage, but it should only be in extreme cases and isolated problems. For the most part, designing at this stage is an effort to rebalance things so they fit with practical mainstream reality. Tuning them just so. The biggest problem in this whole stage is that you may end up having to alienate some of your “true” fans who helped you balance the game. But shifting from balancing with fans to tuning for the market is absolutely essential for your project.

Endnotes

It’s relevant to note a few things:

  • Not all game designers are as comfortable at each stage, or even as good at the work at each stage. Some are fantastic at having or communicating ideas, while others may be better at problem solving.
  • Not all design disciplines have equal need for all of the stages. If you’re a systems designer you probably need less pure ideation than a narrative designer but you need a lot more balancing.
  • How much time you focus at each stage will depend on preferences, budgeting, staff availability, and many more things.

The only takeaway you need to have from this is that you should know where your design currently is and what that means for the work you need to put in as a game designer.

During ideation, you don’t need to balance anything. During problem solving, you shouldn’t explore new crazy mechanics. If you respect that line you chose to cross before, your game design work will become a lot more predictable and you won’t encounter as much eye-rolling from your colleagues.

Courtroom Intrigue

One of the best games ever designed, in my opinion, is Diplomacy. It originally saw the light of day in 1959, making it much older than myself. It’s also a game I rarely get to play because of its idiosyncracies – it takes a long time to play, it requires seven players, and it has player elimination. There’s a good reason it’s sometimes half-jokingly referred to as “the game that breaks friendships.”

With this background, and what’s been previously written about player v player conflicts in TTRPGs, let’s just say that I really enjoy roleplaying where the characters are at each others’ throats.

Enter Carrion for the Carrion Crows – a mini-campaign (3-4 sessions) built around an imminent war and the nobles who were left behind to govern in their betters’ stead while they were off winning another war.

Have some fun backstabbing your friends!

Subjectivity in Game Design

Is Candy Crush good? Is Dark Souls hard? Is ARMA 3 complicated? Is Battlefield V fast-paced? Is Hearts of Iron IV accessible?

Unlike the academic theories of gravity or evolution, game design is entertainment. This means there’s no such thing as an objective truth. For every player who thinks Dark Souls is hard or Hearts of Iron IV inaccessible, there’s at least one player who disagrees. Loudly.

Metacritic grades and sales figures can tell you something about what reviewers think or how the market is voting with its wallets, but when it comes to a game design’s inherent qualities nothing can ever be objective. We sometimes forget that a game’s financial merits doesn’t necessarily mirror its creative ones.

This often makes the conversation on game design problematic, since two creatives may have widely different opinions on what the right way forward should be, and there’s no unbiased way to make a decision.

Worst case, the decision is made from executive fiat – the boss decides – but what tends to happen is that we start discussing from the only common ground we do have: the design of other games.

Yes, our game should have a Stamina meter, because this works well in Dark Souls.

No, we shouldn’t have a power that lets you fly, because Call of Duty doesn’t have one.

Our game must have a quick-melee button, because Overwatch has one and it’s a lot of fun in Overwatch.

You’d think I’m exaggerating. I’m not. All three are examples from design processes I’ve been involved in.

The Problems of Subjectivity

At a high level, subjectivity makes it impossible to make simple theoretical decisions. Especially when you combine it with the nature of game design as something everyone on a team can have opinions about. If the CEO played a cool game last night, or saw a cool trailer, chances are they’ll swing by someone’s desk the next day and talk about how our game should do the same thing.

Casual banter and brainstorming can become the same conversation as the one about practical implementation and personal tastes will often coexist with other kinds of arguments in a way that makes it hard to consider which is which.

What’s Fun

The first issue is when we talk about what we think is fun. Partly because fun isn’t always a goal and partly because fun is completely subjective. Many players enjoy competition, for example, and play hours upon hours of player versus player games. Personally, I don’t enjoy this, even if I do try many digital PvP games because I like to stay current with what’s released and what’s trending. In my tiny subjective world of single-player games, PvP isn’t “fun.”

But more importantly, pursuing fun can sometimes be detrimental to what you are making. Games like the inimitable QWOP deliberately makes the control scheme frustrating to create a very different kind of fun from almost every other game where running is a feature. And of course, the Resident Evil series thrived for years on having you decide between shooting or moving, building a more intense zombie survival horror experience by doing so.

Basically, arguing on the basis of what’s “fun” is a completely useless argument. Not because someone is wrong, necessarily, but because everyone will be right.

Good and Bad

The mainstream knowledgebase on what’s commonly seen as ‘good’ or ‘bad’ can often be discerned from the more vocal voices in YouTube comment sections or trends in user scores on various platforms. At least that’s how it feels when you observe it.

But picking features or ideas from a good game doesn’t mean your game will gain the same benefits, nor does picking ideas from a bad game mean your game will be bad either. Pretty much every game will have merits of some kind. Technical, aesthetic, mechanical. Dismissing or approving of games based on the common notion of their merits will make you miss interesting and clever ideas.

Just as with fun, using a game’s perceived goodness or badness as an argument makes for a useless argument. Especially if you are using it to evaluate a tiny part of the game.

Feature Prejudice

You’re talking about the player needing a solution to a problem, and you’re looking at games who have solutions to said problem. In most conversations, you’re more likely to use examples from games you think are fun or good, and you will then pick mechanics from those games to solve your problem – even if the problem is completely unrelated.

I was working on a first-person shooter once, where the player moved very fast. It felt nice and supernatural, and we had a lot of fun with it in development. At some point, a long empty segment of hallway was added to the test level. The immediate response was, “let’s add a sprint feature!”

My argument against this had always been that you moved at sprint speed all the time, more or less, and that sprinting would be a very artificial feature. In Call of Duty, as a good example of a sprinting mechanic, the sprinting serves a much more important purpose than giving you a slight boost in speed in empty hallways. You move slower in Call of Duty, partly because sideways movement tracking on a controller is trickier and a slower pace therefore fits the PvP matches, and partly because it’s supposed to emulate more regular soldiers and not superhumans. The sprinting then allows you to cover distances, for example to reach cover, faster, but also robs you of your ability to shoot without first stopping. This exposes you to danger if you didn’t already reach your cover.

Sprinting, in Call of Duty, isn’t just a convenient mechanic – it serves a wider dynamic.

In our case, the sprinting feature was added anyway, “because it’s expected from a first-person shooter.”

This is feature prejudice, where you make the mistake of equating a dynamic with one of its mechanics, and as we’ll get into soon, it’s a direct consequence of our lack of respect for subjectivity.

As with fun, good, and bad, you shouldn’t wantonly borrow mechanics like this.

Game Design Language

We say what’s fun, we say what’s good or bad, and we mistake mechanics for their dynamics. Subjective reality is already wreaking havoc with game design. But there’s another thing that makes it an even bigger issue: there’s no established way to talk about game design objectively.

Most game design books (that I’ve read) go through game design, not in practical terms, but in abstracts. In high level terms. You will learn how to pitch, how to write documents, and possibly read a few paragraphs about what a game is or isn’t. None of it helps you all that much in your day to day work as a designer.

Moreover, few professional game designers have actually read any of these books. Instead, you will often find yourself working in different ways as a designer depending on which company you work at, what kind of games you make, and how senior your position is. You may use a certain technique to solve a problem, and your company will have a name for that technique that you won’t find anywhere else.

One place calls the trail of enemies that leads you to the next door in the linear story “breadcrumbing,” while another calls it “leading,” or “leashing.” You’ll quickly learn the new terms at a new place, of course, but this lack of a proper lingua franca for game design pushes much of the conversation back towards using other games as reference points… and then you’re back at square one – in subjectivity land!

Handling the Subjectivity

Subjectivity is bad, then? No! We just have to remember that it exists and work around it. Understand that our own ideas are not worth more than anyone else’s and define our game on its own terms so that we don’t get bogged down in preference discussions or stuck in designing by reference.

The best part of subjectivity is that we can take ideas that may seem completely disparate, combine them, and our game will be much better for it. But only if we can do it in an informed way.

If anything, we should embrace subjectivity. Take as many perspectives as we possibly can and run them through the gauntlet of discussion and prototyping.

But we must first set the terms for our project, or our design discussions will soon boil down into matches of reference tennis.

Respecting Design as a Craft

One very important step is to give game designers the power to actually control the game design. Just like concept artists, game designers are often the subjects of uninvited scrutiny. Game design, like art, is something everyone can have opinions about. But the fact that people can have opinions doesn’t validate those opinions. A concept artist or game designer is no less of an expert than a rendering programmer or technical artist. The only difference is that the crafts of the former are not as esoteric as those of the latter.

Understand that your opinions are just that – opinions. Also, whatever you do, don’t push things through using clout derived from title or seniority. Even if you’re the CEO, you hired that game designer to be the game designer.

The point being made is: let game designers be the ones to design your game. Let them have the say in the matter and make sure that everyone respects it.

Postpone Your Piggybacking

“Piggybacking” is what you engage in when you borrow wholesale from other games. When you grab that sprint mechanic from Call of Duty, you’re piggybacking on Call of Duty.

But with all these issues of subjectivity now fresh in memory, you can see how piggybacking can actually be a bad thing. If one superfan of Soulsborne games suggests a difficulty level for your game project based on the most recent From Software title, difficulty will be very different from when the Nintendo fan dips into their experiences to do the same.

Because of this, piggyback as little as possible early in a game’s life cycle. Learn to talk about your game using the game’s own terms. Establish pillars and facts and use them as memes in your design conversations. Only engage in piggybacking when you feel that you have a clear identity for your game project.

Using Pillars

The trickiest part of game development is to solidify what your particular game is about. This can be self-explanatory for someone who is simply plugging away at the task on their screen. They just need to finish this task and move on to the next one. But that’s the work, it’s not the product.

Using design pillars is one way to communicate what your game is about. Broad but relevant pillars that can be used as practical expressions in conversations, becoming natural staples in how you define your game. The trick is to communicate what each pillar means, and to communicate it clearly and succintly enough that everyone on the team can make good use of it. It’s something close to what genres are used for among music lovers.

The only danger here is to make pillars that are so generic that they say nothing at all, or so specific that they require too much explaining.

“Fun Gameplay” is a terrible pillar, for example. But “Quirky and Fun” could be a good one, given the right context. It’s fine if a game’s pillars change a few times through the course of a game’s development, but the more solid they are, the better they do their job: to get you away from the subjective conversation and squarely into the objective reality of your particular game.

Stating Facts

From your pillars, you can derive facts. A fact is something you can state as true and can be related to narrative, to gameplay, to the art direction, or pretty much anything else. The trick with facts is to make them extremely specific. Facts should each verify a thing that is true about your game.

Do not use facts based on falsification. I.e., things that are explicitly not true. It can sometimes be necessary, if you have tropes to rule out for example, but shouldn’t be made the norm. Mostly to keep the tone positive. This may sound weird, but believe me – it does have value.

Some sample facts could be:

  • The game has three resources: Blood, Sweat, and Tears.
  • Our main character’s name is G.
  • The main character carries a gun.
  • Guns are rare.

The more succinct and specific each fact can be made, the easier they are to remember and communicate. Filling a wiki or similar with long lists of facts will often end up having the opposite effect, however, which leads us to the next thing.

Writing One-Pagers

The way one-pagers can be used is to put pillars and facts, as they relate to a specific subject, into one single document. Say, the Gunplay One-Pager, or the Grunt Attack One-pager. This can then serve as the basis for any conversation on this topic or related topics.

This works especially well if you organise your teams in a cross-disciplinary way, since it eschews any need for discipline-specific information and gives each discipline ownership of its own respective crafts. The one-pager’s job isn’t to tell everyone what to do – it’s to lay the groundwork of what the goal is for this part of the game.

The traditional Game Design Document, often expected to provide information and detail on everything, will often waste most people’s time because the details in there are simply not relevant to them. A one-pager can keep things succinct and allow people to apply their own specific knowledge to the subject through their own planning rather than as the uninformed details of a game designer on a writing spree.

What’s important with one-pagers is to keep them short, keep them up do date, and to name everyone who is responsible for implementation so that communication can be facilitated.

Demonstrating the Game Iteratively

Facts and pillars summed up in one-pagers for cross-disciplinary teams. There’s your game design. Now go build your game.

One strength of working from a high level where everyone can ultimately understand what the game is about before they set to making it is that everyone can be part of the whole. In a very large project, this may only include the leads and directors, but the best possible situation is where this information is project-wide.

Of course, someone whose specialisation is making shruberry or shoe laces may not even want to know what the game is about, but they may still have cool ideas that can feed back into the larger conversation.

What’s most important of all once you start building things, however, is that a one-pager can be wrong. Once that feature is implemented, reevaluate it. Does it actually fit with the pillars? Should one of these facts be removed, or tweaked?

The more you do this work, the more informed your iteration, and the better your game.

Investigate Your Own Murder

Experimentation in tabletop roleplaying is a ton of fun, and sometimes an idea comes up that’s nothing more than a “what if?”

In the case of Death and Police Tape, which you can download on itch.io, the whole idea was to make a gritty (and gory) freeform horror scenario where you first died a gruesome death and then investigated that same death, having to explain it in a press release. With a new set of characters.

It turns the common GM/player dynamic somewhat on its head and lets the players drive the interesting decisions to be made.

We had a ton of fun with it, and it can be safely played in a single evening. Perfect for Halloween.

Tigers, Horses, and Weird Danish Rock Songs

When you only have a week to write a whole scenario, you often have to stick with the first thing that comes to mind. After a couple of weekends of role-playing this way, there was also many of us. The pandemic made digital hobbies a good way to do social things from the quarantined safety of our homes.

Seven players wanted to play, and the idea was to put them into two distinct groups of characters. Other things that coincided to create the splatstick survival horror scenario The Mustang Sallys was a purchase of the old Swedish OOP Splatter role-playing game. But most of all, it was the random discovery of a weird Danish rock song.

The name and lyrics of the song are NSFW, but let’s just say that I laughed out loud when I heard some of it. Combining it with some of the colorful characters of The Tiger King on Netflix, the story of the scenario basically wrote itself.

You can die from acne, you can die from scabies
You can die tomorrow, you can die tonight
You can die of cholera and you can die of plague
But you can also die of Horse

Quote from the rock song, Google translated from Danish

Credit for the cover image goes to the fantastic Joakim Hellstedt.

Cyberpunk + Heist = Grand Slam

In 2020, with the COVID pandemic in full swing, our regular role-playing group took to Roll20. Before then we used to meet once every week to play around a physical table. Something that sounds strangely exotic when you say it out loud today.

Initially, no one knew how long the pandemic would last. There were of course suspicions (that turned out right), but the idea for these online sessions became to play single-evening sessions and have a bit of fun with whatever we could come up with. We’d then resume our previous campaign once the pandemic was over.

The first of these improvised sessions was based on a poll on the gaming group’s Facebook page.

What do you want to play?

Two things came out of that poll. Cyberpunk and Heist. These were the two things that scored highest out of whatever alternatives that were provided and they became the only real foundation for what would be written.

The following week, Grand Slam saw the light of day. Five prewritten characters and a story that hinges on a gold heist. Some custom rules for hacking were added, custom-made mostly to fit the Roll20 chat we used, and we set off.

It would be three game sessions before we had finished the scenario. It ended with a bang – total party wipe. But we still talk about it fondly, having had a ton of fun.

This scenario is now available at pay what you want pricing, from Itch.io, if you feel like stealing some gold from organized crime.

Hopefully, someone out there can have as much fun with this as we had!

Ways to Not Have Cooldowns

Cooldowns are not features. They were primarily invented to solve problems in the days of latency-riddled networking and limited bandwidth. By setting a server-side cooldown, the server can ignore specified input from a client and make sure that the clock behind the scenes isn’t choked.

Cooldowns have since stayed with games, probably because many of today’s game designers grew up on a diet of World of Warcraft, but also because they’re an effective and immediately recognizable tool for balancing complex features against each other.

But the thing is: all they really do is slap an arbitrary duration on your features. They make something that could be made intuitive and skill-based live entirely in the UI space.

Traditionally, action games never used them, at least not in the ubiquitous HUD progress bars we see today.

So just for the sake of argument, here are some ways you can not have cooldowns.

Buildup

To use the feature you need to hold the button for a duration, for visible buildup, or chain inputs together. The difference from a cooldown is that it’s visible and interactive. Even if it’s still arbitrary, it moves the interaction into the game’s world space and won’t have you looking at the UI all the time.

  • Charging. Hold the button for just the right amount of time, then release. The charged shot in the Metroid games.
  • Chaining. Multiple quick interactions building up to a more massive one. Yoshimitsu’s sword thrust in Tekken.

Tradeoff

Making the feature truly interactive, but with a crucial tradeoff, puts all the power in the player’s hands and once again removes it from the UI space. Rewarding the player for learning to use a repetitive mechanic at the right time will get them closer to the coveted Flow state.

  • Combined Timing. Pull it off for a boost, fail to get penalized. Consider the reloading mechanic in Gears of War.
  • Anticipation. Time it right to avoid a negative effect, time it wrongly to get punished. The self-healing in Stranger’s Wrath is a good example; use it in the midst of combat, and you get killed.

Economy

The most obvious way to limit an interaction is to tie it directly to a resource. This can be something you collect all the time as you play, like ammunition in a survival horror game, or it can be something that accumulates over time automatically.

  • Hard Restrictions. Spells per day in D&D. Number of ammo rounds available in almost every game with guns. If you have the resource, you can use the feature.
  • Durability features. Weapons in Diablo or Zelda: Breath of the Wild. A different theme on hard restrictions, but the same thing in effect.
  • Accumulation and cost. Accumulating a resource along the way, enabling use by removing the accumulated value. Consider the “supers” of many popular multiplayer games, like Destiny 2 or Overwatch; and the resource accumulation and building progress bars in a strategy game.
  • Self-Regenerating Resource. Use the resource while you have it; wait for it to recharge. Stamina in Dark Souls, force powers in Dark Forces 2: Jedi Knight. But also of course health in the Call of Duty games.
  • Powerups. Temporary boosts that enhance specific features or make strong technical exceptions. When you find the Quad Damage in Quake, or the Active Camouflage in Halo, it’s the game’s invitation to make the best of it while you have it.

Context Sensitivity

Communicating a feature in a consistent way and letting the player adopt it systemically is my personal favorite when it comes to restrictions. You know intuitively that wherever there’s a dab of yellow or white paint in a modern adventure game, you can climb, for example.

  • Activation Requirements. Web jumping in Spider-Man; web slinging in Spider-Man. It requires certain prerequisites that become fairly obvious with experience. The aforementioned dabs of paint are also like this.
  • World Requirements. Rope arrows in Thief: The Dark Project only attach to wooden surfaces. Requires that you pay close attention to the world you’re in, and invites experimentation. But also puts more demand on the level design.

Duration

Rather than having the arbitrary cooldown timer to wait for, you can have duration as something that happens because of activation. The time will still be arbitrary, but again it’s something that happens in the game world and not in UI space.

  • Activation Duration. Sprinting in Call of Duty. Many hack effects in Cyberpunk 2077. Activate the thing, use it for the duration, then you can (usually) activate it again.
  • Player-Activated Duration. You know it’ll take a certain amount of time, but you can decide when to do it. Reloading works this way in most first-person shooters. Repairing in Hawken.

Diminishing Returns

Let the player use the feature however much they want, but make it a little less effective every time. Use it too much and it loses its effect entirely.

  • Boost. Morphine in Call of Cthulhu: Dark Corners of the Earth automatically heals you to full health and sanity, but lasts a limited time. Each successive use makes it last shorter.

Endnotes

The pattern you should recognise is that there are many ways you can move the information you need into the game space, away from UI space, without taking away the arbitrary restriction that a cooldown really is.

You’ll still have that cooldown in practice, but it will be represented in a way that at best makes more intuitive sense, and at worst makes the player focus on the game world instead of the frontend. This is always a good thing.

By all means, use cooldowns. Just think of the alternatives before you do.