Universal Truth Number Three (pt.1)

Recently through the mysterious and tenuous connections of social media, I was asked a few questions about the game design of Halo multiplayer.

Yes, the first Halo. Combat Evolved.

Yes, I know that game came out when dinosaurs still roamed the Earth, but there are still a few things about the development process that might be interesting to designers.

One question in particular caught my attention: “Was quick-camo intentional?” Paraphrased, I read the question this way:

"When the player picks up the Active Camo powerup, they turn invisible. If they shoot while they're invisible, they become visible for a while. But some weapons seem to make the player fade in and then back out of view faster than others. Was that intentional?"

The answer is related to one of my Universal Truths of Game Design. The Universal Truths are rules that I have figured out throughout my career in game development. I know they're true, because I have followed these rules and succeeded, and I've ignored them (or just been ignorant of them) and failed. In this case, the answer comes from;

UNIVERSAL TRUTH #3: You must create a mental model.

That means that, as a designer you must create a theoretical model that describes how the systems in the game should act with each other.

Game data design and balancing is an incredibly complex task. As anyone who has ever opened up a set of modern game tools knows, there are an overwhelming number of places where a designer can change numbers that can affect how the in-game systems behave.

Here’s an example picture of an open game toolset that I grabbed off the web:

It’s a pretty typical screenshot of a set of development tools. There are windows that allow the designer to place objects in 3D space, and along the right side of the screen there are a bunch of folders that hold different types of data that you can fiddle with. And adjusting any of the numbers will change what happens in the game.

I’ve seen it happen many times, a good game designer is tasked with making the game more fun and, faced with the complexity of that job, gets overwhelmed and doesn’t know what to change to make the gameplay better. At best, a designer stuck in that situation is ineffective. At worst, the game sucks because of them.

In my process, I make a mental model of how I think the system should work. It gives me a place to start figuring out what numbers to change, and in what ways I need to change them. From there, I adjust the data values to suit that model. And the more rigorous I am with my mental model, the more confidence I have when I'm adjusting the sea of numbers in front of me.

Let me give you an example.

As we were working on Halo, the team lead’s first choice was to make the guns work the exact same way in single player and multiplayer. The responsibility for balancing all those numbers had been given to a senior designer on the project, but the general feeling was that his changes were not making the game more fun (see above).

I talked things over with Jason Jones (the creative genius at the core of Bungie) and he and I agreed that somebody with more experience in game balance needed to take over the job. Initially, Jason volunteered to handle it all himself. As the man behind the game balance of Myth, and the Marathon series of shooters he was more than capable of the job.

But I pointed out that multiplayer would have very different needs for the guns than the single player team. Weapons in the hands of dumb AI bad guys need to provide fun challenges for the player to overcome, but weapons in the hands of a player are a different matter. As a quick demonstration, think about the gunfights in Halo. In most cases, encounters have multiple bad guys shooting at you at one time. Each gun can be adjusted to be a little bit weaker in enemy hands so that player (the hero of the story) doesn't get overwhelmed. But in multiplayer, most decisive fights are one on one. Guns needed to be unique and powerful. I also pointed out that if we just used one set of data, as I was changing the gun data for multiplayer I might be damaging the overall balance of the single player game. Jason agreed, and we decided to "branch" the data and create two versions of the numbers, one for single player and the other for multiplayer.

So starting out, I had a handful of guns with some data already attached to them based on the single player game. I had the freedom to change whatever I wanted. All I needed to do was figure out how to make the fighting fun. I needed a roadmap to follow. A mental model.

But where to start?

Some of my mental model was shaped by the choice of weapons we'd decided to put in the game. Jason picked the weapons for Halo, and they are arranged in a matrix. Each weapon has a role that it is the best at, and the roles roughly correspond to ranges in a gunfight. So for example the shotgun is deadly at close range, but it’s almost useless at medium range and beyond that it can’t even hurt people’s feelings. On the other hand the sniper rifle is super-dangerous against targets that are far away, but difficult to use against enemies standing right next to you. So the matrix design was the basis of my mental model. But that brought up two interesting issues.

First, the process of making weapons fit into set categories is much easier when you’re talking about imaginary stuff. When you’re trying to define a set of strengths and weaknesses for a Covenant plasma rifle, nobody is going to argue with you. (At least back then they didn’t. I bet that today it would be a lot tougher to make any old changes you wanted to.) But it's a very different experience if you’re trying to define the strengths and weaknesses of real world weapons. People tend to have very strong opinions about real guns – a lesson I learned working on the SOCOM series of games, as well as on FarCry 2 (which I may discuss in another post).

The second interesting thing about shaping data in a matrix model is that you can’t be too aggressive. I grew up shooting guns. Especially shotguns (I was a redneck child of the bayou) So when I first started working on the multiplayer shotgun, I slanted the data design towards close range to suit the matrix. But in reality, people hunt birds with shotguns. And deer. And bears, and wild boars and other dangerous stuff. In the real world, if you had to be standing right on top of a bird or a deer for a shotgun to be effective, you likely wouldn’t be a very successful hunter. Or worse, if you were hunting boar or bear they might end up hunting you instead. (Yes, I am aware of bow hunting. Shut up.) Shotgun pellets spread out after they exit the barrel of the gun. The amount of spread is called the choke, and even shotguns that have less “choke” and a wider spread still have fairly tight grouping of pellets. And even though the pellets are spread out a little, they’re still made of steel and they come flying out of the gun at supersonic speed. If they hit anything - especially something made of skin - they rip it apart. Based on my real-world experiences, I started with shotgun values that were more realistic. I wasn't aggressive enough in adjusting the numbers. Over multiple play tests I realized that the shotgun was too useful beyond short range. It was trampling over other guns and their place in the matrix . So I made the effective range much shorter. Unrealistically short. Ridiculously short in fact - to help differentiate it from other weapons. Like I said before; when you’re balancing a matrix; be aggressive.

But just making the Halo multiplayer weapons respect their roles in the matrix really wasn’t enough. That’s kind of “first-person shooter design 101.” In a first-person shooter, weapons are the stars of the show. They need to look good, and sound good. They need awesome animations. They need to be effective in their roles and they have to make the player feel powerful and competent. But perhaps most importantly, they need to reward player mastery.

To accomplish that, the design needed depth.

(continued in Part 2)

Please join the discussion at www.hardylebel.com