—

This is actually a really interesting question and answering it brings up a lot of nuances. Starting with the fact that, as you point out (though I don’t want anyone to feel like I’m slagging off on them) failures can often be more instructive than successes.

Then, too, the context matters. I don’t think that there are any inherently bad techniques, simply because I’ve seen so many off-the-wall unusual inputs used to good effect that I think it’s quite possible to find an effective use for something that no one else has spotted before.

As a further consideration, something I feel that gets frequently overlooked in the popular discussion of games is that different games need different things. Just as there’s no one purpose for art, there’s no one purpose for procedural generation. Simcity 2000 and katierosepipkin’s no people both generate text, but they’re using it for very different effects. Proteus and Dungeon Crawl have different goals; what works in one might not work for the other. 

For that matter, Dungeon Crawl and Crypt of the Necrodancer are both dungeon crawls, but Dungeon Crawl has large dungeon levels and an autoexplore feature, while Necrodancer has tightly constrained dungeons where every step counts. They both have perfectly sized dungeons for the game that they’re in.

There are also different aesthetic goals. Just as some games deliberately curtail the player’s agency to produce an effect of fatalism or determinism, procedural generation can strive to produce results that feel familiar and realistically mundane, or it can be deliberately pushed to produce something that feels alien.

What works for one project may not work for another. One of my friends has a saying: “You are not Tarn Adams”. Dwarf Fortress thrives on the obsessive attention to minute details. It wouldn’t be Dwarf Fortress without it. But Tarn Adams has been working on Dwarf Fortress as a full-time job for nearly a decade at this point. While I’d love to make something with the same intricate detail (and a better interface) it’s not something that most projects need. Even in the base-simulation-genre that Dwarf Fortress revitalized, most games are better off finding their own simplification, rather than trying to copy the excesses of Dwarf Fortress.

When it comes to failures of procedural generation itself, there are two broad categories that I’ve noticed so far. The first is what we might call conceptual failures: the flip side of the order/chaos balance I’ve discussed quite a lot, Michael Cook’s “more unpredictable stuff” critique, Darius Kazemi’s call for context, and so on.

The early Elder Scrolls games are a good example here. While there’s something to be said for the sheer indifference of Arena and Daggerfall’s massive worlds, the bulk of the things you’ll encounter in the game are mostly interchangeable. Random town #3 looks a lot like random town #4. Even if the buildings and names are shuffled around, they’re too big and too anonymous to do much more than confuse the player.

Part of this is down to the tech and design limitations of the time: while you can take the basic concepts here are design a tight procedurally generated open-world dungeon crawler, no one had ever done it before. In an era of experimentation, when CRPGs were still reacting to the design lessons of Dungeon Master, Arena’s open-world procedural generation is simultaneously revolutionary and haphazard. 

The towns, for example, have very little order, being more a random jumble of buildings. If you compare them with a map of an actual medieval city, you can see that while the real thing has a level of organic chaos, it also has decipherable patterns and enough unique features to be navigable. Real-world chaotic patterns have clumps and irregularities that derive from their history.

I touched on this a bit when I talked about Arena specifically. The games are just too big for what the generator is able to accomplish. Generating large-scale structures that make sense requires more than just scaling up. Which is why the platform that NaNoGenMo gives for novel generators has had a significant impact on the state of story generation over the past few years: working at novel length has driven experimentation with new long-form techniques. 

If you’re not Tarn Adams but you want to generate something that’s along the same lines as Arena while avoiding their mistakes, you might consider making something that generates a small but self-contained world rather than a vast, sprawling one. The original Elite, as you’ll recall, was capable of generating two hundred trillion galaxies but deliberately shipped with only eight. 

I suspect the developers themselves recognized this, because they stripped out the procedural generation completely in Morrowind and then gradually added it back in…but that’s another story.

Even these rules aren’t ironclad guidelines. For example, while generators that are too big and too infinite are generally less interesting, the whole point of simulations of Borges’s Library of Babel is that their infinite complexity is too big for the human mind to comprehend as we browse through the mind-numbing noise that frustrates our desperate search for meaning.

The second class of failures are more technical. For example, it was pointed out to me on Twitter that the articles in SimCity 2000 are regenerated if you close and reopen the article. This obviously hurts the verisimilitude. While they probably never fixed it because it’s a relatively minor part of the game, this is a good example of a solvable error. You could either store the random seed used to create the newspaper or have the entire process be deterministically random. Simcity isn’t the first game to have this issue, nor is it the last: Elite Dangerous does the same thing with some of the minor local news articles. It’s also a good example of the importance of understanding the random number generation that you use.

That’s one reason I try not to use the term “random generation,” by the way. It tends to give people the impression of an entirely chaotic process. A single Perlin noise texture map or a jumble of building parts are poor examples of what procedural generation is capable of accomplishing. I’ve seen some confusion out there on the internet that procedural generation is just about dungeon maps, or terrain height maps, or Perlin noise planets. The randomness is only one aspect of procedural generation. Albeit an important one.

