Drawing Board IX: Procedural Building Generation

So, first things first: apologies for the paucity of updates recently, some work-related upheaval has been eating up a good deal of my spare time. But with everything now squared away (for the moment) regular updates should be resuming!

The topic today is one that's come up a number of times in the forums, as well as being something I've planned to write about since the project started: procedural generation for buildings. This is something that I believe will be a key feature for Metropolis, one of the things that will truly make it a "next-generaton" (no pun intended) game. But let me begin, as always, with the Disclaimer:

IMPORTANT DISCLAIMER

This series of posts are not to be read as "official" ideas for the Metropolis Project, they are simply my personal thoughts about what some cool game features might be.  The final feature set for the game will be decided by the community and the development team contracted to build the game, and may not include any of these things.

Anyone who's played city building games extensively is familiar with a problem that compounds as your city expands; a growing sense of artificiality brought on by the limited number of building models. In the first Sim City it wasn't such a problem: the game was all about strategic simulation and didn't make much pretense of looking attractive. But as games evolved and graphics improved, developers began looking for new ways to increase the visual impact of simulated cities, and players have become increasingly focused on making realistic and good-looking, as opposed to just functional, cities. The "Repetition Problem", as I would term it, is a barrier to that goal: building models which look attractive enough on their own look false and uncanny when they are repeated in close proximity. The problem is often especially acute among service buildings (e.g. fire stations, schools, etc.), which even in modern games frequently have only a single model for a given function.

Someone needs to hire a new architect.

Traditionally, developers have attacked this barrier along a number of vectors. The most obvious is the brute-force method of simply creating more and better-looking building assets. This allows bigger cities with less variation, and spaces out repetitions to make them less noticable. There are a couple downsides to this approach: first of all, 3D assets represent one of the most labor-intensive (and thus expensive) aspects of development. A game designer risks spending a lot of their budget on a feature that becomes less important the more it's developed. In other words, having twenty variations on a suburban house as opposed to ten isn't going to affect sales very significantly, but it will cost twice as much to develop.

However, even if that negative is overcome by harnessing the power of player-created assets, another, more fundamental barrier starts to emerge. As more and more assets pile up, the program itself grows increasingly bloated and unwieldy, eventually reaching a point where it taxes system resources so heavily that the game becomes unplayable. Any Sim City 4 player who has a plugin folder with thousands of buildings can attest to the effect on game speed and storage; and yet even such a massive collection is dwarfed by the variation present in reality: it's estimated that the New York metro area has close to a million unique structures.

Since it's clear that trying to create a realistic number of unique buildings by hand is hopeless, developers have used other tricks to beat the Repetition Problem. Most of these involve introducing randomness to some aspect of the building besides the model. In Sim City 4 this was accomplished by using lot models which could be distinct from the actual building; the structure was the same, but the surrounding elements like trees and sidewalks were varied. This worked reasonably well for smaller buildings, but fell apart as the models scaled up: two identical skyscrapers are going to look the same whether one has a bus stop outside or not.

Fortunately, the Repetition Problem has a solution: procedural generation. If you're not familiar with the concept, procedural generation simply means that instead of using 3D assets, buildings are created by the program on the fly, following a set of rules laid out in a script (you can read a more detailed explanation here.) Textures are often reused between different buildings. The result is that a large number of buildings can be created without modelling each structure individually; and if the proper "rules" are established in the generation script, the buildings will look varied enough to seem random, but plausibly shaped enough not to seem odd.

This technique works, paradoxically, because of the large degree of similarity between most urban buildings. "But wait!" you're probably thinking, "You just said that buildings looking the same was bad!" The important thing here is to draw the line between "similar" and "identical". Human brains are very good at pattern recognition: two things which are exactly identical stick out like a sore thumb, even where two nearly identical things don't. Take a forest for example: the trees are all largely similar, but the forest looks natural. However, two or more tree that were exactly the same would stand out and look artificial. The same applies to cities: let's face it, most buildings in urban areas are fairly boring and look like other buildings; But they do have minor variations which make them unique. Two buildings side by side with exactly the same shape stand out. With a procedural approach, you could make a large number of similar but not identical buildings.

How would procedural generation work in a game context? Procedural scripts would be handled in exactly the same way as traditional building assets: they would be assigned properties that determined the context in which they could appear and their values for the simulation (wealth level, occupancy, etc.) The only difference is that, when the simulation selected them to be constructed, they would not be simply "plopped" like a 3D model, but fed to the procedural generation program, which would determine their shape in that instance and give the result back to the main simulation. To be sure, this requires more processor cycles than just placing a model, but since the procedural calculations would only be required sporadically, as new buildings are constructed, the overall burden on the CPU would probably be minimal.

For modders, this would be a great opportunity for creating building styles rather than individual buildings; with a few textures and a good script, a modder could create an entire neighborhood of authentic-looking buildings in the time previously required for just one. The scripts that are created by the community could then be shared and downloaded just as buildings are now. The player could include them as plugins which would be used in whatever context they specified.

As an example of how this would work, let's look at a hypothetical situation. Say I wanted to create an old North German town; I could create a script which would specify houses that have peaked roofs, white plaster walls and dark crossbeams (the "Fachwerk" style, to be more specific). As the town grew, the script would create buildings which were otherwise distinct but shared these features, giving an impression of unified style but not looking like the same building repeated ad nauseam. Achieving the same effect by individually creating enough similar-but-unique buildings to create the appearance of randomness would take much longer and consume more system resources.

This is not to say that unique models on the traditional pattern would not be necessary; quite the contrary. But ultimately I think the trend would be towards using unique models for buildings that should also be unique in the context of the game, that is, buildings which appear in the city only once. Scripts would provide the "filler" which constitutes most urban landscapes.

On a final note: while procedural city-building might sound fanciful to someone used to the old paradigm, there are no significant technological barries to implementing this kind of system; If you don't want to take my word for it (and you shouldn't), take a look at two pieces of software that are using procedural generation to create 3D cities already: CityScape by PixelActive (Update: no longer available)and CityEngine from Procedural. Granted, these aren't games themselves. But they nonetheless provide a stunning demonstration of what's possible with this technology.