Generative Game Design, Part 4: Prose (Deep Structure)

A framework for designing games inspired by Leonard Bernstein’s Harvard lecture series The Unanswered Question and transformational grammar. Bernstein is a conductor, composer, and much more, whose most famous work is songwriting for West Side Story.

Part 1: Game (Surface Structure)
Part 2: Attributes
Part 3: Mechanics
Part 4: Prose (Deep Structure)
Part 5: Applications

1. Game (Surface Structure) — the sensory form in which the game is experienced
2. Prose (Deep Structure) — the underlying structure that configures player behavior
3. Mechanics (Underlying strings) — the smallest units that have meaning
4. Attributes (Chosen elements) — a discrete unit that distinguishes one interaction from another

Prose (Deep Structure)

We look at how mechanics are organized in the second layer: the deep structure, “prose”, of a game. This is not so much about how mechanics are presented to the player; that’s more in the surface structure. This is about how we can use mechanics to induce the intended player behavior. Or, how we can derive player actions from metaphors. In short, prose is the configuration of player behavior through transformations, patterns by which the game and mechanics are made meaningful.

For instance, tag and hide-and-seek can be described similarly on the surface: both are games in which one player, who is “it”, tries to “catch” another player. How is it that in one game, the “it” player chases the other, but in the other game, the “it” player shouts out when they’ve seen the other? How do we arrive at these two different experiences?

Diagram showing what “catching” means in tag.
Catching someone in tag requires touching
Catching someone in hide-and-seek requires perceiving

We know that the difference between the two, on the surface, is that one involves physical contact and the other involves visual contact. But if we look at it mechanically, we can focus on 4 main mechanics: 1. the geometric shape of the player who is “it” (which is an identity), 2. the geometric shape of the other player, 3. the speed (geometric+time) at which these players can move, and 4. “catching” means the geometric intersection between the two players. Given what we know about the game on its surface, the 4th mechanic may seem like it is the key difference, but the difference is really due to the relationships between the other 3 mechanics created by the 4th mechanic, not the 4th mechanic itself. As an example, how can we play hide-and-seek in an open field? The game becomes trivial in this “level” because the size and speed of the player (including their “vision cone”) makes catching trivial. By recognizing these attributes in our mechanics, we can start to modulate on the geometric and time attributes to drive players toward the game’s intended behavior of hiding and seeking.

We can change the geometric size of the vision: play at night and the “it” person uses a lantern that lights a small radius around themself. The not-“it” player can effectively hide in the dark, and the “it” player must seek them out. However, after playtesting, we find that when the not-“it” player is about to be spotted, they run away from the light of the “it” player, and the “it” player chases the sound of their footsteps. This is not our intended player behavior of hiding and seeking; now, the behavior is chasing. It’s a new player experience, but we’ve essentially recreated tag. How can we have predicted this?

Diagram showing difference between vision cone hide-and-seek and light radius hide-and-seek.
Using a lantern to reduce the geometric size of the player’s vision to facilitate hide-and-seek in an open field. Notice that the image on the right is similar to the diagram above with tag.

The fundamental relationships between the 4 mechanics in our new hide-and-seek game are unchanged from tag. The only thing we have changed is the geometric size of the “it” player: from their body size to the light radius. What we need to change is really the relationship between the geometric sizes of the players and the distances between them. Or rather, how the distances between them change over time. It is by enforcing this mechanic — normally implied in traditional hide-and-seek — that will make the not-“it” players behave similarly: not-“it” players may not move from their starting position. This replicates that feeling of scouring for the “it” player and that feeling of dread for the not-“it” player. The only other key ingredient missing is the hider’s ability to hide creatively.

The purpose of examining deep structure is that we can codify the creation of these relationships as transformations and apply them to different attributes with similar results. For example, the relationship between the two identities in tag, “it” vs. not-“it”, can be described as a dominating one. “It” can directly affect not-“it” (by tagging), but not-“it” cannot directly affect “it”. Hence, “it” is dominant over not-“it”. Secondly, this “tag” interaction between the two identities is oppositional to one another, as in tagging is beneficial for one but harmful to the other. “It” wins by tagging, while not-“it” loses when tagged. We can label the creation of these two relationships as, respectively, a dominating transformation and an oppositional transformation.

For fun, let’s see how we can apply these to a different game like rock, paper, scissors (RPS). Luckily, RPS already has an oppositional transformation: the interaction between rock-paper, paper-scissors, and rock-scissors is beneficial for one but harmful to the other. On the other hand, to apply a dominating transformation, we need to create two new identities to assign to the players in order to give one dominance over the other.

Instead of “it” vs. not-“it”, we can choose something more flavorful for RPS: an attacker and a defender. In this case, the attacker is dominant over the defender. This means that we need to transform the RPS interaction such that the defender can no longer “win” against the attacker. This will be like how the not-“it” player cannot “win” in tag; only the “it” player gives up (or time runs out). If the attacker throws paper, the defender successfully defends if they have thrown scissors or paper. Throwing scissors in this scenario does not result in a “win”, but, in the traditional RPS-sense, it’s a tie.

The new player experience for this version of RPS is — much like the experience in tag — how many turns can the defender evade the attacker OR how quickly can the attacker catch the defender. The experience will not totally be the same, because we are using identity (RPS) vs. geometric (tag) attributes for the basis of the interaction. However, despite the difference, we have been able to reproduce that “chase” experience by reusing the transformations we have discovered in tag (dominating and oppositional) and applying them to RPS.

Part of the fun of analyzing the deep structure prose is discovering these transformations and how they configure player behavior. Like a repertoire, they give us the knowledge base that empowers us to replicate and innovate. These aren’t one-off functions. They are transferable patterns that can be applied across multiple attribute types and used in disparate games. Generative game design is about how we can eliminate guesswork and design with confidence. We’ll explore some general applications of this framework in the next (and final) part.

This ends in Part 5: Applications. You can find me on Twitter @stephentrinha.

--

--

--

Writing about video games and game design. Systems designer on Diablo 4. Views are my own.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

“The Good, the Bad, the Ugly”: Game Articles

Gameplay Journal Entry #2 — Giovanni Minus

Cubomania Monthly Digest

The Serpent Witch: A Challenging Antagonist for My D&D Players, Along With a Pleasant Surprise

Field Notes — Hypnospace Outlaw

On the Abyss

Quiz: Just how much Do You Understand about video game?

Revomon — Official public release on SideQuest!

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Stephen Trinh

Stephen Trinh

Writing about video games and game design. Systems designer on Diablo 4. Views are my own.

More from Medium

Announcing the Holiday Jam Winners!

[Part0]Trying to build a clone of skribbl.io

Making a mobile game feel like Google Maps

Rhythm Quest Devlog 22 — Character Animations