For general feedback about the game.
Steam SupportVisit the support site for any issues you may be having with the game or Steam.
We're plugging away at the Engineer update. He's an interesting class to work on, because he creates a larger footprint in the game than any other class. This means we have a lot of options to work with, and the resulting set of ideas is truly daunting. Since we've already built and playtested some things that haven't worked out (with no false modesty, I think we've mastered the art of rapidly making things that aren't fun), we thought it might be interesting to give you some of our failed experiments.
The first was a new building internally known as the Repair Node. We gave Engineers the ability to replace any current building (teleporter entrances and exits were considered one building for this) with the Repair Node instead.
While deployed, the Repair Node would draw from a pool of energy to fix damage to nearby buildings. When the node ran out of energy, it would stop repairing and regenerate up to full, creating a window of opportunity for the attackers. When sapped, the Repair Node's repair function was disabled for the duration of the sap.
The goal of the Repair Node was to solve a perceived problem in the Engineer's play experience: always having to be tied to your base. The Engineer often has little to do after his base is built and fully upgraded except wait for the inevitable Spy sapper attempt, or for the battlefront to reach the base. The Repair Node was meant to buy the Engineer time if he wanted to range out to gather metal or harass the enemy with his shotgun.
This is usually how we approach our game design: Identify a problem, then discuss the ways it could be solved. Our experience told us that even when the Engineer didn't feel immediate pressure, he still couldn't range out away from his base. If a Spy, Soldier, or Demoman found the base unguarded, it didn't take long to blow up. The further away an Engineer was, the fewer buildings he would be able to save from sapping. We also felt that the Engineer invested a lot of up-front work to establish bases that were very easily destroyed. Thus the repair node was born.
Play-testing the Repair Node showed us one expected, and two (somewhat) unexpected, outcomes. The expected outcome was that bases were far harder to destroy, and turtling became a super effective strategy. Fortunately, this is the kind of problem that can be attacked by turning the correct game design knob, and the Repair Node had a lot of available knobs. We could lower the rate of repair, lower the amount of repair energy, lengthen the vulnerable period, and so forth. We tried several options. One change we made was to add diminishing returns so that two Repair Nodes working together were less than perfectly efficient, and adding a third didn't really help at all.
Despite the design choices we had available, we were never really able to get the Repair Node to feel balanced for the attacking team. TF2 maps tend to be designed with very specific predicted Sentry placement locations and length of Sentry survivability. The Repair Node distorted old favorite maps and made testing new ones more difficult by exaggerating intentional choke points and creating new choke points where they didn't previously exist.
The first unexpected outcome of the Repair Node was the team realizing just how valuable the Dispenser and Teleporter were to so many aspects of game pacing. If the Engineer isn't able to build a Dispenser, his team loses the support power that the Dispenser provides. In most games Dispensers are ubiquitous. You don't really realize what you've lost until you've lost it. Fewer Dispensers had the effect of slowing attacking teams down in a variety of ways: Teams were more fragile, metal was harder to get to the front lines, and team rally points were harder to define.
An Engineer who took a Repair Node instead of a Teleporter put his team in an even less viable position. The pacing of many maps became completely broken without Teleporters in play. Teams weren't able to push as effectively and the lines of battle moved closer to the spawn points. This lack of flexibility meant that attackers weren't able to hold gains and matches took longer to complete.
The second unexpected outcome was downstream from the first. Teams perceived Engineers with Repair Nodes as less "friendly", specifically because they weren't building Dispensers or Teleporters. In retrospect, older data at our disposal should have known this would happen. Prior to TF2's release, the Medic had weaponry that was significantly more powerful, leading to highly skilled players playing Medic as a purely combat class. Aside from the balance issues this created, it also resulted in a Medic that wasn't interested in healing anyone, which didn't typically sit well with his teammates. Their perception was that healing is the Medic's job. Medics who didn't do that weren't perceived to be team players -- an identical reaction to Engineers refusing to build Dispensers and/or Teleporters. Like many design exercises we didn't learn what to do next so much as what NOT to do.