I haven’t highlighted too many technical errors, partially because only some of them are illuminating, and partially because they often require a deep dive into the minutia of a generator. At some point I’d like to do some writeups of the source code for some generators and point out exactly what they’re doing, step-by-step. 

The last bit, summing up your question, of how not to use procedural generation could probably use a whole tag series itself, to go along with the when not to use procedural generation posts. There’s quite a few games and projects I haven’t mentioned here because they don’t use procedural generation and I think they’re all the better for it. Kentucky Route Zero, Infinifactory, The Stanley Parable, and Undertale don’t have much in the way of procedural generation, and don’t need it. I could write volumes about their approaches to interactive narratives (and might do that in an organized fashion someday, since that’s another one of my passions) but I deliberately haven’t talked about them here.

How not to use procedural generation combines that with the first failures, the conceptual problems (and occasionally the technical problems). Failed procedural generation is generally either broken, boring, confusing, or jarring. Broken is when it fails in a way that makes the game unplayable, or breaks another part of the game. Boring is when the generation is too predictable or too samey. Jarring is when the generation is technically fine, but aesthetically doesn’t fit, as exemplified by the worst sorts of random combinations. Confusing is when boring gets combined with broken or jarring, as in some of the early Elder Scrolls dungeons. Mazes are frequently more fun to design than they are to solve. 

As a rule of thumb, anything where the procedural generation is having more fun than the player is probably a place where you shouldn’t be using procedural generation.

It’s good to look at what other people are doing. That’s one of the reasons I’ve been writing this blog, to keep up with all of the procedural generation projects that are happening. Ideas are something you need to grow and cultivate, not wait until a creative mood strikes. (Though don’t forget you can also get inspiration from elsewhere: at the very least you may get an idea for new unusual inputs to use.)

That certainly includes what other people are saying about procedural generation. Like this article from Gamasutra, which discusses what developers can learn from studying other games. The article talks about several games, some of which I’ve covered here and a couple that I haven’t yet. 

Some of the ideas are things I’ve talked about here before, like how procedural generation can push players to understand games on a systemic level rather than just memorization, or how emergent effects can combine to produce a greater whole. There’s a particularly good point about how exposing numbers or connecting the effects to the player’s actions can give the player a greater emotional investment in the result.

http://www.gamasutra.com/view/news/262869/7_uses_of_procedural_generation_that_all_developers_should_study.php

Fractal Forest (Procjam 2015)

Another ProcJam project from 2015′s jam. While the voronoi textures are eye-catching, the real purpose behind this one seems to be generating the node-based path movement graph.

The pathing doesn’t always respect the terrain height, but the aesthetic effect is rather striking. Though the textures aren’t generated at run time, the overall feel suggests an opportunity to make something that’s consciously and obviously entirely generative. Layering some additional levels of generators might break up the homogeneity and start to flower into something unique. Still, for a jam project: definitely eye-catching.

http://cry-havoc.itch.io/fractal-forest

Mansion Maniac (NYPL Labs)

Now you can explore procedurally generated historical apartment buildings! When you walk through a doorway, the generator adds a room from a collect of annotated rooms from real early 20th century New York City buildings.

Built by Mauricio Giraldo for the New York Public Library Labs using the library’s extensive collection of public domain resources, in this case blueprints of apartment buildings. The source code is on github for your perusal.

Since the rooms are all from historical blueprints, jumbling them together makes the already intertwined New York City resemble Çatalhöyük, a BLDGBLOG-worthy union of the earliest and latest metropolises.

There’s quite a bit here that we can unpack. First, it’s a prime example of using unusual inputs to add order to a generator. The rooms generated by this are already more interesting than generic dungeon corner piece #7. Even filtered through the chopped-up blueprints, they retain some of their original history, giving them an unseen but felt depth. There’s lots of public domain resources out there that can be used for similar effect in your own projects.

Second, by using historical data we can get a feel for what these rooms were like. While the generated floorplans are ahistorically chaotic and random, the experience of walking through them (and reading the labels) gives us a tiny glimpse of context for the original setting they were in. The interactivity also makes us more likely to engage with them: it’s a rare person who has the time to peruse musty tomes of blueprints, so this presentation makes them much more accessible. As a bonus, the source data is linked, so if this sparks your interest you can go and hunt down the originals. This is a great example of one way that procedural generation can be used to explore real-world subjects, by looking at them as systems rather than as lines on a page.

Finally, the source code for the project is available. It might be interesting to see what would happen if you take the generator a step further. Can you design an algorithm that creates a plausible floorplan, one with more order? Or one that uses rooms from a different source, such as archeological floorplans from Minoan palaces? Or perhaps you can take these rooms and transport them to a different context: what about exploring a fantasy dungeon whose rooms are secretly based on New York City apartments? Or maybe you’ll find a way to add another layer to the generator, and use the output for music, or painting, or dancing robots.

Speedruns and Procedural Generation

