The SSM Framework of Game Design

This article goes over a framework for understanding how videogames work. It divides games into systems, story, and a mental model, and then shows how these interact. Using this system makes it easier to make design decisions and enables one to have insights into the workings of a game.


I've previously talked about story and mental models, and now it's time to wrap it all up into one neat framework. By looking at how these aspects influence one another it's much easier to talk about a game, and it also allows us to draw some fresh conclusions. In this post I'll go over the basic framework and then discuss how it can be applied to gameplay.

It's worth noting that this is by no means the only way of looking at games, nor does it take into account every single aspect of what games are. I think it's broad enough and covers enough ground to be really useful, though. In fact, it'll be used as a foundation for many of my upcoming articles on design. With that said, let's start.

The first thing you need to realize is that all games work in three different spaces: System, Story and Mental Model. These are the building blocks of the entire framework and I'll henceforth refer to this as the SSM-framework. This theory derives a few of its basics from the MDA framework, so it feels right to briefly go over that. In the MDA framework, games are divided into Mechanics, Dynamics and Aesthetics. The mechanics are the basic building blocks of a game, the dynamics are how they work together, and the aesthetics describe the user experience[1]. All of these different components are layered and dependent, so mechanics give rise to dynamics and dynamics give rise to aesthetics.

While I think the MDA approach to looking at games can be really helpful, it doesn't properly separate the player's understanding of the game from the actual behaviour of the game. That's the main thing that the SSM Framework tries to fix. The way it does this is by viewing a game as something that takes place in the three spaces I mentioned earlier: Story, System and Mental Model. Now let's go through each of these.

---

System
The System space is where all of the code exists and where all of the game simulations happen. It's here that things get done. We can divide this space into two layers: Mechanics and Dynamics. This is incredibly close to the MDA framework, with the exception of the Aesthetics layer. It's also important that the mechanics and dynamics here are abstract; we don't take any account of how they are presented to and understood by the player. System space only concerns itself with functionality.


Story
Story, as explained in this previous post, is what gives context to the things that happen in System space. In Super Mario's system space, a fireball is just an abstract object with bounds that trigger a particular event on collision. It's in Story space that it looks like a fireball, which helps the player intuitively understand what sort of threat they are dealing with. Sometimes the Story space is very thin. For instance, in Tetris the visuals are basically just a direct visualization of the system space. In other cases, the Story space can be very thick. A good example of that is The Walking Dead where the systems are supported by hours of non-interactable Story-space cutscenes.

Just like the System space can be divided into two layers, so can Story space. At the bottom layer we find the Mis-en-scéne, which is basically everything that the player can see, hear, and in other ways reach their sensory organs. This is a term borrowed from film and I think it best encapsulates this component of the story layer. In the layer above that we find Drama. Just like the Dynamics of System space, this is something that is generated by the layer below, in this case the Mis-en-scéne. Here's a quick example of this: In Super Mario, the character of Bowser is part of the Mis-en-scéne and the fact that he does not like Mario is Drama. Just like with Mechanics and Dynamics, there is some overlap between the two, but they are still separated enough for it to be a useful distinction.


Mental Model
Finally we arrive at the Mental Model space. It's hard to quickly summarize exactly what a Mental Model is, and the best thing really is to read the previous blog that discusses the subject. In very simplistic terms the Mental Model is the player's personal experience of the game, making it similar to the Aesthetics of the MDA framework. The big difference is that while it does derive from what happens in a game's Mechanics and Dynamics, it is thought of as its own separate space. When you join together the three different spaces, it looks like this:

It is when the Story and System space are experienced together that a Mental model is formed. I think it's incredibly important to think of this as a separate space, because just like System and Story have their components, so does the Mental Model. At the basic level you find Affordances. This is basically the functionality that the player attributes to a perceived object, e.g. that a door is something that can be opened. Then at a layer above that you find Schemas, which is how the player thinks they should behave in various situations and how these situations ought to play out.

This is a quite rough division of layers and as before there is overlap. There are also further details to take into account, such as the player's emotional responses and so on. Normally, you wouldn't think of these as part of, say, Affordances, and if you wanted to you could make the components of the Mental Model space quite complex. I feel that for a framework to be useful it needs to simplify things and as a start Affordances and Schemas work quite nicely. It's not at all that different from Mechanics and Dynamics; these are widely used concepts in game design despite not being exact expressions.

A final important note about the Mental Model space is that it doesn't necessarily need to contain things from either System or Story space, it can be things that the player makes up from their own imagination. For instance, certain items might disappear when they are out of view for a long time. The player might form the Mental Model that that this is due to some gnomes, despite neither System nor Story space contains any such information. This is very common, and a large part of the Mental Model space is usually taken up by these kind of imaginary entities, actions, etc. Sometimes a game is designed for this, other times it is purely accidental.

