Generative Game Design, Part 5: Applications
Practical uses for applying this framework
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
Application
Attributes — Design Docs
Writing design docs with an eye for attributes translates well into implementation. Identity attributes in many cases can be represented as an enum in software. Labeling all the necessary quantitative attributes reveals all the variables that are needed and the hooks for designers to tweak. Figuring out what kind of geometric shapes need to be supported (or can be supported) is necessary.
What kind of input are we listening for? Does time have any effect? Generative game design is intended to be useful not just for understanding game design but also communicating it.
Attributes — Error Design
Slips, as explained in Don Norman’s The Design of Everyday Things, “[occur] when a person intends to do one action and ends up doing something else”. This is like when a player, in a platformer, jumps too late and falls into a pit and dies. Mistakes, on the other hand, “occur when the wrong goal is established or the wrong plan is formed”. This is like when a player, in a Pokemon game, chooses a fire-type against a rock-type.
A simple rule of thumb is to control slips with time and input attributes and mistakes with identity, quantitative, and geometric attributes.
The more time a player has to react to something or the less complex the input is, the less likely a slip will occur. Like allowing an additional amount of time when the player runs off the platform to jump and make it to the other side, a.k.a. “coyote time”.
Simplifying (or reducing the number of) identity, quantitative, and geometric attributes will decrease the likelihood of mistakes. Like instead of 18 Pokemon types, we can reduce it to 3 with a Fire > Grass > Water > Fire relationship. Perhaps not as fun, but player mistakes will be greatly reduced.
If the topic of error design is interesting, I have written about it in an earlier blog post: Assisted Jumps in The Talos Principle.
Mechanics — Poker Hands
Poker hands are created through the conjoining of identity attributes with other identity attributes and quantitative attributes. Pairs use ranks as identity. Straights use ranks as quantitative, since they’re defined by a consecutive sequence of ranks. Flushes use suits as identity. And straight flushes conjoin ranks and suits into a new and rarer hand taking into account both quantitative and identity. All of the poker hands go to show how much flexibility we have with a seemingly small set of attributes.
Prose (Deep Structure) — Mapping Transformation
One fun transformation is mapping one attribute onto another. We can think of inventories in video games as the mapping of identity-based mechanics like items to a storage. But what this storage can look like depends on what our goals are and subsequently what attributes we choose to base it on.
Using quantitative attributes like weight will give us something like Skyrim’s inventory system. Or, using geometrical attributes like shapes will give us something like Resident Evil 4’s attache case. Perhaps we can try doing a different type of inventory that’s based on time attributes instead: when you throw an item away, it reappears after 3 turns.
Central to Generative Game Design is separating player behavior and player experience. We don’t want to be stuck discussing whether Skyrim’s inventory system should actually be volume instead of weight to determine player behavior. That may, instead, be a question about the player experience. This discussion may in fact be focused on whether this storage system should be based on quantitative attributes or geometric ones. How the attributes can be intuitively understood at the surface structure (volume vs. weight) is a separate and important conversation.
Design Disciplines
A fun exercise is to map out where you think design disciplines are focused in regards to generative game design. Or, conversely, figuring out what you’re good at and what kinds of designers/developers you ought to collaborate with. Here is a rough breakdown of some of the most common ones:
Important note, this isn’t to say that a level designer can’t have a voice on what the level will look like, or that a narrative designer can’t work on mechanics. This is just saying that if a level designer works on the surface structure, they’re focused on how the level is represented: environmental narrative and player resonance. If a narrative designer works on mechanics or deep structure, they’re developing a narrative system. Cross-pollination is awesome in empowering us, renewing creativity, and encouraging collaboration. Do it!
Closing Thoughts
When we have a design problem, we can use Generative Game Design to facilitate ways of approaching and solving it. If our players are struggling to understand the game mechanics, do the metaphors effectively communicate the underlying mechanics (game surface structure)? Are the mechanics actually contradicting their purpose (prose deep structure)? Are there too many attributes conjoined together (mechanics)? Should we be using one set of attributes instead of another (attributes)? Using this framework helps us pinpoint where our problems lie, and what steps we can take to fix them.
I hope you have found this to be useful/helpful! You can find me on Twitter @stephentrinha.
