A Mechanics Map is a diagram that represents the different elements in a game and how they are connected. It is not a flow chart of player actions, but more of a graph showing the relationships between the different parts of a game.
This map consists of 3 parts:
- Game elements — These are the mechanical systems and components of the game, for example: player character, weapons, coins, inventory system, etc… They are not the actions players take, but instead the game components that interact with those actions. In the map they are represented as rectangles.
- Relation arrows — These are arrows connecting the game elements together. Each arrow includes the verb that describes how the two elements relate to each other and it points to the direction of that relationship. If the elements affect each other, it is better to have two arrows as opposed to a double headed one.
- Connectors — These are organizational elements that help make the map more readable. They are represented as numbered circles and they allow you to connect two different parts of the map without having to make an arrow crossing the page. They always come in at least pairs (an entrance and an exit), though if there’s one element that interacts with many others in the same way (for example a currency that can buy potions, equipment, weapons and pets), then you can add exits.
Mechanics maps can get quite large for complex games with many moving parts. There are two things we can do in order to help with this:
- Group similar elements into an umbrella element; for example, you don’t need to list out the 20 different weapons, if using a ‘weapon’ element suffices.
- Summarize game systems into a single block, and then make another independent map for that block; for example if you have a complex but largely self contained crafting system, add a game element called ‘Crafting’ in the main mechanics map and then make a new one just for that system.
While analyzing a map there are a few patterns you are on the lookout for:
- Clusters — Highly connected elements, these are the systemic center of your game, so make sure they are related to your core experience.
- Loops — When the arrows of various game elements make a closed circuit. This is a good sign; the more loops the map has, the tighter the gameplay will be as the player will always have something to look forward to next.
- Dead Ends — A game element with just incoming arrows but no outgoing arrows. If a player reaches a dead end, then gameplay comes to a halt. These are suspect, not necessarily bad; as sometimes the goal or reward exists outside of the game loop. A common example of this is cosmetic items that don’t affect gameplay, being able to show them off is the player’s goal, so it’s independent of gameplay. However, if this is not the case, dead ends can be quite harmful, as a player may lose sense of where to go next.
- Chains — A chain is a series of elements where the middle ones have only one incoming arrow and one outgoing one. This is generally a sign of bloated design, and we should really question if we need those middle elements. Remember that everything we design is extra work for the rest of the team, so anything we shave off will help production.
I first heard of this tool from Alexandre Mandryka of Game Whispering during one of his seminars.
- List out all your game elements. Think expansively; trying to add elements to an existing map is a pain.
- Place the game elements based on their relationships. You should start with the element that is most connected, as that one is the hardest to place.
- Connect them with arrows; if it’s getting crowded, consider using connectors.
- Move elements and arrows to make the map legible.
Let’s imagine that we are working on Pacman.
A simplified mechanics map would look like this:
As I mentioned above, mechanics maps can become quite complex. Here’s one I made for a game I worked on a while back. During the 2020’s crypto boom, I was tasked to come up with a design that blended the use of external currency (crypto) with regular game mechanics. The result was a card-based rogue-like game where you wager crypto on how far in the game you’ll make it. Due to NDA’s I stripped out context of the map, but by the end it looked like this:
As the fad of crypto faded, the company decided it was not worth the cost to make the game; still, it was a fun project to work with its own set of interesting challenges 🙂
- MDA FrameworkOne of the most widespread ways to analyze a game holistically.
- One PagerA critical part of pitching a game idea to the wider team.
- SWOT AnalysisAn easy framework for analyzing the competition.
- Bartle’s Player TypesOne of the oldest & most widely used player categorizations
- PersonasA technique to humanize the intended players of the game
- X-StatementThe first step in development after having the game idea.