Critique Tips: Using the SSS Model

One of the first things you’ll likely disentangle as you begin thinking about games in more depth is the difference between “mechanics” and “level design.” For many games, regardless of the particular level or area you’re in, you’re always capable of performing actions from your base toolkit or interacting with enemies in a particular way, but the design of the area will dictate which actions or interactions are useful. However, thinking about this too heavily from the perspective of a given game or genre can cause tangents into the nitty-gritty implementation elements. As I like to start from a abstract reference point, I devised this simple “SSS” model (“system, scenario, and structure”) to frame my analysis.

There’s three primary reasons for which I use this model:

• On a theoretical level, this undergirds the in-depth parts of my analytical method based on state space theory in articles you can find here and here. Thankfully the SSS model sits upstream of all of this theory, so you don’t have to get into the weeds if you’re not interested in developing metrics around state change or unspooling how players progress through a state space.

• On a practical level, I lean pretty heavily on this model to outline my reviews. In my recent Strider review (and the original Backloggd review from nearly two years ago), I start off discussing the movement abilities and interaction for a paragraph before moving into two paragraphs on the level design. That’s fundamentally a paragraph on the system and two on the scenarios, with analysis of the structure relatively truncated due to the linear arcade level progression. Back when I did three paragraph reviews (my “750 Rule” reviews, named after the target word count), system/scenario/structure was an extremely convenient split.

• On an implementation level, most game engines have code-driven systems and data-driven scenarios. Drawing the distinction between the two can lead into trouble on a case-by-case basis, since there’s certainly going to be code handling the scenarios (whether through parsing them, providing bespoke scenario-specific interactions, or even generating scenarios on the fly) and data tables in the engine, but as someone who teaches software engineering through the lens of game dev, I find that students need the distinction drilled into the head early lest they attempt to hardcode every level in their game. Where the structure falls in that divide… it’s almost always a mix of the two, but the structure of my students' projects rarely develops beyond linear level progression.

The Layers of the SSS Model

System

The system consists of the fundamental rules of the game. What these rules consist of will depend on the game, but it generally defines both actions that the player(s) and other entities can take and interactions that will occur when an action is applied to an entity in the game. If you wanted, you could think of it as the “training room” equivalent of the games with the actual level design removed and the ability to test anything you want; this is what developers are doing when they add those “test maps” to games with random enemies or interactables spawned in. While it may not be hard to recognize actions in a game, interactions may be more oblique and will generally span all aspects of the physics engine, the AI, and potentially further simulation aspects depending on the complexity of the games. More abstract variables such as the timer or the player’s score are also integral to the system, even if it seems like they don’t directly interact with the player. Even menus are a kind of system; this logically follows if you consider that the gameplay of many turn-based games consists solely of navigating menus.

You can think of the system as if you could play around with all of the different rules of the game in a test map. [src]

The player learns the system in the sense that progressing through the game requires learning the fundamental actions and interactions. It’s not uncommon for the system to be directly communicated to the player via tutorialization or button pop-ups. The system constrains possibilities by defining every entity in the game and what each are capable of, with each scenario drawing from these entities and nothing more.¹ Likewise, the system is useless on its own, as if you were reading the instruction manual without booting the game. To actually play, the system needs to be contextualized by the scenarios.

Scenario

With the palette of entities, actions, interactions, and other rules provided by the system, the scenario paints scenes that the player can step inside and interact with. Often times we would describe the scenarios as “levels,” “areas,” “missions,” “encounters,” or some other word that captures the idea of the player facing a set of obstacles. Hence, in the SSS model the player overcomes each scenario, where they leverage their knowledge of the system against the entities of the system that the scenario has placed in their way. This implies there must be some way to end the scenario, whether by waiting or by completing a set of conditions. Multiple end conditions or methods may exist as well, and the game may mandate that one or more of the conditions are met before the player may proceed.

This training mode mission in The House of the Dead 2 is a clean example of a scenario: it’s a particular instantiation of the system with a win condition. [src]