---

With the basics laid down let us discuss how the SSM Framework describes a game loop. Here is a an overview for how it all works:

Click to enlarge.

The steps are as follows:

1. The users triggers an input on the controller and this data is sent to System space.
   Example: The fire button is pushed.
2. System space handles the data, does all the required simulations and then generates a bunch of abstract data.
   Example: The trajectory of the bullet is calculated, a collision is found, the hit points are lowered for the object and this causes the object to transition into the "exploded" state.
3. This abstract data is sent to the Story space, where it is given context.
   Example: The game changes various numbers which are used by various graphics components to produce output. The "exploded" event triggers a particular sound file to be played.
4. A collection of sounds, animations, graphics and so forth is produced.
   Example: The bullet is animated as a flying projectile. It is seen hitting a barrel which then explodes to the sound of a loud "Boom!".
5. This Story generated content gets sent to the various sensory organs of the player. The most common are the eyes and ears.
   Example: The player hears and sees the explosion.
6. The player's sensory organs sends the data to the brain where it is processed in various ways. We are now entering the Mental Model space of the game loop.
   Example: The player recognizes the bullet and barrels as those objects. It's also clear that the bullet hitting the barrel caused an explosion event. This, together with the boom sound, gives the player a feeling of satisfaction.
7. The player's impressions are fed into the current mental model.
   Example: This is the first time the player witnesses a bullet making a barrel explode.
8. Using the new data, the mental model is updated.
   Example: The player is now aware that shooting barrels will make them explode and cause satisfying effects.
9. The player uses the most recent model to figure out what to do next and simulates what effects various scenarios would have.
   Example: The player is surrounded by barrels and knows that their goal is to destroy as many objects as possible. They consider what would happen if they were to shoot at more barrels. A mental simulation is made where the result of shooting the other barrels would make them explode as well, causing a lot of carnage, which brings the player closer to their goal. This feels like a good plan.
10. With a plan for what to do next, commands are sent for the player to trigger the game's input device.
    Example: The player's brain sends signals telling their hands to move the stick and hit the fire-button in such a way that it should hit the nearby barrels.

And then then it all loops back to step 1 again and begins all over. Hopefully this gives an idea of how useful the SSM Framework is in describing the game loop. Once you have this sense of how data is formed and transported around as a game is played, it's much simpler to see where something goes wrong. 

---

Now for a simple example of how this framework can be helpful when analyzing input. Hopefully this will also show how SSM can help us discuss certain game design problems in a much simpler way. 

Let's start by imagining a System space that has the following: 

• A character where the bounds are defined as an abstract cylinder.
• An abstract device that will play sound files when certain events are triggered.
• A couple of rules that will make the cylinder character stay at a certain distance from the player.

Now say that the Story space looks like this:

• The cylinder takes the form of a cute rabbit.
• The sound files played are cute quips that the player is meant to find endearing.

The designer's goal is that the rabbit should be something that the player cares about. If the Mental Model gets constructed properly the player will think of the rabbit as a living creature and base their imagination mainly on the story aspects of the character. This makes the player protect the rabbit and makes sure that it never falls too far behind. This is a case of the Mental Model working as desired.

However, it might be that the player realizes that the rabbit is a great shield against incoming enemy attacks. The game becomes much easier to play if the player manages to position the rabbit in between them and any hostiles when it's time to loot treasure chests. 

This radically changes the player's mental model. Instead of being a living creature, a fantasy mostly derived from Story space, the player now sees the character mostly as an element of System space. The rabbit is now simply a handy game object that has various tactical benefits.

This sort of thing is quite common in games. Entities usually start out in story space and then as you play the game and discover how they actually work, your mental model becomes more influenced by System space. And since the story content can usually deliver a lot more emotional depth, the experience comes off as very "gamey". In some cases this can be perfectly fine, but when you want to deliver a narrative experience it can be devastating. In this case it's really important to keep our Mental model close to what we had in Story space.

---

These sort of story vs gameplay issues are really easy to discuss in the SSM Framework, and it also provides us with several avenues of attack for how to solve them. You need to make sure that System space doesn't generate Mentally Modeled behaviors that directly contradict what is in Story space. By thinking about the flow of data in the game loop you can pinpoint where it all went wrong and then change things accordingly. While this doesn't spell out every single step needed to fix the problem, it gives us a way to formulate it and a foundation on which we can lay a more detailed plan.

Next week I will go over how the gameplay is defined in the SSM Framework and how it shows us a way to give narrative games a great sense of play.

Footnotes:
[1] The MDA framework also brings up various ways in which games engage players, but that I felt no need to go over that in this article. Do note that there is more to the framework than simply 3 layers of components.