Games Have Three Legs

Stuffed Wombat, a game designer as good at reasoning about games as he is at making them, wrote a post where he posited that a game’s construction can be split into two groups, or two legs. The first group contains what are called systems, which are the verbs of the game. You click, you jump, you get shot, you die; grab, lift, throw, run, these are how the game feels to the player. The second group is content, which is more ephemeral, but in general includes the objects we see: a brutish enemy that walks slowly, a block that bounces when jumped on, or a sword with a poison tip.

Although building games under this framework cannot make a bad game any better, it is still useful for presenting what we have been exploring here at MLC, that is Procedural Functionality. Before diving into this, though, let’s expand on this idea of systems and content and how they relate to one another.

The Left Leg: Systems

Games now almost entirely run themselves. This is far from what the first video games were like, which were player-centric experiences. Instead, you as a player now almost assume that what you do is within a larger world, and not just in a hand-wavy, let-me-slip-in-some-background-dialogue way. Enemies are not creatures born to kill the player, but sit, stand, perhaps talk with each other, or lose interest. They do this all while we might be on the other side of the map, solving a puzzle. It is the same with environments, weather, and whatever else the world might contain. More now than ever before, are we seeing games where the player’s melody on the controller has less creed on the game’s execution. Players are merely one ingredient in a larger, simmering system stew.

The key word here is system. Systems are core game loops that run and execute functionality. Functionality might be a player running about and exhausting a stamina supply, or a Minecraft sand block suddenly registering a vacancy and falling down, or a rotten zombie turning at the sound of a noise. All of these behaviors are functional responses to an object’s environment. It is, arguably, systems and functionality that characterize game objects.

To push this to the limit, you could go so far as to argue that if the graphics and art of the game were washed away and reinvented by one of the many artistic visionaries out there, the games systemic operations would still remain, and therefore the game’s functional feel would remain. Of course, this point is moot because an important part of our understanding of games is through their visual design. A stone block that looks like water would be very hard to reason about. But still, for some games this holds.

On a side...
On a side note, this is part of the reason that machine learning struggles so much with learning Minecraft from scratch. Not only does it have to learn how to play, but it must also learn what a pickaxe is before it can use one. Our visual biases are important.

In general though, the point is that systems and functionality in their purest form can be thought of as separate from their counterpart, content.

The Right Leg: Content

Content is murky. The easiest boundary to cleave content from the rest of the game is by saying it is the art. This might be all the visuals that happen that have no direct influence on the game’s execution. Undoubtedly, these are important.

Another way to think about content is as a coagulation of functionalities. Again, using the example of Minecraft, gravel is one type of block, of the many possible types of blocks. A block is aware of many systems, such as one for updating its state, one for triggering drops on destruction, or conditions for when the block is damaged. By specifically defining the functionalities for these systems, we create a piece of content for the game. For gravel in Minecraft this might look like a functionality that drops flint with a certain probability when destroyed, a functionality that allows the block to be damaged by any tool when struck, and a functionality that makes the block fall when the block below disappears.

Standing Tall: Systems And Content

Part of the murkiness around content is that when we talk about a game’s constituents, we do not have a good word to separate content, the artistic skin of the game, and content the assemblage of many functionalities. To avoid mixing concepts up when talking about these two different definitions, it is easier to use more specific terms. Content that is purely visual, such as graphics, visual effects, and animations, are best called assets. Then, the objects that are compositions of unique functionalities can be called just content.

Sometimes the distinction...
Sometimes the distinction between content and assets can be difficult. For example, are collision boxes part of content or assets? They are a functionality, where the system is collision resolution and the unique functional behavior of that system is defined by the collision geometry. Therefore, they are part of content.
For the programmers...
For the programmers out there, another way to think about content is as classes in object-oriented design, the systems they are involved in as ‘interfaces’. Interfaces are ‘contracts’ which classes can subscribe to using. One class can have many interfaces, and if another piece of code is aware of this, it can make use of that class’s interface functionality. Interfaces attached to game objects are in some way similar to the idea of systems, which are contractual design decisions in a game. Interfaces don’t provide us with an implementation, but they tell us what we should implement. It is the same with functionality, which is an object’s implementation of a specific system.

Running Start: The Systemic Era

