The Game Mechanics Distribution Schedule

Believe it or not, this is a design article. It’s not about the fun theory stuff like DDA or emergent narrative, but focuses instead on some of the nitty gritty implementation stuff, namely the distribution of gameplay mechanics in your game. In the latest project I’ve been working on, I came up with a useful method for tracking what abilities the player will be using and when, to insure that you don’t have bunched up areas that require something like “block pushing” followed by a dearth of any interesting gameplay aside from “double jump”.

This method probably works best as an analytical tool after you’ve made a paper-map pass on your levels, but it could easily be tweaked to adapt during preproduction. The basic gist is that you lay out a spreadsheet where columns represent gameplay “moments” and rows represent the mechanics available to the player. You fill in what is being used where and zoom all the way out, so you can see the entire breadth of the game. At this point you look for dense and sparse areas that show where something is being used to frequently or not often enough. This is a good tool to keep separate level designers under a consistent framework for the frequency and escalation of mechanics they’re introducing and requiring the player to use.

Step 1: The Mechanics

The first step is to call out all of the player tools. It helps to already know what they will be, but there’s room for growth if the list isn’t 100% complete. It’s most useful to categorize these into types of abilities. “Jump” and “wall-run” would go under “navigation based” for instance.

A handy extrapolation from this step is to identify tiers of usage for each ability so you can ensure they’re being escalated and grow in meaningful ways as the game progresses. “Jump, tier 1” would involve small heights with little repercussion if you miss while “Jump, tier 5” might require precision aim or timing and have certain doom as the consequence for failure. It’s probably a good idea to normalize these tiers across the board so they all have the same range. It's good to place a doc like this on a wiki somewhere so all the designers can get a good, concrete idea of what constitutes what tier of any given mechanic.

Step 2: The Schedule

The next step is to break your game down into levels, and the levels down into bite-sized encounters. For this tool to work best, all of the encounters should be approximately the same length. If they aren’t, you could scale the column width in excel to represent the duration of the slice. The style of game you're making will impact how these slices are determined, so feel free to make up your own unit of measurement.

Step 3: Make the spreadsheet

Now we combine the previous 2 steps. You'll make a spreadsheet with rows representing the abilities and columns representing the levels and moments. My first inclination was to give each level its own tab, but this ended up isolating them so you couldn't look at the big picture all at once. The new shareable excel format should ideally allow multiple designers to work on their own sections individually without needing to split it into separate docs.

The ability groups should be clustered together, preferably in the order in which they're revealed, and I'll explain why next. You can give headers to these and merge cells for level and ability groups for further clarification. The main idea in formatting is to enable you to get as much information at a glance as possible.

Step 4: Mark mechanic availability

The next step is to gray out all of the boxes where abilities are not unlocked or available yet. If you've listed the abilities in the order they're unlocked, this should resemble stair steps. This process by itself will be helpful in showing you how much of the game relies on which subset of the player's abilities. You can tell if, for instance, the player will have nothing but "jump" for 90% of the game, at which point he gets all of the other abilities at once. This is a bit of an exaggeration, but you get the idea.

Step 5: Fill in the boxes

At this point you go through all of the moments, level by level, and fill in the cells where a mechanic occurs. Leave the cells where a mechanic isn't used white. If you're using tiers, you can heat map the values so blues are low-tier and reds are high-tier. This will take some time, but you get that OCD bubble-wrap kind of Zen out of the process.

Step 6: Step Back and Analyze

Now that you have your chart filled in, zoom it out so you can see the whole thing at once. The text will probably be illegible, but you'll be able to see trends from this birds-eye view.

Long lines of a color mean that something is probably being overused in an area. You'll probably want a little of this when a mechanic is first introduced, but give it some breathing room after that.

Large white spaces mean a mechanic is underused in an area. If you've clustered abilities by grouping (navigation, equipment based, cerebral, combat) then you can tell if an area leans too much towards one style of gameplay. This is an unbiased analytical tool, though, and you might want a more combat-heavy area.

Another thing to look at is heat-mapping progression. If reds are occurring a lot before blues, or there are a lot of blues at the end of the game, then there's probably an escalation issue to address where things are too hard up front and too easy on the backend.

Step 7: Tweak and repeat

After you've gathered your data, make some notes about where the problems spots are and how to fix them with the inclusion or removal of mechanic usage instances. Implement these ideas, fill out the chart, see how things are working and go from there. It's an iterative process that could take several passes along with whatever other methods of blind-testing or other feedback tools you're using.

Conclusions
The first thing to note is this isn't a magic bullet to make a fun game. It's a way for a designer to get a good idea of the landscape of the mechanics in his game and adjust levels accordingly. There isn't a sequence of colors or patterns to look for, as it's all in the aesthetic that the designer is hoping to accomplish with the title.

Another thing to take into account is that this is initially set up for linear levels with a set schedule for the revelation of abilities. I think the idea could extend to incorporate less linear experiences with open world settings or possibility space bubbles or whatnot, and I might tackle that extension in the near future.

In no way do I recommend this over actually playing the game and seeing what it feels like in person. This is a good method of troubleshooting things in the paper map phase and keeping tabs on gameplay distribution during development, but it won't replace actual playtesting and user feedback.

I hope some of you get some use out of this, as it helped me out a great deal in getting a grasp on the big picture of what was happening in my game.