For general feedback about the game.
Steam SupportVisit the support site for any issues you may be having with the game or Steam.
Well, we were expecting some response to A Heavy Problem, but we severely underestimated just how much interest everyone had in contributing. If you're one of the many folks who emailed us proposals and haven't received a response, please accept our apologies, because there's just too many for us to reply to all of them. From the large amount of feedback and forum activity, it's clear that many of you found this interesting, so we'll definitely be posting more design goals. For those of you still thinking about it, here are some more tools to use in evaluating ideas:
The last one raises another question: What other goals should we have for the Heavy update? Half the battle of good design is choosing the right goals and the right constraints. In A Heavy Problem, we specified a goal for you, and the constraints that had to be kept in mind. Try taking a shot at defining the overall set of goals that the Heavy unlockables should be trying to achieve. Watch out for the common circular logic trap of finding an idea you like and then trying to extract goals from it. We find it's best to not think about ideas at all at this point, and to focus entirely on more abstract goals. What are the biggest problems in the Heavy class? In what situations is it the least fun? Like idea evaluation, goal generation is a big topic in itself, and one we'll go into in a later post.
To continue from the previous week, today we have some additional finished trading card images for you to take a look at - the Heavy and the Medic.
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.
During the development process with most of our games, we end up creating content that, for a variety of reasons, may never see the light of day. Sometimes we may not have the time to bring the content to finish, sometimes we use them as a company-only experiment, and sometimes the content just isn't in line with what we're doing at the time. Needless to say, there's a fair bit of cool stuff that we've never been able to share with our fans. We're happy to say that this blog has now given us a unique format in which to share some of the unused artwork with you.
In any game there's often a bunch of hidden complexity behind some of the simplest looking features, and TF2 is no exception. One example is that of the Medic's medigun. From a player perspective, it appears simple enough: point it at a team mate, press the button, and it'll heal them. After playing with a bit, most players notice that they have to stay near their target and maintain line-of-sight to their target. After playing with it a lot, some players notice that there's some variability in the rate at which they heal their targets. I thought it might be interesting for Medics to explain what's going on here, and why.
The rate of healing actually ramps up based on the amount of time since the heal target was last injured. If it's been greater than 10 seconds since the target was hurt, the heal rate is increased. The amount of increase ramps linearly up to 3 times the base heal rate at 15 seconds since the target was hurt. So if you're healing a target who's been hurt less than 10 seconds ago, you'll only be getting the base heal rate of 24 health a second. If the target was hurt 12.5 seconds ago, you'll be healing at 48 health a second. If the target hasn't been hurt for over 15 seconds, you'll be getting the maximum heal rate of 72 health a second.
Like many additions of hidden complexity, this was a solution to a problem we observed in playtesting. Early on, the medigun only had a single base healing rate of 24 health per second. One behavior we saw players exhibit was that of retreating away from the front line to get healed by a Medic, before returning to combat. Over time, we saw players stop doing this, when they realized that the time it took to be healed back there wasn't worth it. They could have kept fighting at the front line, died, and respawned in much the same amount of time. We wanted to encourage that retreat-for-healing behavior, so we needed to reduce the time it took. We didn't want to affect the healing rate 'in combat' though, so we added this ramp. By using the time since the target was last hurt as a measure of how much combat the target is in, we could essentially tune two different healing speeds independently. The base amount is the rate of healing 'in combat', and the fully ramped amount is the healing rate for resting 'out of combat'.
