Opinion: Pacing Graphs And Tips From A Combat Designer

[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.

Our goal is to visualize the state and intensity of the player’s experience, and to do so in a way that conveys the relationship to not just the surrounding moments, but also the entire game. In short: we want to see how pacing changes over time. We want a graph. (Fairly obvious, but it’s good to verify it is the right choice). That is not all, though, as our stated needs provide even more information about the exact KIND of graph we require. Of the four clean choices to visualize data (points, lines, bars, and boxes), lines are the best at conveying the shape of data as it changes over time, which is exactly what we are looking to do. This gives us the shape our data must take, and now we must determine what data to show and determine what it means. Quantitative Information and Pacing Numbers, by themselves, have little to no meaning, and it is only by comparing them with other numbers that they gain meaning. If I tell you that Kratos has 100 health, then you learn absolutely nothing of any real value. 100 Health, by itself, means nothing, because you have nothing to compare it to, but if I tell you that Kratos has 100 health and the Cyclops has 200 health, then you can begin to compare these two values; meaning is beginning to emerge. A graph is no different, and if you do not ground your data in Quantitative Information, then your entire graph is meaningless. Quantitative Information, though, is not just made up of raw numbers. It also includes Categorical Scales, which give meaning to the numbers, and allows us to gather data. Categorical Scales can be broken down into three types: Nominal, Ordinal, and Interval.

Quantitative, Categorical, Ordinal, Nominal… Mike… why does this all matter? Do people really need this level of detail? Why can’t I just draw some lines and call it a day? (Sigh) Because you’re not a lazy bum, that’s why. Because you care about good communication, that’s why. Because you take this job seriously, that’s why. This matters, dear reader, because we wish to communicate, and poor communication is almost worse than no communication at all.

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.

(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).

Each level of the spike has a “significant and meaningful definition”, so that when two designers talk, they have conversations about pacing that have meaning. “I’m thinking of having a 3 here” — this has meaning. You know exactly what he wants, and you can consider what it means within the surrounding context of the rest of the level. Before this I have a 2, and after it I have a 5. I know what this means, and so does, more importantly, every other designer on staff. You can now compare two levels side by side, and have a meaningful conversation. Remember: numbers only have significance when you can compare them to other numbers. For the second part, meaningful categorical scales, you must break your moments up into an Interval Scale. Simply listing the major moments and their corresponding spikes tells nobody anything of any real significance. Major moments have an intrisic order, yes, but they convey no quantittative value. Ok, you say, what if I break the level up into loading regions? Better, but not quite good enough. See, now you are breaking the game up into intervals of time, which is good, but Interval Scale requires intervals of equal size to be truly clear, and that is not what you have done. Take the following two examples:

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:

Conclusion Pacing is a complicated thing, and doing a Pacing Graph is not going to do your job for you. Its job is to guide you, and to help you communicate with other members of your team. Communication is a critical component of what we do, yet so often we choose to intricate or obscure our messages. Graphs are not just a collection of bars, not just a bunch of colored pie wedges, and not just a bunch of lines with numbers. Like all things, they are a tool, and tools should be used correctly, or you risk doing more harm than good. If you have found this interesting, then I fully recommend you do some further reading (PDF link). [This piece was reprinted from #AltDevBlogADay, a shared blog initiative started by @mike_acton devoted to giving game developers of all disciplines a place to motivate each other to write regularly about their personal game development passions.]