A technical framework for understanding game mechanics in systems.
As the subtitle states, this is a framework for a technical understanding of game mechanics in systems — not so much a creative one. I’ve been developing it while working on design documents for various projects, and I feel like it might be useful other designers out there. Its purpose is to help analyze mechanics and give an organized format for breaking down mechanics into their most basic forms. I use it most often when I need to write up comprehensive docs for a game mechanic or system. I also use it to develop new mechanics for an existing system.
4 Elements of Game Mechanics
There are 4 elements of game mechanics: quantity, spatial, state, and action. The following chart defines each of them and provides some examples of each. After the chart is an application of the framework using 2D Mario games.
To demonstrate how you might use this framework, let’s say that we’re writing up the documentation for the health system in a 2D Mario game. We can start with the metaphor, as that’s always the most visible aspect:
Mario turns big when he eats a mushroom. When Mario is big, if he takes damage, he turns small, and when Mario is small and he takes damage, he dies.
This might be enough for others to understand, especially if they’ve played a 2D Mario game before, but it poses several questions. How does Mario eat a mushroom? What does it mean for Mario to be big or small? How can Mario take damage? When you need to start examining the underlying mechanics, the framework comes in handy.
We can break out the mechanics into their elements, beginning with big or small. Mario’s size indicates how many hits he can take before he dies (quantity) — 2 when big, 1 when small. His size also affects how tall he is when he is standing (spatial) — 2 blocks vs 1 block. And because his size adds an additional rule to the player, i.e. they cannot grow any bigger while big, we can consider it to be a state mechanic as well.
Eating a mushroom and taking damage are mechanically very similar. First off, they are action mechanics: they change Mario’s state from small to big or big to small to dead. And second, they both require another entity to collide with Mario (spatial). What differentiates gaining health and taking damage depends on what that other spatial entity is. If it’s a mushroom, Mario will become big; if it’s an enemy, Mario will take damage.
Using the framework to break down the health system in a 2D Mario game gives us this summary:
Big or small are state mechanics that (1) apply to Mario, (2) visually represent Mario’s health points (quantity), and (3) affect how tall Mario is when he is standing (spatial). When Mario collides with another entity (spatial), that entity may change Mario’s health state to big, to small, or to dead (action).
Being able to convert metaphors into mechanics is an important skill to have when analyzing systems. Mario’s health may appear to be straightforward on its surface, but by using the framework, it becomes clear how Nintendo was able to innovate. It is not purely a quantity-based system, where a number counts up and down. It’s a system that affects Mario’s size which affects whether or not he can run through a 1 block gap, or whether that fireball would’ve instead passed over his head if he were small.
This breakdown does not cover all aspects of the system. Obviously, it does not examine other power-ups like the flower. However, there is still analysis to be had on what’s here. For example, how is the spatial problem solved where Mario is still colliding with an enemy immediately after taking damage? Does Mario get hit again? Using the 4 elements will help you find answers to these questions.
In a future post, I may explore my other uses for this framework such as how to use it to come up with new mechanics for existing systems. But in the meantime, let me know what you think here or on Twitter! I’m always trying to improve it.
-- Stephen Trinh (@stephentrinha)