Games are becoming complex systems. Most of this has been, in part, due to the rise of systemic games. Systemic games are games with so many systems that they enter the emergent regime; they become unpredictable, surprising, impossible to unravel with logical steps. This is only a recent achievement in games because it involved a redesign in how they were built. Rather than big, bloated monolithic systems, systemic games have tiny modules of which one entity in a game might have hundreds. By architecting in this way, game designers unlocked a content canvas. With this new structure, designing games with more content involves recombining these pre-built systems in interesting ways. As the player smashes and crashes these together, the diversity of content produces a diversity of outcomes. A great recent example is LoZ: Tears of the Kingdom (see this GDC talk from Breath of The Wild), not just for its crafting system, but also its weather, enemies, and objectives; these are all gorged with micro-systems that have complex interactions. There are many other games that deserve the systemic game badge: Deus Ex, Dishonored, Dwarf Fortress (rogue-likes are a popular genre for this), No Man’s Sky, Minecraft – so many the list would go on.

But what is next? Although there have never been more game designers than now, and we are only growing, we are still far from any clear ceiling. One clear expansion point can be seen when we look at what systemic design involves. Despite having a range of Lego-esque units to build out complex content with, there still remains one challenge: someone must manually compose these Lego-esque units before putting them together. Take Minecraft blocks. There are an impossible number of possible blocks that could be made – the modding community has shown us this – yet still some game programmer must sit down and program every possible block function we want the player to experience. This is the same for games with different weapons – even with advanced weapon systems like Noita – enemy behaviors, or objectives. This hints to what the real bottleneck for emergent gameplay is right now: human-designed content functionality.

Imagine if any content could be procedural at the functional level. Some content, such as environments and systems disguised under parameterised representations, have started to go in this direction. Minecraft and Noita are two good examples of parametric-based procedural enemy behaviour. We believe, though, that it should be possible for any content to be procedural and for game design to move into a new chapter: the era of Procedural Functionality.

Another term we...
Another term we have used for Procedural Functionality is Automatic Modding or Auto-Modding. The naming implies that the concept of modifying the game’s codebase (and assets) after the game is released is now automated, and therefore becomes part of the gameplay itself. We will elaborate more on this in a future post.

Leg Number Three

What this Procedural Functionality era will look like, right now we can only wonder because the tools out there don’t allow for easy experimentation. But at MLC this is exactly what we are building. We want to try to understand how these new games can be built, to explore what game design means in this space, and to build community tools that can support game developers that are interested in learning more.

At MLC, we see a future of games developers who are not constrained by how quickly they can script all their agent’s behaviours, write all their weapon attack responses, or invent a procedural framework for their items. Rather, they can build very complex systemic designs, but allow for procedural functionality (and the player’s creativity) to take the game and run with it.

Stuffed Wombat, a game designer as good at reasoning about games as he is at making them, wrote a post where he posited that a game’s construction can be split into two groups, or two legs. The first group contains what are called systems, which are the verbs of the game. You click, you jump, you get shot, you die; grab, lift, throw, run, these are how the game feels to the player. The second group is content, which is more ephemeral, but in general includes the objects we see: a brutish enemy that walks slowly, a block that bounces when jumped on, or a sword with a poison tip.

Although building games under this framework cannot make a bad game any better, it is still useful for presenting what we have been exploring here at MLC, that is Procedural Functionality. Before diving into this, though, let’s expand on this idea of systems and content and how they relate to one another.

The Left Leg: Systems

Games now almost entirely run themselves. This is far from what the first video games were like, which were player-centric experiences. Instead, you as a player now almost assume that what you do is within a larger world, and not just in a hand-wavy, let-me-slip-in-some-background-dialogue way. Enemies are not creatures born to kill the player, but sit, stand, perhaps talk with each other, or lose interest. They do this all while we might be on the other side of the map, solving a puzzle. It is the same with environments, weather, and whatever else the world might contain. More now than ever before, are we seeing games where the player’s melody on the controller has less creed on the game’s execution. Players are merely one ingredient in a larger, simmering system stew.

The key word here is system. Systems are core game loops that run and execute functionality. Functionality might be a player running about and exhausting a stamina supply, or a Minecraft sand block suddenly registering a vacancy and falling down, or a rotten zombie turning at the sound of a noise. All of these behaviors are functional responses to an object’s environment. It is, arguably, systems and functionality that characterize game objects.

To push this to the limit, you could go so far as to argue that if the graphics and art of the game were washed away and reinvented by one of the many artistic visionaries out there, the games systemic operations would still remain, and therefore the game’s functional feel would remain. Of course, this point is moot because an important part of our understanding of games is through their visual design. A stone block that looks like water would be very hard to reason about. But still, for some games this holds.

On a side...
On a side note, this is part of the reason that machine learning struggles so much with learning Minecraft from scratch. Not only does it have to learn how to play, but it must also learn what a pickaxe is before it can use one. Our visual biases are important.

In general though, the point is that systems and functionality in their purest form can be thought of as separate from their counterpart, content.

The Right Leg: Content

