For general feedback about the game.
Steam SupportVisit the support site for any issues you may be having with the game or Steam.
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:
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.