New to Narrative

Design and storytelling resources for game makers, old and new.

A grid filled with fire icons. There's a small character standing next to a car icon that's also on fire.
Home » Blog » Systemic Game Design and How to Apply It To Storytelling

Systemic Game Design and How to Apply It To Storytelling

I’ve often wondered what would happen if we hammer the Venn diagram of overlapping creative fields into a circle. Game design is a field that excels at making a player’s actions feel impactful. Writing on the other hand engages readers on an emotional level through tailored prose and interesting dialogue. Today, we’ll be taking a look at what systemic game design principles are and how to apply them to storytelling, with the aim to create a world that feels alive and reacts to the player’s actions.

Preview

  • 10 Minute Read
  • Beginners/Intermediates
  • Useful for text-heavy games and interactive fiction

Video

If learning by video is more your pace, check it out here!

What is systemic game design anyway?

If you’re working in game development, you might have heard this term thrown around before. I won’t bother with trying to define it in technical jargon, instead, I’ll jump straight into a concrete example. 

Let’s say our game has a Molotov Cocktail item. If the player throws it at something, it will set fire to whatever is touching it. In more traditional design, we would manually define what we can and can’t set fire to. For example, we define that yes, we should be able to set a Police Car on fire. But then what happens when you throw it into a lake? We want to remove the Molotov Cocktail and it doesn’t set fire to anything. Then, a programmer would write code to destroy the Molotov Cocktail when it touches a Lake and other code to allow a Police Car to burn when the Molotov Cocktail touches it.

An example of traditional game design using a grid with a player character, police car, trees and a lake. They do not interact.
An example of game design with traditional interactions

In systemic game design, we would create a separate system that takes care of all those manual definitions for us. That system is completely independent and will have no notion of anything outside of its responsibility, which in our case is setting things on fire. We create a Flammable flag and a Fire flag. The programmer writes a system that says that whenever something with the Flammable flag touches something with the Fire flag, it removes the Flammable flag from it and attaches a Fire flag instead.

(Note that I use the word flag here to mean any method of designating an object. Depending on your field or project, flag can be substituted for tag, label, component, etc.)

Let’s attach the Flammable flag to the Police Car. After that, we attach the Fire flag to the Molotov Cocktail. Just for fun, let’s attach a Flammable flag to all the trees in our game as well. Now, when you throw a Molotov Cocktail on a Police Car, it will be set on fire. However, any Trees touching the Police Car will also be set on fire and so will any other Trees adjacent to those. We suddenly have a forest fire on our hands!

An example of systemic game design using a grid with a player character, police car, trees and a lake. The top trees and police car are on fire.
An example of systemic game design in action

But what about the interaction with the Lake we had in our traditional design example? We create another system that says when something with the Wet flag touches something with the Fire flag, it removes its Fire flag completely. We then attach the Wet flag to the Lake. The Molotov Cocktail touches the Lake and its Fire flag is removed, so it doesn’t burn anything anymore. Note that this particular Wet system doesn’t know anything about the Flammable flag because that is outside of its responsibility.

We can also add a Wet flag to a new item: the Bucket. Now, when you throw a Bucket on anything that’s on fire, it will automatically extinguish it, without manually defining every individual interaction between Buckets, Trees, Police Cars, Lakes, and Molotov Cocktails. Hopefully, the possibilities of this kind of design are sparking your imagination already!

Systemic games use multiple of these systems to create a reactive playground for the player to interact with. A somewhat recent example is ‘The Legend of Zelda: Breath of the Wild’ series, where a big part of learning the game is experimenting to see how the world’s systems react to your input. Did you know in that game you can cook an egg by tossing it into a hot spring, for example? I invite you to figure out what flags and systems might allow that to happen!

How can systemic design enhance storytelling?

Systems like these can generate entire worlds too, like in ‘Dwarf Fortress’. Even though Dwarf Fortress has no story in the traditional sense, simply interacting with its reactive world causes a sequence of events you can interpret as a story. There’s even a website dedicated to stories like that, where people come up with entire Shakespearean plays based on what is essentially a bunch of systems reacting to each other. (Update: the site seems to be offline at time of writing, so here’s a Tumblr alternative.)

Apart from generating entire worlds, I’ve found that taking these systemic game design principles and applying them to game narrative can offer a more immersive experience to players as well. Especially in large open-world games with many NPCs, dialogue can get repetitive quickly unless you write loads of script by hand.

Let’s say we’re making an open-world game, with hundreds of NPCs. Realistically, we won’t have the time to give all of them unique and interesting dialogue, so we’re resorting to writing some shared generic interactions. At some point, the player will tire of seeing “Greetings, traveler” for the hundredth time. It makes the world feel robotic, as though all characters are animatronics waiting to deliver their line.