Content is murky. The easiest boundary to cleave content from the rest of the game is by saying it is the art. This might be all the visuals that happen that have no direct influence on the game’s execution. Undoubtedly, these are important.

Another way to think about content is as a coagulation of functionalities. Again, using the example of Minecraft, gravel is one type of block, of the many possible types of blocks. A block is aware of many systems, such as one for updating its state, one for triggering drops on destruction, or conditions for when the block is damaged. By specifically defining the functionalities for these systems, we create a piece of content for the game. For gravel in Minecraft this might look like a functionality that drops flint with a certain probability when destroyed, a functionality that allows the block to be damaged by any tool when struck, and a functionality that makes the block fall when the block below disappears.

Standing Tall: Systems And Content

Part of the murkiness around content is that when we talk about a game’s constituents, we do not have a good word to separate content, the artistic skin of the game, and content the assemblage of many functionalities. To avoid mixing concepts up when talking about these two different definitions, it is easier to use more specific terms. Content that is purely visual, such as graphics, visual effects, and animations, are best called assets. Then, the objects that are compositions of unique functionalities can be called just content.

Sometimes the distinction...
Sometimes the distinction between content and assets can be difficult. For example, are collision boxes part of content or assets? They are a functionality, where the system is collision resolution and the unique functional behavior of that system is defined by the collision geometry. Therefore, they are part of content.
For the programmers...
For the programmers out there, another way to think about content is as classes in object-oriented design, the systems they are involved in as ‘interfaces’. Interfaces are ‘contracts’ which classes can subscribe to using. One class can have many interfaces, and if another piece of code is aware of this, it can make use of that class’s interface functionality. Interfaces attached to game objects are in some way similar to the idea of systems, which are contractual design decisions in a game. Interfaces don’t provide us with an implementation, but they tell us what we should implement. It is the same with functionality, which is an object’s implementation of a specific system.

Running Start: The Systemic Era

Games are becoming complex systems. Most of this has been, in part, due to the rise of systemic games. Systemic games are games with so many systems that they enter the emergent regime; they become unpredictable, surprising, impossible to unravel with logical steps. This is only a recent achievement in games because it involved a redesign in how they were built. Rather than big, bloated monolithic systems, systemic games have tiny modules of which one entity in a game might have hundreds. By architecting in this way, game designers unlocked a content canvas. With this new structure, designing games with more content involves recombining these pre-built systems in interesting ways. As the player smashes and crashes these together, the diversity of content produces a diversity of outcomes. A great recent example is LoZ: Tears of the Kingdom (see this GDC talk from Breath of The Wild), not just for its crafting system, but also its weather, enemies, and objectives; these are all gorged with micro-systems that have complex interactions. There are many other games that deserve the systemic game badge: Deus Ex, Dishonored, Dwarf Fortress (rogue-likes are a popular genre for this), No Man’s Sky, Minecraft – so many the list would go on.

But what is next? Although there have never been more game designers than now, and we are only growing, we are still far from any clear ceiling. One clear expansion point can be seen when we look at what systemic design involves. Despite having a range of Lego-esque units to build out complex content with, there still remains one challenge: someone must manually compose these Lego-esque units before putting them together. Take Minecraft blocks. There are an impossible number of possible blocks that could be made – the modding community has shown us this – yet still some game programmer must sit down and program every possible block function we want the player to experience. This is the same for games with different weapons – even with advanced weapon systems like Noita – enemy behaviors, or objectives. This hints to what the real bottleneck for emergent gameplay is right now: human-designed content functionality.

Imagine if any content could be procedural at the functional level. Some content, such as environments and systems disguised under parameterised representations, have started to go in this direction. Minecraft and Noita are two good examples of parametric-based procedural enemy behaviour. We believe, though, that it should be possible for any content to be procedural and for game design to move into a new chapter: the era of Procedural Functionality.

Another term we...
Another term we have used for Procedural Functionality is Automatic Modding or Auto-Modding. The naming implies that the concept of modifying the game’s codebase (and assets) after the game is released is now automated, and therefore becomes part of the gameplay itself. We will elaborate more on this in a future post.

Leg Number Three

What this Procedural Functionality era will look like, right now we can only wonder because the tools out there don’t allow for easy experimentation. But at MLC this is exactly what we are building. We want to try to understand how these new games can be built, to explore what game design means in this space, and to build community tools that can support game developers that are interested in learning more.

At MLC, we see a future of games developers who are not constrained by how quickly they can script all their agent’s behaviours, write all their weapon attack responses, or invent a procedural framework for their items. Rather, they can build very complex systemic designs, but allow for procedural functionality (and the player’s creativity) to take the game and run with it.

by Levi

by Levi