System-Oriented Design

System-Oriented Design

System-Oriented Design

Building your game with Systems will streamline your design process and keep your game compartmentalized and agile.

These days, we often hear a lot about game mechanics. Some designers choose to start with mechanics, and then consider theme and experience later. This style of “bottom up design” tends to create games which feel ‘mechanical’ or ‘math-y’.

Not to say that inventing mechanics is a bad idea. When you get a great idea for a mechanic, you should absolutely write it down, and look for a game to use it in. 

Rather than talking about mechanics as the fundamental component of gameplay, it’s much more useful to consider systems.

What is a System?

A system is a set of interlinking rules, resources, mechanics, and components that work together to create functionality in a game. 

Said more simply, the system is everything that’s in between the player’s strategy (input) and its results upon the game state (output). Systems might be complex or simple, but the game lies in those black boxes. Picking them apart is the fundamental joy of gaming.

In the example above, you can see that Bullet's Pattern system is implemented to achieve specific features. Many components and rules combine together to support this system. Many of those components and rules are re-used by other systems, but this example considers only the context of the Pattern system. 


Designing Systems

A system can be used to implement the game’s features. A well-built set of systems implementing the features will reliably create the target experience of the game.

The best way to start with a system is to think about how a thing works in the real life. If you’re building an economy for your game, start with real money and think about how it moves in the context of your game. Then go back to your mental list of mechanics, and ask “what mechanics will implement a system like this?”

When prototyping, you can build a prototype that just answers questions about an isolated system, rather than building the whole game.

Simple vs. Complex Systems

The place where I like to draw the line between Simple and Complex in terms of systems is when multiple players get involved.

In a Simple system, there is only a single strategy acting on the system. The player should clearly understand the outcome or possible outcomes of their actions.

A system like inventory management or a fixed-price market to exchange resources could be considered Simple. A game like roulette is also a simple system.

Once you have two or more strategies inputting on a system, each trying to achieve different outputs, and largely agnostic of the other inputs, then the system has become Complex. In a Complex system, the output is not so certain, because the interaction of multiple strategies creates the outcome.

In the example with Exceed, no one player understands what outcome their attack will create, because there are multiple inputs working on the system simultaneously. This means that there is a chance for a player to fail, depending on the conditions of the other strategy.

Contrast this with Bullet's Patterns above—when a player wants to use a pattern, the outcome of the action is very clear. When a player wants to strike in Exceed, the outcome is less certain. That uncertainty is a hallmark of complex game systems.

Successful Systems

The system fulfills the target experience if both the inputs and outputs map logically according to their real-world experience or understanding. 

For example, I know that in the real world, when someone else gets in line first for a haircut, I have to wait for them to finish before I get my haircut. If there was a second barber, I could also step in and fill their slot. Then the third player would be forced to wait until either barber is free.

Sounds like a game mechanic, right? Worker-Placement mirrors this situation very closely. And that’s where Worker-Placement works—it simulates a real-world problem of a service-commodity with limited supply and competing customers. 

When used in systems mirroring this situation, it creates a seamless experience. When used out of place, it feels mechanical. 

Linking Systems

The barriers between systems are a useful abstraction, but there are no rules or limits on the game designer. You can link systems in any way, so which ways should you?

Said another way, you could make the purchase of a haircut affect the market price of wood if you want to, but it’s probably not a good idea.

For example, you could imagine that the top box is a system by which players produce lumber, and the bottom box is a system for preserving wildlife habitats. The actions players take in the lumber market directly affect how well they're able to conserve wildlife, making these two systems linked.

Whenever a system uses the game state to determine its output, it becomes linked with any system which can affect that state.

The advantage of using systems is that they remain atomic and are not tightly coupled. Limiting the interconnectedness of the systems will make the game easier to design and easier for your players to understand.

Ideally, it’s good to have multiple different links to keep systems distinct. If buying lumber is only linked to wildlife conservation, the two are effectively one system. If lumber buying is linked to both conservation and to the ability to build dams (which is itself linked to conservation), the systems start to feel more distinct, each one pushing and pulling on the others to create a web of points where the players can apply force.

When linking, try to make the links clean and intuitive. Links between systems should be logical results of the experience you’re creating.

Here's a look at how Millennium Blades links together various game systems into a cohesive whole.

In this article, we talked a lot about inputs and strategies. Next time, we’ll learn about Strategy-Centered Design, and how to wrap your systems around the goals of players.