We want to introduce some reactivity to the world: characters should respond to the player’s actions and achievements. Let’s say the player picks up a Relic, and we want characters to give some information about that Relic. But if all characters were to react to it, it would feel robotic again.

In a traditional branching narrative game, we would create a unique character, let’s call her Prequildo. We would then write her a set of responses based on whether the player is carrying a Relic or not. It would look something like this:

Prequildo: “Greetings, traveler.”

If Player has Relic:

“Ah yes, you have brought me the infamous Magnetic Egg! Fabled for its magic proteins and ability to stick to metal surfaces, yada yada…”

If Player does not have Relic:

“Please come by whenever you’ve found a Relic.”

But that’s just one character in a sea of hundreds. The chance that the player will stumble into Prequildo while carrying a Relic is tiny, so this interaction will likely not see the light of day.

If we take a systemic approach, instead of defining this dialogue specifically for Prequildo, we would create a flag called Antiquarian. In this case, an antiquarian would be someone who has knowledge of old things, including relics. Then we create an independent system that checks if a character with the Player flag is interacting with a character with the Antiquarian flag. If it is, check if the player has a Relic, and if they do add that dialogue to the current interaction.

Then we attach the Antiquarian flag to 20 NPCs in the world and suddenly the player has a 1/5th chance to run into this interaction. Don’t quote me on the maths.

How to make repetitive interactions feel more unique?

If the player encounters the Relic interaction multiple times, they will see through the façade and we’re back to feeling robotic, even though it is a reactive event. We’re going to discuss a few tricks to help with that.

Trick 1: Artificial Scarcity

The first trick is simple: just remove the interaction from the game after the player reads it for the first time. If you read a piece of script that reacts to something you’ve done and then never see it again, it will feel like a uniquely tailored event in the long run.

There are smart ways to remove, replace and add interactions to a pool of potential encounters so that you can recycle the content you’ve written, but it can get a little complex. Perhaps I’ll dedicate an entire article to this at a later date!

Trick 2: Hide the System

Never let the player in on the secret. If you reveal any information to the player that might tip them off about how the systems work, see it as an opportunity to make your narrative more reactive.

Let’s say, if the player picks up the Relic, they receive a quest. The quest reads something like “Find out more about the Relic.” with the objective of “Bring the Relic to an Antiquarian.” You then mark all the Antiquarians on the map and the player chooses the one that’s nearest.

The problem is, players will figure out that the whole Antiquarian system is generic and not unique. Instead, what we can do is see if the player has already met an Antiquarian in a systemic way. We can make a system that adds a new flag called Met to characters that the player has interacted with before. 

Then, we go through all characters with a Met and Antiquarian flag and fetch the name of the first character that satisfied those conditions. In this case, it brings up Prequildo. This way we can replace the objective “Bring the Relic to an Antiquarian.” with “Maybe Prequildo knows something…” Not only does the game now react to the player having met Prequildo, but it also creates an opportunity for the player to revisit a character they already know and potentially build a relationship.

Alternatively, if the player runs into another Antiquarian by coincidence, we can check the Met flag to add some more reactivity as well. That would look something like this:

Antiquarian: “Greetings, traveler.”

If Player has Relic and Antiquarian does not have Met:

“Is that a Relic you have there? I’m, like, super into Relics, here let me see!”

If Player has Relic:

“Ah yes, the infamous Magnetic Egg! Fabled for its magic proteins and ability to stick to metal surfaces, yada yada…”

That’s fun! We have created the possibility for a little player story where the player meets Prequildo > finds the Relic > heads back to Prequildo > incidentally encounters another character who knows about Relics.

Of course, right now it’s still incredibly simplistic, but adding more of these systems grows the possibility for a player story that feels reactive and unique to their playthrough. You can probably already imagine creating other systems like this for your world: faction reputation, character personalities, religions, laws, etc.

Conclusion

Applying systemic game design principles to your writing nets you the efficiency of writing generic dialogue while also adding reactivity to your world. That, in turn, creates more possibilities for a player to experience a story unique to their choices. This way of writing is especially useful for games with loads of content and a lot of interaction from the player, like open-world sandbox games!

The downside, of course, is that recycling generic dialogue might suppress an individual character’s voice and personality. I would not recommend relying too much on these systems for games with a small number of complex characters with strong, iconic personalities.

Thanks for reading! If you want to get notified of the next blog post on similar subjects, you can subscribe to my weekly email newsletter over here:

TLDR

What is systemic game design?

In systemic game design, we create separate, independent systems that are responsible for a specific interaction, as opposed to manually defining interactions between each object in our game.

How can systemic game design enhance storytelling?

Systemic design principles can be applied to story interactions, like NPC dialogue, to make the world react strongly to the player’s actions.

How can I make repetitive dialogue more unique?

You can use a combination of artificial scarcity, hiding information from the player and spacing out content to make repeating or generic dialogue more unique.