The Problem with Pretty Damn Quick

The agony and the ecstasy of Valve is they don't release until they're ready. When this goes badly, it could be a recipe for timid over-design that boils out the essential flavours, but when it goes well, such as the recent Engineer update, it makes genius games. In fact, Valve at the moment feel like they are on a whole different level of game design from other companies and Team Fortress 2 is the boiler room in which they sweat out their best work.

Take one design which has been simmering in beta for over a year - the Pretty Damn Quick. This is the engineering wrench which allows you to build buildings faster, at the cost of not being able to upgrade them. It is an 'obvious' design, in that it makes a net improvement to one parameter, while removing another. And there is no hint of the PDQ in the actual release.

Or is there?

Surprisingly, there is the reverse: the Gunslinger. The Gunslinger allows you to build and upgrade all buildings normally - except the sentry, where it allows you to quickly build a sentry which cannot be repaired or upgraded at all. The inversion in this design is that it is the building that cannot be upgraded, rather than the ability to upgrade which is removed. The reason why is obvious in retrospect: an engineer with a Gunslinger is still able to upgrade the buildings of engineers he works with, but an engineer with the PDQ is not able to assist his team mates - and the Team in Team Fortress 2 highlights why the Gunslinger design is the better choice.

(As for why it is only the sentry which is modified by the Gunslinger design: the tf2 blog post about the Repair Node is a lessons learned on why the teleporter and dispenser should not be messed with).

If you look at the other class updates in this light, the balance of unlockable weapons favour team play over individual prowess: the Jarate and Huntsman allow the sniper to move up alongside his team to assist, bleeding weapons highlight enemy Spies to other team mates instead of improving instant kill chances, the poorly received Scout update improving the ability to distract and harass instead of assassinate, the Scottish Resistance providing superior area denial abilities.

So what next?

If you've missed the analysis on the forums, the Polycount update will include community weapons with new abilities and the underlying message is don't worry about the game design - Valve have got that covered. Despite the forums being filled with back seat game designers, like myself, none of them are at a stage where we can conduct wide spread testing and analysis of games to the same depth that Valve is capable of. I find this a little surprising: play testing is something that should be easy to crowd source by distributing a server side mod, but the combination of community organisation and technical ability appears to be beyond most forum members. I suspect this is because game design is ultimately dictatorial - which is why the variant model used by Angband development (a gateway drug which is easy to edit leading open access to the clean source code combined with lots of bad game design) works so well. In order to organise external testing for Team Fortress 2 of the sort required to match Valve's game design abilities, you'd need to find the group organisation, game design and reverse engineering skills in the same individual or tight knit team, virtually fully formed.

But it turns out what is next is actually Alien Swarm, the free to play source mod released with source code, a tile based generation tool set which includes procedural level creation tools and access to the AI director. Alien Swarm is an entirely different kind of boiler room, and seen in the light of the misdirection of the PDQ beta I believe Valve are putting a number of free tools out there to see what the community can do with them.

We know that Valve are experimenting with procedural content generation, because Gabe has told us so, in an editorial written for Edge Magazine in December 2008. At the time, everyone assumed he was talking simply about the AI director in Left4Dead, but he must also had in mind Alien Swarm - the team of which Valve had hired the previous year - and was 'thinking aloud' about whether procedural content generation was possible for level design as well as pacing.

The procedural generation in Alien Swarm is about as simple and generic as you can make 3D generated levels - so simple at the moment it doesn't necessarily guarantee connectivity. It is template-based, much in the same way Torchlight builds it's levels, although at a lower level of detail, and the view angle deliberately prevents more complex 3D geometry such as bridges and subways which would complicate the level generation algorithms. It does do some clever design with tags for various room templates to allow the random levels to be closed correctly to avoid players being able to fall off the edge of the world - an issue which 2D level designs don't face.

What it does give you is source code, the Source engine tool set and a design vocabulary to build on - and I believe Valve wants to see what is possible with that combination. What won't be possible with Alien Swarm is more complex 3D geometry - and you should ignore the temptation to port your favourite 2D roguelike level generator to the Alien Swarm source code. But, as Mad Tinkerer points out, there is real scope for creating a procedural Zelda-like - go here, destroy these things, get this door key, then go here - something that no one has tried to build using a roguelike engine. The tag system appears ideal for procedural puzzle building, there is enough of an in-game vocabulary of gates and triggers, and the possibility of using Source engine physics should be enough scope to (procedurally) build something beautiful.