Pacing defines the way we experience games. It’s a balance where there’s no real exact science, but good designers have a sense for it. To make matters more complicated, game design includes multiple distinct areas of pacing. The classic narrative sense of pacing applies to games, with rising action, climaxes, and periods of less intensity. But along side this narrative element, games must balance interactive elements of pacing. This includes learning curves and difficulty levels, as well as introducing and layering new gameplay mechanics and goals.

The first Batman Arkham Asylum game did an amazing job with pacing (much better than the sequel, in my opinion). You steadily learn new gameplay mechanics, and you steadily face challenges that incorporate new mixes of those mechanics. There are periods of intense brawling intermixed with periods of stealth and also moments of quiet exploration. Finally, as you progress through the game, the plot rises in action and the entire island physically evolves into a more crazy, hectic world to match it. They pretty much nailed pacing in each of its facets.

Because game development is such a lengthy, iterative process, evaluating pacing can be difficult. I always try to experience content during development as the player would experience it. I try to consider what reactions or issues I would have as a player. It takes discipline to be able to do this after replaying the same segments of a game over and over while iterating on it. The process reminds me of writing. You write your thoughts as they develop, but you must always reread in a manner almost like speaking aloud to really know what a sentence says and sounds like. There is a flow and cadence to writing, just as there is to game design. If you skim while you’re editing, you aren’t fully experiencing the work and miss out on this dimension. Even though you know what lies ahead or you’re just testing one thing, every once in a while you should slow down and try and experience the content as though you’ve never seen it before. When you play through your game to get a feel for its pacing, you have to do it like you’re reading aloud.

When you think about 3D level design, odds are you think about building levels in 3D—width, height and depth—fairly common fare for those acquainted with game development. But that’s not what I want to talk about. I put “3D character writing” in the heading because there is a good chance people have heard of this subject, and it helps us game developers get out of the mindset of three dimensions automatically meaning width, height and depth, which, for the purposes of this writing, they don’t (although, to be honest, I’m not sure what they stand for, or even if there are exactly three).

In storytelling, the three dimensions of a character are physical, sociological, and psychological. The idea is that if, as a writer, you only flesh out the physical dimension of a character, the character is shallow, not believable, and not interesting. Developing a character’s past and explaining the psychology behind their motives helps the audience suspend disbelief and more vividly experience the plot surrounding that character. Something similar to this strategy applies to level design.

When we were developing Conduit 2, while analyzing problems with its predecessor, we identified the level designs as a major area to improve. Most common critical complaints regarding The Conduit‘s levels involved the excessive corridors and boring layouts. We knew we were going to address that in the sequel. But another problem that bothered me was the hollow, dead feel of the environments and the player’s experience in them. The levels felt like merely containers for enemies—arenas with a thinly veiled movie set façade resembling some real life place. I didn’t view this as an art problem, but actually a design problem. We needed to apply something similar to three dimensional character writing to our level design.

One way to address this involved the characters in the level. In The Conduit, all of the characters in the levels were enemies, and all of the enemies felt like they were simply standing in wait for the player—their entire existence framed by the single moment their lives intersect with the player. As you might expect, this doesn’t help create a very believable world. Rather than having the enemies (or any characters) standing there facing wherever the player will inevitably appear, designers should setup some sort of scripted event for characters to be involved in when the player first witnesses them. Even if the event is nothing more than standing around, smoking a cigarette out of boredom, it will contribute greatly toward making the level feel more alive and helping the player suspend disbelief.

However, if we designers are going to the trouble of setting up so many scripted events, we might as well add to them a bit of meaning. A design goal I established for Conduit 2 was to have each level appear to have some dramatic event unfolding, such that the action taking place would have been interesting even if the player character never showed up. Of course, the player should have some important role to play in the events transpiring. But the player’s role should only shape the outcome of the events—not completely define them.

I think we did a decent job of this in the first level of Conduit 2. The player is on an oil rig, but the inhabitants of the oil rig are quite busy preparing for (and ultimately fending off) attacks from a sea monster. Not only are these characters visibly doing this, but there are notes the player can read, announcements over the PA, and other evidence the player can witness to help piece the plot of the level together.

Bioware games typically provide great, formulaic examples of this aspect of design. Almost invariably, the player shows up to some new environment to accomplish a step in their long-term plan for defeating whatever evil they’ve embarked on defeating (note: hero’s journey). But once the player arrives, it quickly becomes apparent that something interesting is happening in the level. It would have happened even if the player didn’t show up—but the player has shown up and will influence these events, solving the mini-drama of the level before becoming one step closer to accomplishing their overall, game-encompassing goal.

For example, in Dragon Age, when you show up at the dwarven homeland pursuing the help of the dwarves in your campaign against evil, you discover yourself in the midst of a political dispute that must be resolved before the dwarves will help anyone. The player is given the impression that the dispute’s origin predates the player’s arrival. However the player’s arrival generates the opportunity for the political stalemate to be broken (and the player is, in typical Bioware fashion, free to tip the scales in favor of either side).

I think the sociological dimension of 3D character writing also pertains to 3D level design—you need to give the player the impression that people have realistically inhabited the space and have developed an appropriate set of customs and habits.

