Interview with Robin Walker of Valve Software

Interviewer: Steve Lieb
Robin Walker of Valve Software

1.  TF2 seems to really be "pushing the envelope" of the first person shooter to integrate (for the first time I can think of) the visceral goals of a typical FPS (survival, weapons, frags, flags) with a larger strategic 'concept'.  Can you discuss a little bit about how you got to this point in the design of the game?  I mean, it started as a simple Quake2 port of TF, right?  You seem to have accepted a radically higher standard for what you are planning to put into the game than that - can you talk a bit about how you went from there to here? 

ROBIN WALKER: It would be hard to answer this without delving a bit into the history of TF, so I'll try and keep it short. The original design for TF2 was done by John Cook and me, a few months before we came to Valve.  It was a culmination of all the things we'd learned throughout the development of TF1. It wasn't a direct port of TF1, but it wasn't a big step forward either. We were a small company of 4 guys, and we took that into account when we designed it.

When we came to Valve, we showed them what we were working on, and they liked it. We started working on the Half-Life version of TF2, and had been doing that for a couple of months when Valve offered us full-time positions, which we accepted.

Here TF2 took a turn. John and I'd been getting more and more dissatisfied with the design of TF2, for a couple of reasons. We'd been exposed to Valve's expertise for several months, and already we'd learned enough to believe we'd made some wrong decisions in the design. We'd also been exposed to Valve's artistic and development talent, and with some of that behind TF2, we really began to believe that our original design for TF2 wasn't all that it could be.

So, we started afresh. Valve taught us a lot, and gave us much better tools, and we produced a much better design. John and I play a lot of RTS and turn-based combat games, so it's no surprise our game has a heavy focus on strategy.  Our desire to focus TF's combat on strategy has always been there, it's just taken us a few iterations to achieve it.

2.  I've seen interviews/previews that discuss the strategic map handling, but they typically have covered it as an aside from the gameplay - but I'd like to go into more detail.  How is this scripted?  Is the structure linear - i.e. the "game" advances either forward or backward along a single "line" of maps?  Or can it be a tree of alternatives?  

ROBIN WALKER: The map handling is done through a scripting language that hooks into the events passed to it by the server. It has the ability to note down any events, with any parameters it wants, and recall them later. So if the map wanted to know who destroyed a part of an installation, and at what time and with what weapon, it could note it down, and recall it further along in the campaign.

Our current campaigns are all linear, but the map scripting is perfectly capable of a branching structure. We stick with linear because our campaigns are designed to be played over the net with any mix of veterans and beginners, which restricts the complexity of our design a bit.  The great thing about the scripting language is that it's external to the map, allowing you to alter the map's behavior without recompiling the map.  You could take the maps from a couple of our linear campaigns and, within a few minutes, create a simple branching campaign out of them.

3. Can the results be scaled - i.e. an overwhelming victory by one side would advance the script two steps instead of one?  Can the scripts be dynamic and/or nested - for example if the switch is thrown you no longer win by capturing the flag, but now by killing their medic (or something)?

ROBIN WALKER: Yes, the scripting can handle these easily. All the actual goals of the maps are set by the scripting, so changing the goals at any time is as easy as creating them in the first place. The actual result of actions on the map is also defined by the scripting, so achieving goals on a map might result in moving a map or two ahead, or just altering the environment further along in the conflict.

4. Can any of the actions within the maps be tied to these scripts?   Or is the simple win/loss the only thing that affects where the strategic part of the game goes?  Are the scripts able to handle conditional events - if so, how broadly 

ROBIN WALKER: The scripts can hook into almost any event that occurs. Even the definition of win/loss comes from the scripting. For example, in the Beach Landing map, the goal of the attackers is to simply make it past the beach and into the safety zone on the other side. The attackers get points for every team member who makes it. The scripting also keeps track of the number of attackers that make it. In the campaign's second map, the attackers have a limited number of lives, and they get a bonus number of lives based upon the number of attackers who made it through the Beach Landing.

5. Can the scripts affect entities or basic relationships on the map/in the game - for example, if you get into the enemy's command base, you might be able to see their [team] communications?  Could a preprogrammed event affect the priorities of a bot AI, for example?  

ROBIN WALKER: While the scripting hooks into an enormous amount of the basic game code, it doesn't quite cover everything. There are a few basic relationships that we protect to prevent maps from utterly confusing players who rely on behavior they've learned through playing our maps. The Bot AI fits seamlessly into the scripting. When the scripting defines a "goal" for players to achieve, it's also providing the information the Bot AI needs to be able to achieve it. Changing the Bot's priorities is simple... change what they need to do to win, and they'll start working towards their new goal.  

Click here for the next page!