Sunday 1 August 2010

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.

6 comments:

The Mad Tinkerer said...

I originally got the idea from Sean Howard(of Deathspank and A Modest Destiny)'s 300 Mechanics #4:

http://www.squidi.net/three/entry.php?id=4

And to a lesser extent this one:

http://www.squidi.net/three/entry.php?id=93

The essential algorithm can be simplified even further: before making the map, divide the "dungeon" into A, B, C and however many conceptual subdivisions you want to make. Then tell the computer to pick a "Gate" and a "Key" for each area. Then tell it to generate each area one at a time with the Gate being the only way into the next area and place the corresponding Key somewhere between the start and the Gate (usually, but not necessarily in the same area).

Then you just need to come up with different kinds of gates and keys, such as literal doorways and keys/levers/bombs. But there's also plenty of examples from adventure games and RPGs where a character bars your way until you recover an item ("Quest Giver" being a Gate and "Quest" being a key). Or perhaps it's an environmental hazard such as a spike pit that needs to be crossed safely with rope. Or perhaps the way appears completely blocked until you find a convenient air vent to crawl through. Or, of course, a room where you're trapped until you've beaten a boss or fended off a few waves of enemies.

After the mandatory gates and keys are placed, the computer could also use A* pathfinding to figure out what parts of the level are the most out of the way and deliberately hide extra ammo/treasure/secret easter eggs in the out of the way areas to reward exploration and give the inevitable dead ends purpose. Or to more intelligently hide the keys.

I've been working on teaching myself programming, but I'm not quite at the point where I can implement this kind of thing myself yet.

Rune Skovbo Johansen said...

Interesting post. For what it's worth, the 2.5D platformer I'm working on has procedural level design with keys and locked doors setup in a "environment tree" similar to the one described by Sean at http://www.squidi.net/three/entry.php?id=4 . More info: http://blog.runevision.com/2010/06/first-peek-at-levels-in-eas.html

Andrew Doull said...

There's a paper which describes a very similar approach which predates Sean's suggestion - I'm having difficulty locating it though (I've filed it in the PCG wiki somewhere).

The difficulty I have is that no one appears to have successfully implemented it beyond thinking about it - Rune, it'd be interesting to see how far along your prototype is. Part of the problem is that most procedural generated levels allow you to destroy terrain, which limits your ability to proscribe a fixed route - this is out of necessity because many PCG level generators do not guarantee connectivity. I'm surprised given the increase in BSP (and other tree) based approaches to level generation not more has been done here.

Also Rune: can you create an entry in the PCG wiki for your project?

Rune Skovbo Johansen said...
This comment has been removed by the author.
Rune Skovbo Johansen said...

Thanks for the interest Andrew. While my game is a work in progress still, the door and key placement is fully implemented. I just made a blog post about it where you can also try out the game for yourself:

http://blog.runevision.com/2010/08/eas-demo-of-procedural-environment.html

I just noticed now that Mad Tinkerer also mentioned placing keys and rewards in out of the way dead ends - a method I also employ.

I'll make an entry in the PCG wiki shortly.

Andrew Doull said...

Rune: Thanks for the wiki update.

Rewards in dead ends (even short dead ends) is a classic platformer technique. See e.g. http://www.auntiepixelante.com/?p=630

Auntie Pixelante's website is an excellent source of level design analysis for many platformers.