I actually got dirty with procedural world creation in something I've been working on since forever - a pet project which I'm hoping to share with the user group at some point. Here are a few reflections.

Procedural systems essentially take a varying input and use a fixed set of building blocks and rules to create an output. The way I thought about it was to decide what I wanted for the output, then think about how I wanted to specify the input, and finally deduce what the building blocks would have to be to make all this happen.

That last stage - deciding on the building blocks and writing the code to make it all work - is incredibly good fun. You've got a set of nicely-defined tasks whose success can be easily verified, and there's a real sense of achievement in varying a few simple parameters and seeing whole new worlds appear.

Now, locking down the inputs, outputs and building blocks is actually quite a challenge.

Inputs

Here are some input possibilities for a procedural, zelda-style dungeon game :

• binary file created by level editing tool specifying exact positions of each monster and object
• text file specifying overall populations of monster types and objects, and size of world
• N greyscale textures showing probabilities of encountering N monsters/objects in world footprint
• single 'difficulty' or 'game length' factor

It's worth noting that each different method of authoring requires a unique ratio of 'user input' to 'pre-defined rules and building blocks', and because of this the levels will turn out quite different.

For example : if the system just took 'difficulty' as an input, it would be very easy to author 100 levels which were progressively harder to pass - but they'd be pretty generic. No chance to make level 15 a really long corridor, level 20 a huge room with all the monsters hidden in the corners, and so on.

A perfect example of this is the old C64 game The Sentinel by the legendary Geoff Crammond :

It created entire 3D chess-board-like levels from a single number between 0 and 9999 (encoded as a password so you couldn't just jump to any old level). The idea was that when you beat a level you would be left with a certain number of health points, and these would get added to the number of the level you had just completed - and the result would be the next level you'd jump to. A simply amazing game, if you've never played it - plus, full 3D on the C64...

A level editor on the other hand may allow for creation of very specific scenarios, but then you have a less conrete way of measuring the success of your designs (compared to a whole level created by 'difficulty'), and authoring requires a whole load of user input. Do you actually have time to make 100 levels?

Another question to ask yourself is what method the author will find easiest. Textures for instance - as an artist, I have a good idea of the ways I can manipulate a texture in photoshop, and would have great fun making probability textures and messing with different kinds of fall-off etc - and could end up with something which couldn't really be expressed in, say, a text file.

I recently heard of a sandbox game which had a dynamic rubbish-on-floor system driven by a greyscale texture : white meant "high probability of rubbish here" and black meant the opposite. So you could 'paint-in' trash where there were alleyways, carparks and so on - great! Unless of course you didn't know photoshop.

Outputs

What kind of thing could your system output?

• text file specifying cleverly-weighted positions of monsters, objects and walls on a 2D grid
• palettised texture where the value of each pixel refers to a wall/monster type/object/exit/player start position
• vertex and index buffers of cleverly-weighted maze world walls; populated array of MyMonster() structs

Basically, anything. You'll have to draw the world, and allow interactions with it, so output whatever is necessary to do all that.

You could definitely argue that drawing a 3D world from the starting point of a text file is in fact another whole procedural system, and I'd have to agree (of course, any game which isn't just streaming in chunks of pre-populated memory - so pretty much every game - is doing this to some degree). So procedural systems can be multi-stage, with data getting munged from one format to another. Some of the stages may also happen offline, and some at runtime.

Part 2 will discuss building blocks and rules, and how my pet project ties into all this!