While the scenario must only use elements outlined in the system (it’s constrained), it also breathes life into the scenario by creating a context for it to exist in. Rules define how things should work, but without a use case they cannot be put into action. However, few games exhibit just a single scenario in practice. Generally scenarios are mere components in larger structures, receiving a contextualization of their own as earlier or later in an overall progression, or perhaps as “main” or “side” scenarios in games moving beyond purely linear structures.

Structure

With a heap of scenarios to choose from, the structure sequences and arranges them into the overall game that you play from start to end. The most traditional structure places scenarios in a linear order, often from easiest to hardest. More modern games may provide an open-ended set of scenarios that can be completed in any order, or they may have designated scenarios that contribute towards progression while gradually opening up side scenarios that provide additional narrative, atmosphere, mechanical advantage, or alternate aspects of the system. Some games may randomize scenarios instead or encourage replaying scenarios over and over again, often in tandem with the system elements that encourage the same. Regardless, as the player engages with the game, they will inevitably progress through the structure, whether to reach a specified end point or achieve a desired level of mastery.

The Mega Man series became famous for their unique open-ended structures, where each stage was named after its ending boss, and each level could be done in any order. This tied into a system where special weapons from each boss had an advantage against a certain other boss. Finishing all eight main levels would place the player into a more traditional linear gauntlet of stages to end the game. [src])

One quirk of the SSS model is that it implies that the system and the structure don’t directly engage with each other; I go back and forth on whether this is true or not. We can understand practically that game designers don’t work with these clear delineations and will design the system and structure in tandem to meet their goals. Where it’s undeniable that they meet is in the scenarios: if a structure privileges a certain style of play or progression, it will be experienced moment-to-moment in the scenarios, where rules based around said style of play are instantiated. If a game has a material grind as a design goal, it’s likely that the structure will provide a variety of replayable scenarios that instantiate particular materials within the rules defined by the system.

An alternative way to perceive this is on the right of the SSS model diagram, where the abstracted layers are defined as a gradient from “macrodesign” to “microdesign.” While I don’t use these terms often in my own critique (as I find them too squishy), you may find it more useful to think of these layers as artificial delineations in a spectrum of game design that ranges from the overall top-level construction of the game to the minuscule interactions that one may scarcely notice. In either case, the important distinctions to make when writing critique come from discerning the scale of a particular design decision, and more coarsely from our initial framing, the primary distinction is separating the mechanics (the system) from the level design (the scenarios).

Questions to Ask in Your Crit

Now with an understanding of the full SSS model, including what each layer is and how they interface with the player, we can begin to incorporate their concepts into our critique. I find it useful to start with the following questions:

• What rules and entities (or actions and interactions) are in the system? What are the scenarios, and how do they use the elements in the system? How is the game structured with regards to the arrangement of the scenarios?
• Does the system overly constrain how each scenario plays out? Is it robust enough to provide a large variety of scenarios? Or does it have such depth that scenarios can still be intriguing even when they’re weakly defined?
• Do the scenarios provide interesting contexts for the system? How much of the system does it use in each scenario? How often do scenarios overlap in the elements that they use?

Platformers have traditionally operated on a “world” structure, with level scenarios that each draw from a similar mechanics before ending on boss scenario or something similar. In Crash Bandicoot 2, this world revolves around slick surfaces that change Crash’s handling, along with snow-themed enemies such as penguins. [src])

• What kind of scenarios does the structure have at its disposal? How does the structure group scenarios by their attributes, such as the elements of the system they use, their length, or the conditions for their completion? Are the scenarios all pre-made or are they generated programmatically?
• What design concepts can you follow from the macrodesign of the game all the way down to the microdesign? If you find a particular design thread at one layer of the game, can you follow it to the other layers? Do you find the game to be built top-down from its structural design concepts, bottom-up from its system design concepts, or somewhere in-between?
• When comparing a game to another similar game, on which layer do they most strongly differ? Does one adapt the system of another to a new structure, or does it instead take the surface-level structure with a radically different system inside? Do its scenarios use similar amounts of elements from the system, do they tighten the scenarios, or do they make them more open-ended by comparison?

Coming Up Next

In my next article, we’ll look at some examples for specific games and how we can break them down into the layers of the SSS model. We’ll then cover each layer of the model in more detail in separate articles, identifying games that focus on particular layers over others and follow particular patterns for constructing their layers.