siosios
03-02-2010, 09:00 PM
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.
http://www.teamfortress.com/images/posts/repairnode.jpgWhile 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 both 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.
Lesson 1: The problem of the Engineer being tied to his base still exists, but the Repair Node was too heavy-handed a solution. If we solve this problem in the future, it will have to be in a way that doesn't distort the existing balance between attackers and defensive choke points.Lesson 2: The Dispenser and Teleporter are really good. We already knew this, but we didn't know that they were really, really good. Encouraging Engineers to either avoid build them entirely, or to build them in weird ways, broke the game's pacing immediately. New buildings in the Engineer update will probably take the form of upgrades, or entirely new choices alongside the old buildings, instead of replacements.
These may seem like obvious lessons, but knowing for certain why a particular idea doesn't work can often be as valuable as an idea that does. This process highlighted specifically where and why the Engineer is valuable, and how even slightly altering this value can have game-shattering implications.
Ultimately, the Repair Node was cut because it made the game more of a grind. While it definitely made it less stressful to manage a base as an Engineer, it wasn't fun. The Engineer gained a little bit of fun, but nearly everyone else in the match suffered as a result.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
In other news, our minds were blown this week when we saw Andrew Kepple's amazing Spy & Pyro cartoon (http://www.youtube.com/watch?v=-GNnftq744I). We've decided this is final proof that TF2 fans are smarter, more creative, and much better looking than fans of all other video games. On the competitive side, we've been addicted to watching CommunityFortress's (http://www.communityfortress.com/) eXtv series of commentated competitive TF2 matches. If you haven't watched any, take a look at some great European (http://communityfortress.com/tf2/news/extv-dignitas-vs-www-esh-asrock-tourney.php) and North American (http://www.youtube.com/watch?v=Bcwt8Mn6OCg) matches. If you haven't watched much competitive play, eXtv's commentary does a great job of helping you understand the tactics being employed.
More... (http://www.teamfortress.com/post.php?id=3539)
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.
http://www.teamfortress.com/images/posts/repairnode.jpgWhile 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 both 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.
Lesson 1: The problem of the Engineer being tied to his base still exists, but the Repair Node was too heavy-handed a solution. If we solve this problem in the future, it will have to be in a way that doesn't distort the existing balance between attackers and defensive choke points.Lesson 2: The Dispenser and Teleporter are really good. We already knew this, but we didn't know that they were really, really good. Encouraging Engineers to either avoid build them entirely, or to build them in weird ways, broke the game's pacing immediately. New buildings in the Engineer update will probably take the form of upgrades, or entirely new choices alongside the old buildings, instead of replacements.
These may seem like obvious lessons, but knowing for certain why a particular idea doesn't work can often be as valuable as an idea that does. This process highlighted specifically where and why the Engineer is valuable, and how even slightly altering this value can have game-shattering implications.
Ultimately, the Repair Node was cut because it made the game more of a grind. While it definitely made it less stressful to manage a base as an Engineer, it wasn't fun. The Engineer gained a little bit of fun, but nearly everyone else in the match suffered as a result.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
In other news, our minds were blown this week when we saw Andrew Kepple's amazing Spy & Pyro cartoon (http://www.youtube.com/watch?v=-GNnftq744I). We've decided this is final proof that TF2 fans are smarter, more creative, and much better looking than fans of all other video games. On the competitive side, we've been addicted to watching CommunityFortress's (http://www.communityfortress.com/) eXtv series of commentated competitive TF2 matches. If you haven't watched any, take a look at some great European (http://communityfortress.com/tf2/news/extv-dignitas-vs-www-esh-asrock-tourney.php) and North American (http://www.youtube.com/watch?v=Bcwt8Mn6OCg) matches. If you haven't watched much competitive play, eXtv's commentary does a great job of helping you understand the tactics being employed.
More... (http://www.teamfortress.com/post.php?id=3539)