Wormsign: procedural content for games

(brief aside: Some of my long posts carry the tag 'Wormsign', a nomenclature I thought of in this post to connotate a trend I think is just starting to emerge. The term comes from Frank Herbert's Dune series, which takes place in a desert inhabited by giant subterranean (subsandean?) worms that pounce up out of the ground and eat things sometimes. The warning for the impending approach of one of these worms is 'Wormsign'; if you hear it in time, you can prepare for the upcoming calamity.)

In retrospect, it seems obvious. All great ideas do.

By this point, you've probably read about Will Wright's new game, Spore. Quick precis: start off as a bacteria, advance through all the stages of evolution to become a galactic overlord. Now, as Ubiq points out, this is a five-bags-of-crack idea. Impossible to develop, as a game. Not because of the technology required, though; after all, computers can be made to do practically anything. The difficulty is in the content: how on earth are you going to get the budget required to hire the people to build compelling content on so many different scales?

Answer: don't hire them. Don't build the content. Instead, build the thing that builds the content. This technique is called 'procedural content', and it's been around for a while in the European Demoscene and in the most advanced graphics boards (think procedural textures and vertex programs). The idea is that rather than painting a scene, you instead describe the steps required to do so. This is how 3D models are constructed now; this is how simulations generate such complex behaviour.

Now, for the game developer procedural content is another layer of abstraction on top of the game's content, with all the pros and cons that come along with abstraction. Let's veer off into analogy-land and talk about cameras for a second.

Tasked with the problem of 'build a camera', the first thing an engineer will do is probably to build a camera. Duh. But then, the engineer's tendency to think in the abstract will lead her to think about the work that went into making that camera, and she'll start wondering how she can Make This System Better. And as I see it, there's a fork in the road here: either she'll focus on the verb ("build me a camera") or she'll focus on the noun ("build me a camera").

Focusing on the building leads toward making a camera-building kit. You've abstracted the camera out, and now you can sell the kit to people who can build exactly the camera they want! (Too bad they'll have to learn to use the camera kit before they learn the camera.) Focusing on the camera leads toward making a point-and-shoot. You've realized that the original problem statement was misfocused: "build me a camera" actually means "build me something I can sell to people who want to take pictures". Assuming (yeah, I know, it's a big assumption) that you're aiming at the mass market, you build in autofocus, and a doodad that makes the camera still work after it gets dropped the 6th time, and an easy loading mechanism, and auto-Fstop choosing, and auto-everything-else.

In both cases, there's more engineering effort involved; it's just focused differently. And you can probably build a point-and-shoot from thet camera-making kit, if you're smart enough. The relation here to Spore is that the rest of the industry has been focused on building games so complex they can't be built without kits, and then (in some cases) even providing those kits to customers so they can tweak the gaming experience (hello, modding community!). Spore takes the other tack: they've gone and built content-creation tools so complete, so full-featured, they almost don't need an operator. To use the industry lingo, the game creates its own assets.

One of the consequences of this mode of asset creation is that the stuff your operators *do* have to create -- the artistic part of content creation, so to speak -- can be captured pretty concisely as the inputs to the asset-creation routines. We go from needing many, many inputs whose values are closely constrained -- maps must have height and position data specified exactly so, character models must be in 3DS format (the specification for which runs to 400 pages), etc -- to needing few inputs each with a wide range of potential values. That leads to the possibility of transmitting many 'assets' very quickly, and to the potential for randomly-created assets to be aesthetically pleasing. A high potential for random content leads to high replayability in a game -- it's one of the oldest tricks in the arcade-game book, in fact. And easy transmission leads to another holy grail of modern game design: user-created content.

MMOGs like Ultima Online, Everquest, and World of Warcrackft have been promising user-created content since the dawn of the genre. "Come play in our world! Hold archery tournaments! Woo an e-spouse! You Can Do Anything You Want!". The problem with that expression of user-created content is that MMOGs either don't allow for a wide breadth of interaction between players. You can talk to people, or (maybe) hit them with a sword, or make your guy play a little animation that lasts maybe 4 seconds and has no effect on the world at all. Of course, you can also interact with other players indirectly, cooperating with them toward some short-term goal -- kill the dragon, rescue the princess, drive the villagers before you and hear the lamentation of their women, et cetera. But you can't really affect other people, or the world at large, in the long term.

Spore promises a different kind of user-created content. Rather than working with (or against) people in some artificial turf, players instead work with (or against) things other players have created. This solves the problems that MMOGs have by not promising player-to-player interaction (unless you want it, and start a multiplayer game) or a world on which players want to have a permanent effect. Instead, players use each other's assets. Potentially without even knowing they're doing so! That's a lot of power, and a lot of potential replayability.

Of course, prodedural assets don't solve all the problems game developers have. You still need incredibly talented people to build the engine that takes player input and turns it into aesthetically meaningful output, and you still need someone to build a fun game with the assets your procedural engine put together. But as a mechanism to reduce the busywork required to make a fantastic-looking game -- which is necessary, but not sufficient, for a game's financial success -- it's a fantastic idea.

Let's hope Spore has the gameplay it's going to need to be a success. The people holding the purse strings are sure to be watching this one.