A speedrun is playing a game with the intent to finish it as fast as possible. This takes a very deep knowledge of a game, often breaking the intended sequence of events or going outside the level geometry. Speedrunning has been popular since the days of Doom, and these days there’s a twice annual charity events, Games Done Quick.

Spelunky, despite (or because of) its procedural generation making simple memorization less useful as a speedrunning technique, has a fairly active speedrunning community.

Studying speedruns can teach you a lot about a game’s design. Speedrunning is frequently about understanding a game on a very deep level, and procedural generation is no different. Many speedruns involve taking specific actions to get the random number generator to an ideal state. Speedrunning a roguelike like Spelunky or Crypt of the Necrodancer requires the speedrunner to take it several layers deeper, uncovering the hidden patterns behind the generator and manipulating the game’s systems to find the fastest result. 

Spelunky Speedrun

Awesome Games Done Quick is a twice-annual speedrunning event. Starting right now, they’re streaming a speedrun of Spelunky. Speedrunning a procedural generation game is a fascinating additional twist to the usual challenges of speedrunning.

Polygonal Planet Project

Oskar Stålberg has another relevant project online, this time an entire planet. It’s labeled as an exercise in tilesets. A close examination will reveal some of the nuances: try putting a city on snow, or using the cliffs to make a canyon in the city and see what happens.

Designing a set of components that fit together well is one of the basic artistic tasks that shapes procedural generation. The basic principles of 2D NES-era tilesets are fairly well known, but tileset design didn’t stop there. There have been quite a few games that have pushed beyond that, including Civilization 3′s hill-and-border system. The introduction of 3D tilesets opens up even more possibilities.

On a more general note, building kits of modular content is a design discipline in itself. Building kits that work with procedural generation is an additional complication, but a necessary one: while the popular image of procedural content is often one that is generating geometry from scratch, entirely in code, the real-world applications are much more likely to use at least some prefabbed components. 

The principles behind modular kits also applies to non-visual content. Prefabbed chunks of content are frequently useful in text generation, and I often use a deck of cards metaphor in systems that need varying output that still needs to fit within constraints. 

http://oskarstalberg.com/game/planet/planet.html

Repl Electric - End of buffer

Let’s start the new year the right way, with a livecoding performance!

https://vimeo.com/117516352

Designing a Procedurally Generated Game - Dwarf Fortress, Darkest Dungeon, etc

Here’s a talk by a bunch of game developers who use procedural generation in their games. I’ve posted about some of their games before: Dwarf Fortress (Tarn Adams), Crypt of the Necrodancer (Ryan Clark), but they all have interesting things to say.

(via https://www.youtube.com/watch?v=S9pc8li4fuQ)

Procedural Generation and Shared Content

There’s a symbiotic relationship between content that’s procedurally created by the computer and user-created content. The most obvious connection is that they both need similar frameworks, with many possible options. But the relationship goes deeper than that.

Roguelikes have a long history of bones files. When a character dies in NetHack or Dungeon Crawl, that’s not the last you’ll hear of them. Their data is saved, allowing them to appear in future games as a ghost. In NetHack the entire dungeon level is saved, so you can even steal the original character’s (now cursed) equipment, or die to the same monster who killed them.

Where this really gets interesting is when you play on a multiplayer server, and can encounter the ghosts of other players. In addition to the usual content creation, the procedural generation system is capable of taking the content the players created in the course of the game and using it to extend its own generation. 

You can take this principle quite a ways. Nethack goes so far as to incorporate the user’s email account into the game: on a properly configured server, if you get an email while you’re playing, a mail daemon will pop into the level and hand you your email written on an in-game scroll. But you don’t have to go that far to recognize that players can be incorporated as part of the procedural generation system. Having the player act as a critic can help bridge a difficult gap in content generation. If you take it a step further and crowdsource the filtering, it opens up a host of machine learning techniques.

Eventually, you may be able to combine machine learning and crowdsourcing to emulate the human-improvisation development process of The Snowfield.

Designing games that share user content is something that Craig Perko has talked about quite a bit. I think he’s on to something with his ideas of developing a language for these interactions and to be able to look beyond the binary of survival challenge mode and creative editor mode. 

A procedural generation that can take player creations or player feedback and incorporate it into the next iteration, like Galactic Arms Race and Warning Forever do on a small scale is a potentially powerful way to structure a meta-generator. It’s not an approach that has been tried often, mostly because it has large up-front costs. 

The idea of sharing other players’ content was, of course, one of the big deals when Spore was in development. Still is, really, since Sporepedia currently lists 188 million player-created creatures. (I have my opinions as to why Spore didn’t become the phenomenon the developers were hoping it would be, but I don’t think the shared user creations was one of them.) 

I’ve often thought that this is one area where Minecraft hasn’t closed the obvious circle. It’s a game all about exploring procedurally generated content and shaping it with the user’s creations, but the arrow only goes in one direction. If there was a way to incorporate user creations back into the generator, so that new worlds could be populated with the ruins and artefacts of other players’ creation, the feedback loop could be sustained within the game itself.