Procedurally generated city by @mrdoob.

What we talk about when we talk about procedural generation: Perlin noise. For those readers who don’t know what procedural generation is, it’s code/algorithms written by people (or algorithms written by other algorithms that are written by people) that enable game-spaces to populate with trees, buildings, etc., right away without relying on the programmer to code every building or tree or brick or leaf by hand. Players have probably seen curling smoke or rolling clouds in a game, perhaps wondering how the programmers did that. It’s through an algorithm (or a derivative of it) created by Ken Perlin in 1983, something now called “Perlin noise.” Smoke and clouds and other textures looked less mechanical and more natural after applying the algorithm, and game-creation and graphics began to improve, having now achieved photorealism.

The natural progression for procedural generation then is to go from naturally occurring phenomena to built environments, games that feature dungeons, buildings, and even entire cities/cityscapes (and the items that occupy them). If you’ve played any of the Diablo games, you get dungeons and loot that are almost randomly generated (within the parameters of the algorithms used to create them). Games such as No Man’s Sky and Elite Dangerous contain procedurally generated structures that vary from one structure to the next based on an executable procedure’s “decision” to choose one shape instead of another, one texture instead of another. The algorithms used to generate these things can be either simple or complex. Follow this link to see a 100-line code tutorial on how to make a procedural city of 20,000 buildings that you can navigate from the air. These structures (and other elements of “machine-created” material culture) dot landscapes to create something I am calling “cultural noise.”

Procedurally generated landscape, walls, etc., in Diablo II. Image Holyvirus2068.

Much in the way Perlin noise creates a forest of trees of slightly different shapes, sizes, and textures, “cultural noise” creates buildings, bricks, textures, littering the landscape with items to find, ruins to explore, and other instant manifestations that provide the illusion of occupation by a sentient species (human or not). There might or might not be rhyme or reason to why you find an old weapon lying around, or why there is a column in the wilderness, or why there are dozens of research shelters on every planet in a universe-sized universe. Unless these items are tied directly to quests or game narrative in some way, they are just junk (noise) in the landscape to give the player a particular feeling. And that’s the main difference between built environments in the virtual world vs. ones in the real world: emotional impact. Just as thousands of trees create the feeling of a forest for the player (who may or may not choose to explore the forest, but is satisfied with a forest-y feel), the same is true of cities with buildings in the distance. Cultural noise reassures the player that they are in an urban environment, or a place once occupied, even if that occupation never actually happened (even if the game’s lore tells argues otherwise—but therein lies another sticky wicket: does the archaeological evidence within a game support the overarching gamelore?).

When talking about built environments in the real and virtual worlds, it is important that we understand the reasons for their respective constructions. Why build a city or a house in the real world? Why do the same in a game? In a game, it’s not a city, but an emotional transmission of a city. It’s not a house, but instead it is what a house feels like. The coding strives for communicating impressions that are accurate instead of accurate representations of things (although some series such as Assassin’s Creed excel at both). In games, buildings are placed in areas not because that’s where they must be placed, but instead where they ought to be placed. The necessity comes from the code instead of the landscape and surrounding features. “If there’s a mountain lake, put a house beside it,” says the author of the code. Not: “the house should be put beside the lake because the area is pretty, the residents need water, and there are fish to catch.” In the real world, people build houses out of the fundamental need of what the house does for the occupants. Games build houses under the direction of code and the fundamental need to populate a space in which to drive a narrative. The cultural noise fills the space surrounding the thing(s) needed to advance the story or game mechanic.

Here we contrast human needs with the needs of a game’s code. Reality vs. virtuality. The archaeology of video games is the understanding of the needs of the code to serve the narrative environment of the world. In the real world, things happen because of human necessity. Games isolate a handful of human needs in order to fill those needs of the player so that the player buys/plays the game. The game serves the game’s needs by satisfying those of the player. In the real world, the house does not have needs, but exists only because someone built it to fill a mundane function: shelter. Everything else attached to “houseness” is extra to that primary function (although the real-world narrative of houses is something more for a rainy day).

Procedurally generated landscape in Skyrim. Image Joakim Ekberg.

Creating a gaming environment/virtual world is an exercise in crafting a space as developers would like it to be. Coding is PROACTIVE. Human settlement in the real world, however, is (arguably) REACTIVE. People see the landscape and decide what to do about it in order to make the place usable, or to avoid a place in favor of settling in another place. In a game, we want a forest, so we build one in order to advance a story or to create a setting for that story. In the real world, we plant/maintain a forest for practical reasons, and only occasionally for aesthetic ones that can have practical benefits.

This cultural noise can then be seen as an intentional artifact of game design, and leaves its own material traces in the game’s archaeological record. As with anything in archaeogaming, the resulting data can be examined intra-game by archaeologists-as-players interacting with built environments following the game’s rules, and extra-game by players-as-archaeologists who recognize the cultural noise as a manifestation of algorithms created by the Maker. We are able to see the city for the cultural noise of the buildings, and the forest for the procedurally generated trees.

—Andrew Reinhard, Archaeogaming

*I recently started my archaeology PhD at the University of York, and hope to be blogging more frequently as my research progresses, using as a sketchpad for ideas that I will later flesh out and support with data and proper citations.



  1. I think you are right – SOME procedural gen does unfold in this way, however I would also argue that there is a great deal that works differently, and is actually much more in-line with how you describe the needs of the “real world”.

    For example, whilst it is true that the designer / coder could construct the code simply to “create the appearance of a place”, they can also use it to explore an explanation / make an argument about placement. I mean, procedural generation covers everything from “place trees randomly” to creating complex systems that are mathematically unserviceable to create or maintain by hand. It is a recipie. That recipie can be based on non-self-conscious design “put trees in places like x” but it can just as easily be a way to try computationally explore and simulate what makes “a good vista” or “good environment”. I guess the point I am trying to make is that not all procedural generation is neccesarily noise, just like not all things placed by hand in the real-world are inherently or neccesarily meaningful. Great example of this is Elite – during the creation of it the procedural code that manages the atmospheres conflicted with the Cambridge university calculations for refraction, by studying the maths behind the code they were able to correct the academic mathematical model based on the PG code.

    In other words: PG-Code, like real life environments, can be both deterministic and prescriptive, or reflexive. For PG-code to be that second part one needs to look at the intentions and experiences of the creator. I guess it is about reflexivity and intent. What is the code intended to explore, create or make an argument about. If the argument is “there are a lot of trees and it seemed easier to write 10 lines of code than employ a designer to place them all” then yeah, that seems like noise. But if the argument is “I want to populate a city to explore impacts on movement based on my assumptions on how cities work” then you are straying pretty far into complex simulation territory.

    Side note: There also seems to be an assumption that procedural generation is used to populate a world to progress a narrative. PG can also be used to generate a plain maze (the whole world, which has no narrative ie: completely ludological). It can also be used to just take out arbitrary jobs for level designers / artists ie: placing trees serves no particular mechanical or narrative purpose, but is a time-saving device. I guess the point here is that PG is not a 1:1 on place-creation, thats just one use. This is probably all stuff that you have thought through but yah, worth mentioning imo.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s