A Heavy Problem
July 1, 2008 - Robin Walker

As Gabe mentioned in his lengthy response to an email recently, the next class pack will focus on the Heavy. For the Medic and Pyro packs we kept our goals for the pack pretty close to our chest, but for the Heavy we've decided to open up the process a little. Our hope is that you'll get a better insight into how we approach design problems, and have some fun thinking about the problem yourself. We do design collaboratively at Valve, and one of the side effects of it is that we really need to be able to evaluate design ideas as objectively as possible. Otherwise design meetings would devolve into subjective arguing. We've found that the best method of working objectively is to have clear goals up front. Once we've got clear goals, we can throw a bunch of ideas up on the board and measure how well each idea achieves those goals. Often the work of testing those ideas against the goals causes us to further refine or clarify the goals.



Here's a list for how to help define the problems we want to solve with the Heavy pack. It's pretty much exactly what we would start a design meeting with. Try coming up with a new unlockable for the Heavy that addresses the goal, while staying within the constraints as much as possible. The extra section includes other details that are useful when trying to compare two viable ideas.

Goal: Make the Heavy more viable when he has no Medic to pair with.

Constraints:

It shouldn't have a cumulative effect when being healed by a Medic as well. Heavy/Medic pairs do pretty well as it is.

It shouldn't significantly change the Heavy's role, relative to other classes. In particular, it shouldn't significantly encroach on another class's role.

It should be understandable for both the user and the player it's being used on.

Extra:

How much work is it? How many new models, sounds, effects, etc?

Does it deepen the Heavy's skill curve? Is it easy to learn? Hard to master?

Is it an interesting tool to choose relative to the base Heavy weapon it's replacing? What scenarios can you envision in which each is useful? What arguments can you raise for why each is better than the other?

How often does the Heavy need to think about it? Is it something he uses once every 5 minutes, or is it something he needs to be constantly thinking about? A greater impact on player decision making is generally a good thing.

How many other features of the game does it affect? Often, the best ideas are "economical", with a small set of required actions, but a wide set of resulting effects.

Finally, keep in mind the skillset required to be a good Heavy. He doesn't really rely on fine aim, since his minigun has such a wide spread, instead relying on more tactical skills, like these:

Being in the right place before he starts firing, because he has little ability to move while firing.

Good anticipation of enemy behavior, for both the above point and because his minigun needs to be spun up before firing.

The ability to estimate the amount of damage he's taking. It takes time for the minigun to spin down, so he needs to be able to know when it's time to retreat several seconds before his health has run out.

The ability to keep firing at a target while still keeping an eye out for other dangers, in particular Snipers & Spies.

Obviously, there are many more, like the full set of skills required to be a good user of an invulnerability charge. If you compare his combat related skills to that of the Soldier or the Demoman, you'll see he has a unique set that's less about aiming & dodging, and more about commitment choices and accurate battle evaluation. When thinking about your new unlockable idea, think about the new skills, or changes to old skills, that it'll require the Heavy to learn. It's best if those new skills aren't identical to ones required of other classes, or class distinctions become less interesting.

In the end, solutions almost always require tradeoffs, from the breaking of a constraint to the addition of a large chunk of work to solve understandability. A framework for objective evaluation is a great tool, but ultimately, something also needs to be fun, and that's hard to evaluate on paper. We try to end our design meetings with three potential solutions, and then implement crude versions of each. Playtesting those crude versions usually shows us some pros and cons that we didn't see in the meeting. Solving those cons, without giving up any of the pros, is the real meat of game design.

I hope you have some fun thinking about this with us.

As Gabe mentioned in his lengthy response to an email recently



......

he couldve answered other emails you know
and got tired of ppl asking all the time so he just started saying "heavy"

Hi,

this was posted already a while ago in general section