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.

In-Game Data Collection

So I've been trying to think of a term to encapsulate a certain type of gameplay mechanicsm I've encountered and enjoyed a few times in the past. The gist is that the player ends up using his own powers of observation and deduction in coordination with avatar abilities to discover things and solve problems. This sounds like standard adventure puzzle gameplay at first, but I think it's a little deeper than that.

• Example 1: Morrowind. One quest involves you finding out where a guy stashes some treasure. You have to watch him from a distance and note where he checks up on his hidden cache. There are no waypoints, no UI goading to keep you on track. He does the action every night and it's up to the player to watch him.
• Example 2: Assassin's Creed. Tracking down the fat guy. One of the eavesdropping missions revealed that the statue in the courtyard was climbable. When the wander-around-able cinema started for the assassination, I was able to note where the statue in question was and completely plan out my assault by the end of the cinematic, springing to action as soon as it stopped.
• Example 3: Wind Waker. The player is tasked with catching a moment of veiled romance with his camera. You eventually find 2 people whose patrol paths cross and they cast a loving glance at one another.

These are all about unguided discovery and feeling really clever once you achieve these goals. They also don't involve any tangible game mechanics. There's no jumping or shooting required to figure out these clues, though the puzzles are ensconced within the context of gameplay that does involve these explicit mechanics.

No real direction here, just that I think this sort of immersive in game thinking is a great thing to shoot for. I'm also trying to figure out a term for this sort of phenomenon so I can categorize it for later reference and use.

Dark Sector

Finally got Gamefly to send me Dark Sector last week. For the 2 hours I've invested thus far, I'm not that impressed. The glaive/boomerang mechanic has some potential, but right now its raw usefulness is overshadowed by guns. It a lot of fun to throw and steer the glaive from a first person view, and it can de-torso guys, so it does tend to win out.

The main sticking point I have is the level design. Why is it always the level design? The LDs are eschewing goal driven encounters with lock-downs where you either muddle your way through to the exit or kill guys until a random door opens. For the player to make meaningful decisions, they have to know what they're supposed to be doing in a given situation. Even if those goals are localized and player generated, at least there are goals. In these cases, it's a get from A to wherever linear formula, but you don't know how to get to wherever so you can't form a plan aside from killing things until something happens.

One area in particular dropped me into a dark shaft with 2 inches of water on the floor. Zombie guys kept spawning from this minuscule veneer of liquid as if climbing from the depths of some fathomless bog while I looked for a way to open the door. Some doors occasionally open when you get close and they flash a "hit B to open", some don't.

I had previously learned the "transfer electricity" ability prior to this, and there was a sparking wire I saw somewhere above on my way in, so I thought that might be the gating device.

Turns out that you just had to kill X of the zombies that spawned in endless waves. I got some kind of achievement and the door ratcheted open, its kill counter satisfied.

I realize that this sort of thing is hard to avoid throwing in on occasion, but at least let me know somehow that what I'm supposed to be engaging in is zombie genocide and not looking for some alternate mechanism of escape. At least God of War had those red walls to tell you that you were in arena mode.

Systemic design, goal oriented encounters, useful tools.

In addition to that, the only encounters I've seen so far could have just as easily been incorporated in a game that only involved a gun or two. Nothing aside from a few remote switches have been boomerang dependent systems.

It kind of reminds me of Jon Blow's talk on the ethics of game design and how we're padding these games out with meaningless repetitive encounters to lengthen the experience instead of coming up with mechanics that are inherently enjoyable to use and lend themselves to creating many varied scenarios where the systems can be creatively and emergently combined to give the player the agency and bit of mental exercise he or she deserves. Was that all one sentence?