[Netherrealm's Mike Birkhead explains why combat pacing graphs should be for entire teams -- not just designers -- and offers advice on creating effective graphs in this #altdevblogaday-reprinted opinion piece.] Every time you create a chart, table, or graph, you are attempting to visualize and communicate important information, but more often than not, people approach the task with a careless and blase attitude that leads to a muddying of their message, which ultimately leads one, even with the best of intentions, to chart the wrong course. There is no greater beneficiary (and culprit) of clear communication than the Pacing Graph. Pacing is one of those designer concepts that you just don’t order from the local design store: “Uh, yes, I’d like to order two units of good pacing please.” We know that we need it, we know when we lack it, and we sorta know how to orient ourselves in search of it, but damn if the search isn’t a complete nightmare. On our search we create tools to light or path, and the brightest light we have is the Pacing Graph. A Pacing Graph is the graphical representation of the major moments in your flow. Much like a screenplay’s three act structure, games have a flow to them. You enter an area, you are presented with increasing levels of both physical and mental conflict, and you are finally rewarded with a resolution. It is easy to see how the game follows this arc, but you’ll notice that each level follows its own mini arc, and even, if you’re good, the combat encounters. A Pacing Graph helps you to visualize this sinusoidal flow to the game, and helps you to spot problem areas like too much combat, too little downtime, or too much of both. Now, I know what you’re thinking. “I’m not an idiot, Mike. I’d never make the mistake of putting two big fights next to each other.” True, you might not – at first, but what happens when the middle section of your level gets cut? (every game ever) What happens when that creature you were counting on to be in your level is cut, so you replace it with another? (every game ever) This kind of stuff happens all the time, and it can be hard to keep track of how things stand at any given moment. Enter your Pacing Graph. They are an invaluable tool in your game design tool box, and not just for you level designers out there. The 300 missions in the Challenge Tower, for example, are constructed around a spike chart. When properly constructed, a Pacing Graph drives clean and clear communication of the major moments in your designs, and ensures a good balance in two major areas: balance within your own work, and balance amongst the entire game. You see, Pacing Graphs are not just for you, and they are not just for other designers; they are for the entire team, and that means they require meaningful context, game wide consistency, and clean communication. Pacing Graphs must be constructed a certain way, and they must match in style and meaning to the designer two cubicles to your left. Look: just making a bunch of lines with accompanied notes does not, by itself, constitute a Pacing Graph, but worry not, for the following will help you to overcome two major mistakes: a lack of clarity, and a failure to recognize the difference between combat and cerebral tasks. Communicating With Graphs Before talking about the components of a Pacing Graph, I must discuss graphs themselves. The simple and intuitive look of most graphs belies the thought and consideration that must go into their construction. Throwing numbers into excel and pressing the chart button will certainly get you a result, but without asking the proper questions, you will never know if it is the best result.
The meaning of our data is important, obviously, but let’s skip that for now and move right to the needs of our audience. We must pick the right medium for the job, and you have two major choices in the shape of your communication: tables, or graphs.
Before you can communicate data, you must know what the data means and know what’s important based on the needs of your audience. Only then can you trim away what’s not pertinent, choose the best medium of display, and highlight what’s most important. – Stephen Few
- Tables: used when you need to look up individual values easily, or when the values must be precise.
- Graphs: used when you need to communicate the shape or relationships of data (patterns, trends, and exceptions)
- Nominal: items that are related in name only (hence nominal), like Regions of the world (North America, South America).
- Ordinal: items that have an intrinsic order, but still convey no actual quantitative value (Small, Medium, Large).
- Interval: items that have an intrinsic order, while also conveying quantitative value (0-99, 100-199, 200-299). Note: the key component to the interval is not that it subdivides, but that it subdivides into portions of equal size. (Or near equal size, as in the case of months / years / quarterlies)
This is important, because Line Graphs, as we discussed, show the relationship between items over time, and they excel at showing trends, patterns, and exceptions, but Ordinal and Nominal scales are not related enough for the graph to convey any kind of meaningful information. In fact, they make Line Graphs worthless. Let’s look at a few examples.
Whenever you create a graph, you have a choice to make—to communicate or not. That’s what it all comes down to. If you have something important to say, then say it clearly and accurately. – Stephen Few
(taken from: Effectively Communicating Numbers)This is the crux of the first major mistake: clarity. In order to be clear, you must quantify your spikes with meaningful values, and you must track them against a meaningful categorical scale. For the first part, I use a fixed point system (usually 6 levels, but it depends on the game).
- Level 0: cool down period
- Level 1: a small fight, usually fodder
- Level 2: a normal fight, where the player is left with around half health
- Level 3: the player is left with almost no health
- Level 4: a difficult fight, and the player most likely died at least once
- Level 5: an extremely difficult fight, and the player most likely died more then 3 times.
Notice how, in the former, you fail to convey the gigantic vacuum in your experience. In fact, everything appears copasetic, which is totally not the case, and this only becomes apparent in the case of fixed intervals. Is it easy to gauge your level on fixed time intervals? No, absolutely not. Does this mean we forgo the attempt? No, absolutely not. It is very hard to judge how much time a player will spend moving through a space, but that doesn’t mean you do not give your best estimates. Game design isn’t easy, my friend, and you shouldn’t be taking the easy way out. If something is worth doing, it is worth doing right. Ok, we have clear quantitative values, and we are comparing them against a meaningful Interval Scale. Are we done? Nope! Now we tackle the second biggest mistake. Combat vs Thinking A video game is not like a movie, and we shouldn’t be tracking our pacing in the same manner. A Pacing Graph is really two separate but equally important graphs. The police who investigate crime~ whoops, I mean: one for combat, and one for thinking. If you ask the player to fight something, then you cannot ask them to puzzle over something. They won’t do it. Combat always wins, and I’ve found this to be true time and time again. It is imperative that you separate your spikes into cerebral and combat tasks, because it’s not just about seeing where the spikes exist in your pacing, but where the spikes conflict in your pacing. Intellectual spikes will always conflict with your combat spikes, and the combat spikes will always win. Given the choice between think and fight, people will go into Combat Mode, which can also, by the way, be synonymous with fleeing. It is more than this, though, as even with infinite clarity to your puzzles, if you make the player fight while they solve things they will hate you. Think about it in terms of enjoyment. Intellectual tasks are about solving riddles and discovering the order of steps, but once you figure out how to do it, you just want to DO it. How many times have you screamed at the computer screen, “I know what I’m supposed to do, just let me DO IT!” Seeing that round peg go through the correct hole is the reward. Imagine the reverse. You have just defeated a very difficult monster, but right as he is about to die the game comes to a screeching halt and asks you to solve a riddle. How pissed would you be? This is what you have worked for! See, in much the same way, combat gets right in the way of the cathartic release of intellectual problems. Wait, does this mean we never ask the player to think when fighting? No. It simply means we must be aware of the connection. Some of my favorite moments in games are so-called Combat Puzzles, such as the infamous scene in God of War where you push the man in the cage up to his death, but you need to be aware of the serious level of play testing these require to feel good. Nothing walks closer to the edge of frustrating than a combat puzzle, as you are essentially making a conscious decision to piss the player off, and then hoping that will pay off – think about that! You are choosing to be a dick on purpose, and then hoping the player will like it. We are assholes. Never forget: your job as a Designer is not to prove how smart you are, but to prove to the player how smart they are. This is one of those cases where, if not careful, we can lose sight of that, which is why we have things like Pacing Graphs. It reminds us of what we are doing, and it can only do this if it visualizes the conflict of Combat and Puzzles. This visualization, you guessed it, requires a separate and equally meaningful point scale for cerebral tasks, because numbers can only have meaning when you compare them to other numbers. Some examples:
- Level 0: nothing
- Level 1: simple interactions like pulling a lever
- Level 2: obfuscated simple tasks, or a simple task made up of more than one task, like finding a hidden box needed for a pressure plate.
- Level 3: multi stage tasks. Most players will be stuck for a little bit. (3 – 5 minutes)
- Level 4: major puzzles with several interactive parts and potentially very obfuscated tasks. (5+ minutes)