A very simple, yet very important rule that any independent developer must remember. For Introversion Software’s latest game, DEFCON, the only real content that we made was the audio. Almost everything else in the game is generated from publicly available information – the locations of cities, longitudes and latitudes of the various coastlines and country borders of the world are all freely available on the internet. DEFCON was in development for about a year. Introversion’s Darwinia, on the other hand, has about 10 hours of game-play from hand-built content, and took 3 years to develop. And each of the landscapes in Darwinia is generated procedurally from a few lines of text – if each of these landscapes was handcrafted too, who knows how long it would have taken.
With each new generation of console, the costs of creating game content, in terms of both time and money, are increasing at a tremendous rate, and it is just unfeasible for a small developer to be able to keep up with such escalation. This is where Procedural Content Generation comes in handy. Procedural content is content that has been created by a computer algorithm rather than custom made by an artist. This content can be created completely dynamically, or can be generated based on some external input, from a user, or a text file, for example.
Let’s say that, as an independent developer, you wanted to make a game in a similar vain to GTA3. You could spend months working on a single city, adding buildings and texturing the world, or you could spend a few weeks working on a way of creating these cities procedurally, the end result of which would be that you have an almost infinite number of cities that you can play through, with a vastly reduced development time.
You might argue that a city created in this way would be far less detailed than one created by hand, but that all depends on how much effort you wanted to put into your dynamic content. Your dynamic buildings could be simple boxes, with textured windows and doors, or you could have the buildings include real, dynamically generated windows based on the size and architecture of your building, which could then be textured depending on the neighbourhood that it is placed in.
These screenshots are from a procedural city generator written by Chris Delay for Introversion Software’s current game in development, Subversion. This is a great example of rapid procedural content generation – after a week's work, we now have a way of generating fairly convincing city layouts with dynamic buildings, whose size is dependant on the population density of that area of the city. As you can see, the same algorithm can be used to generate a number of very distinctive styles of city, simply by changing some of the value inputs into the generator.
Such is the flexibility of these systems that, with a few small changes, the same algorithms can be used to create completely different objects. In the case of Subversion, the same functions can be used to generate the layout of each of the buildings placed in the city.
Obviously, hand-designing the layout of every single building in a city that size would be a ridiculous task. It would take hundreds, probably even thousands, of man-hours. An algorithm written by a single person however can do the same task in seconds, and can be adapted to any other purposes that you might need. The trees in Darwinia, for example, were generated using a similar principal – lines ‘growing’ outwards from a seed point, branching out a number of times along the way.
For a company with limited staff, and no 3D Modellers, this is obviously a far more desirable option than spending months hand-crafting loads of models.
Procedural content also allows you to vastly increase the scope of your game. Using the previous example, given the choice between a single hand-built city, or 100,000 comparable cities generated dynamically, the decision is obvious. Will Wright’s Spore is taking this to extremes – an entire galaxy, from whole solar systems right down to the microscopic life-forms on the planets in those solar systems, dynamically generated for every single player who loads up the game.
Procedural content generation isn’t even a new thing either – in fact, most of the early video games used procedural generation as it was the only way to fit the vast amounts of data onto the relatively small mediums available at the time. Elite and its sequel Frontier are perfect examples of this – dynamically generated solar systems with dynamic missions and a whole host of other features, all created procedurally – an essentially infinite universe that can fit on a floppy disk.
Of course, you can generate more than just static models and shapes procedurally. Textures, sounds and even animations can all be created at runtime algorithmically. Going back to a previous example, Spore features both dynamic animation and texturing of the creatures that a player can create. Animations are created dynamically based on the topography of a given creatures skeleton, allowing it to walk, run, eat and even dance. This creature can then be given a texture, which is dynamically applied to the body based on the location of its head, stomach, back and other areas of its body.
A more extreme version of this is a demo called .kkrieger, a demo created by a team called .theprodukkt. .kkrieger is a First Person Shooter, in which everything is generated entirely procedurally. The level (it only contains a single level – it is a demo after all), textures, models, animations, sound – all created dynamically by the game at runtime. What’s even more impressive about the achievement is that, as well as some nice visuals (all things considered), the entire game is only 96kb – less than the amount of information you downloaded to read this article! If all of this data had been pre-made and stored traditionally, it probably would have taken hundreds of megabytes of space.
Of course, there are some downsides to procedurally created content. For starters, if your entire game is created procedurally, it can be difficult to make areas look unique – it would be very easy to end up with level after level which, while laid out differently, would look very similar. This means that some human intervention is needed in order to spice things up a bit.
Darwinia is a good example of this – while the landscapes in Darwinia are created procedurally from simple input strings, all of the buildings in the game had to be hand placed, and a number of scripted sequences written. While completely random and fully dynamically generated levels were attempted, it proved incredibly difficult to actually generate areas which were fun to play in this way.
The other major disadvantage is the amount of time it can take to dynamically generate content. For example, it might only take a fraction of a second to generate a single building in a city, but once you are generating an entire city with hundreds of buildings, as well as road systems, it adds up to some fairly noticeable load times. This problem is especially evident with the aforementioned .kkrieger – there is a fairly long loading time at the start of the game while all of the content for its level is generated. This also means that a more powerful computer is required to run the game than if the data had been pre-made and stored normally.
Despite this, procedural content generation is a vital tool for small developers, and, some might argue, the future of the industry itself. With development costs spiralling out of control, publishers are becoming more and more reluctant to risk money by trying new things, preferring to stick with tried and tested methods, instead of creating original games. By using procedural generation methods to drive down costs, developers could gain more freedom to test new ideas, and indeed, without procedural generation, small companies like Introversion probably wouldn’t even exist.