Understanding “Systemic” in Video Game Development

A while ago I wrote an article about how I don’t want to continue handcrafting all my content, because computers are good at helping us do things faster and removing repetitive work.

In the months that followed, I had a lot of great conversations about systemic design in video game development.

It became instantly clear that even between very smart groups of experienced developers, nobody had the same interpretation of what “Systemic” means, especially as relates to triple-A games.

Many people assumed that “systemic” meant not having a story. Others felt that “systemic” meant not having control over mission design.

The fact is: it’s complicated because a system is a flexible thing, something that game developers can decide how to use, and how much to use. Like the word “mechanism”, the functionality of “system” can be almost anything.

To start to understand systemic design, I propose that designers try to place their needs inside this simple linguistic format:

I want a machine that does X

To be useful, the declaration ‘machine that does X’ should be something manageable, like “I want my world textures to change during an event called [rain]”, or “I want the player to receive an email from the mission giver whenever a mission is completed”.

Anytime a designer can say “I want a machine that does X” in a way that is feasible and actionable, a system could be designed (or expanded) to support their needs.

If the declaration is too “big” to be useful, e.g., “I want my levels to make themselves” then they need to be broken down into smaller declarations, like “I want the terrain of my levels to generate permutations automatically, on track with the defined metrics for player and vehicle navigation”. (This last thing is typically called “procedural” rather than “systemic” because you’re using a system to create content, often offline.)

In time, thinking and working this way should lead to designers building games that have a lot of [machines that do X]. In other words, a lot of systems.

As usual, I’m using the word “Designer” to refer to “Game Designer” and “Level Designer” kind of interchangeably; I don’t see a useful distinction between these skill sets.

Games in which much of the player experience is produced by systems, can be said to be “systemic”. Each dev team will determine what parts of their game can be produced by [Machines that do X].

Good Systems Add Fun To Other Systems

The more hours of high quality player experience which can be produced using system X, the more valuable system X is as a production asset. This creates a temptation to make monolithic systems, but if you remember from the previous exercise: [Machines that do X] are much better to design in small chunks.

Instead of making monolithic complex systems, it’s better to build collections of simple[Machines that do X] which are compatible with each other, providing interactions that create cool player experiences.

Let’s say I’m making a game which takes place on a jungle planet deep in outer space. Let’s say I am making a weather system, and my [Machine that makes weather] for my planet creates sunny days, clear nights, rain storms, and fire meteor showers.

Now, if my Lizard Monster AI systems are “aware of” the weather system, then my Lizard Monsters will flee fire meteors, and not see as far through the jungle during a rainstorm. The combination of these two systems leads to more interesting interactions, and better player experience.

On the other hand, if my Lizard Monster AI system doesn’t work with the weather system, my Lizard Monsters might look stupid during fire meteor showers, and interacting with Lizard Monsters during weather events would be exactly the same all the time, which is less interesting.

A Useful Lens For Systemic Structure: Data

I talk about data structures a lot, and it’s really about who needs to touch the data. Once you start to have several [Machines that do X], you will likely at some point spend time deciding which functionality should go inside which system. At this point, it can be useful to focus on the needs of your design team.

To take the simplest example: designers and artists working on world assets and terrain will always be the most-informed people on your team regarding your worlds/levels. Knowing this, you will probably want to design your navigation mesh generation and AI behavior tools and systems in such a way that the “world making team” will create data that relates to navigation, instead of the designers working on NPC behavior.

Build the relationships between your [Machines that do X] in a way that makes sense for the needs of your developer population.

Why Is “Systemic” Good, Again?

Certainly there are occasions where handcrafted content is a workable solution — I've shipped a few “boss fights” wherein the entire logic of the encounter is driven by the level script, effectively a chunk of code that cannot be reused anywhere else in the game. Most high-quality games feature memorable “one time” moments that are readily addressed by a content-driven approach.

Still, if designers are empowered to create systems as they work, they end up with more and more hours of player experience that can be produced by combining systems in inexpensive ways, allowing developers to give players more gameplay bang for the publisher buck.

Remember, a “system” can be anything developers want it to be. A system is simply a [Machine that does X], created by a designer for a specific purpose.

Systemic content can be translated to “player experience driven by various systems”, in games that feature whatever combination of systemic and handcrafted content their developers wanted to give their players.

Thinking about game production from a systemic perspective is just an approach, one which offers as its incentive the chance to create endless worlds, populated by systems in interesting ways.