You mentioned that you tried different kinds of surfaces. Can you talk about any that didn't work and why they didn't? I've always been interested in Valve's playtesting and prototyping process.

EJ: I don't think we are ready to talk yet, since some of them might end up in commentary tracks and the like. Portal's commentary will be, for fans that are interested in things we tried that ended up not working out, should be pretty good stuff.

How do you go about doing a commentary? The game is an interactive experience; in a situation like Portal, it's possible because you have levels, so you can talk about, "Here's what we did in this one, and this is what we were thinking about."

Does it apply beyond games like Portal? How would you do something like that? It's a really neat thing for everybody.

EJ: We usually spend some time really late in the product, as late as we can pull it off, because the later we go, the more interesting things we will have to say. We usually take a day or two, and there's a tool built in the game where anyone on the team can place a node and do a really short description of what they think is interesting.

We have some guidelines as to the types of things that are interesting; one of those is failures, things that we tried that sucked, any kind of non-obvious design thing, like we implemented something, and a different thing is what ended up happening, and iteration of a particular element over time is usually kind of interesting to people, like, "We started here, and we ended up at this completely different thing."

We pepper the game with this huge number of nodes, and usually the writers go through and write a script, so we can record it really quickly. We like to get everybody on the team to talk about something, and we'll go in and record a bunch of nodes, and off we go. It's really been far more successful than we expected. Honestly, we usually assume that most of our stories are pretty boring.

Valve's way of writing seems only possible with an integrated writer on the team. Does writing go through as much revision as gameplay and playtesting?

EJ: It's a hard thing to measure, but I think writing goes through at least as much revision as gameplay. One of the properties of writing is that the constraints around it are far more relaxed than gameplay. For example, you could have this gameplay idea that was really interesting, but it's impossible to make; you could never write code that could execute your idea fast enough, so writing, in some cases, ends up being downstream of some decisions -- it's upstream of some, but it's a lot easier to change.

It's just text, it's very malleable; all it takes is a brain to think about it, it doesn't take 50 people to implement it.

EJ: It gets tricky because you end up having to lock a lot of the writing down; you have to localize it and all that.

How much stuff do you end up having to throw out, in general?

EJ: I'd probably ask [Erik] Wolpaw that. At least some maddening amount, I'd guess. With Portal 2, we've changed the story in pretty significant ways more than once.

You just have to keep it wet; it's way better to make a bunch of bad decisions than to make no decisions, you have to move forward.

[But] It doesn't stop us; we've made plenty of bad decisions.

Yeah, but that's another luxury Valve has: the ability to make bad decisions because of having time and having money by being a company that is mostly beholden to itself.

EJ: Well, and to our customers.

That's very similar in a way, because everyone is beholden to their customers, but at a certain point, everything has to ship, and that certain point is very different for Valve than it is for a third-party developer that may have a publisher breathing down its neck.

EJ: The "making customers as happy as possible" business is a pretty good business. Sometimes it can get a little overcomplicated. When people start having customers other than people who buy their product, like a publisher or someone else, the chance of making bad decisions just goes higher.