For example, in Portal, you can look behind the broken wall panel and discover signs of other test subjects living on the fringes of the lab, and hints that the experiments of Aperture Science are perhaps unsavory. Later in the game, you get an inside look at the areas on the other side of the one-way glass: workstations, Power Point presentations, and other signs of life help the player feel that they are in the midst of a space that was recently inhabited by actual people. Plus, the player receives a pretty clear picture of the history and culture within the space without sitting through any cut-scenes or reading any prologues.

This blog post is just an early rambling, but I think there is something to be gleaned from exploring the topic. Eventually, I will try to put this together more coherently and perhaps venture to more definitively label some dimensions of level design that, when fleshed out, provide players with more engaging and immersive experiences.

On Conduit 2, I was primarily in charge of designing the weapons, upgrades, and relevant systems (such as accuracy, etc.).

When we first setout balancing weapons in Conduit 2, our starting point was “How long should it take to kill another player?” We were making a Wii game that we wanted to be a bit more casual than something like Counter Strike or Modern Warfare. We wanted players to have time to react after being shot, so we knew we wanted a model that involved multiple shots to kill. On the other hand, there were times in Conduit 1 where it seemed like unsuspecting, distant targets would have too easy of a time dodging behind cover, evading death and frustrating shooters. We definitely wanted to avoid situations where players felt that the game was unresponsive (“I shot that guy tons of times and he didn’t die, what gives?!”). So after trying some things, we settled with something between the extremes of a Modern Warfare and Halo title: around 1 second of sustained fire to kill a player.

Because we knew we were going to support player defined “loadouts” in Conduit 2, we wanted to make each weapon in a given class (primary or secondary, where secondary is slightly weaker) roughly equivalent to one another—at least in terms of overall effectiveness and desirability. Time to kill is a strong benchmark for overall effectiveness, so to establish our initial balance we gave secondary weapons a time to kill of 1 sec, and primary weapons a time to kill of 0.88 sec.

Not all weapons have the same functionality, however, so our values quickly started shifting from these starting places. For example, the HVS45 has the possibility to kill in a single headshot, but its time to kill for body shots takes over a second. The regular pistol, on the other hand, can kill faster with body shots than any other secondary weapon, but it requires keeping a steady aim while mashing the fire button as fast as possible.

Some weapons very powerful weapons, like the Phase Rifle or SMAW, start with very high inaccuracy, such that a shot “from the hip” has little chance of hitting a target. This forces the shooter to enter scope view to obtain accurate shooting, which takes time for an animation to finish. Movement in scope view is also drastically impaired. Finally, the scope view is zoomed in to such a high degree that firing on near targets is very difficult. This helped us ensure these weapons were good for what we wanted them to be good at, but not universally great.

Other weapons have very limited clip size, long reload times, or restrain base movement speed to achieve a semblance of parity with the entire game’s arsenal. We created some nifty spreadsheets with formulas for keeping track of weapon attributes, comparing weapons, and previewing changes.

With upgrades, we designed them by coming up with cool “build” ideas, and creating upgrades to facilitate them. For example, we knew we wanted a melee build, a sniper build, a tank build, a fast moving flag capturing build, a tricky spy type build, etc. We ensured that someone who wanted to play a defensive oriented character had something defensive to choose from each suit upgrade category. Same goes for all of the other builds mentioned above. It is not by accident that potent combinations like Stealth, Metal Legs, Improved Melee, and Blinding Powder exist.

Suit upgrades also helped us counterbalance some of the more powerful weapons. For example, the Phase Rifle ended up being so powerful that during initial testing everyone picked it. We new we had to reduce its power, but it was so fun to use that we wanted to find a way to preserve the very powerful version. We ended up breaking up the some of the unique aspects of the weapon and putting them back into the game as suit upgrades. This way, someone can choose to play with the powerful version of the Phase Rifle, but at the cost of other suit upgrades.

Throughout the project we ran biweekly multiplayer playtests to observe functionality and balance. We also added two very important tools for getting the most out of playtesting. First, we added some basic stat tracking to figure out more objectively what weapons and upgrades people were having success with. Second, we instituted an online forum for the people involved with the playtests to report feedback. The forum has proved vital, and design regularly consulted it, posted our own observations, and replied to our co-developers from outside of design to help keep everyone informed.

When we made balance changes, I would commonly play against my co-designers or our QA team, or observe them playing each other with the affected weapons and/or upgrades. Because we were of similar skill levels, this was effective for previewing balance changes before checking them in for our big, team-wide playtests.

For many playtests, I added notes to the instructions email describing balance changes and gameplay additions for the build to be tested. On occasion I explicitly asked participants to report to the forums about certain aspects of the game. Between these notes and my postings on the forum, one can find insight into a great deal of the balance changes made throughout the project.

I’ve added several gameplay videos from games I have worked on to my portfolio, along with blurbs about my roll on the projects.

Click here to check it out.

Finally got around to diverging from the default wordpress blog. This post isn’t so much an update because I think people are interested, but rather an attempt at making the homepage look more full

Eventually I’ll copy the posts from my old blog’s database here, and that will help fix the problem.

New personal website underway.