The platonic Procedural Content Generation algorithm allows you to create entire universes by pressing a button:
We're not quite there yet, because it turns out to be a tough problem, but in this article, we wanted to offer a few thoughts that might bring us one step closer.
Procedural Content Generation (PCG) -- the algorithmic creation of anything from background scenery to symphonies to storylines -- is a compelling idea, right?
Manually creating gaming worlds takes time, and storing it all takes massive gobs of space. Since the days of Starflight and Elite, developers have worked towards getting computers to the point where they can be boundlessly creative.
Broadly, developers often lean on PCG for three reasons:
It allows us to empower creators to produce content more quickly.
It allows a game to react to players in real-time in ways otherwise impossible.
It allows us to reduce the on-disk footprint of content.
We also find that there's another, hidden benefit:
It allows us to become more creative through experimentation.
In this article, we'll talk about PCG's history, problems, solutions, and methods we've discovered while using it in our 2009 title, AaaaaAAaaaAAAaaAAAAaAAAAA!!! -- A Reckless Disregard for Gravity (Aaaaa! for short) and our upcoming 1... 2... 3... KICK IT! -- Drop That Beat Like an Ugly Baby (aka Ugly Baby).
Spoiler: We favor a modular, graph-based system to benefit from the upsides of PCG while mitigating some downsides. That's it in a nutshell. You are now free to either read the rest of the article or become the leader of a pack of Alaskan Malamutes.
Successes in Games
First off, there's some evidence that PCG is actually viable/useful, despite sometimes seeming like the flying car -- forever in sight, but never (yet) practical.
Rogue! It's still a great example of procedurally generated content in games. Created around 1980, the game empowered the computer, itself, to generate a fantasy world as you played, building subterranean rooms and twisty passages and populating them with (pre-created) potions, enemies, and weapons. This style of dungeon creation is successful (Hack, Moria, Larn, Nethack, Angband, Dungeon Siege, Dungeon Siege II, Diablo, Diablo II, and Diablo III, to name just a few), and relatively well-investigated, with many developers creating roguelikes and many resources for roguelike development.
We couldn't do an article on PCG without talking about Rogue, but we're using a screenshot from Temple of Apshai Trilogy for the ST instead, just to be different.
On a galactic sale, Starflight (1986) and its sequel gave us dozens of star systems and hundreds of worlds to explore. Each system contained a number of planets, and each planet was assigned a number of characteristics (surface temperature, gravity, weather, atmosphere, hydrosphere).
What was particularly amazing for the time was that you could land your planetary module on any number of these and explore winding coastlines and mountains, populated by mineral deposits (aluminum, molybdenum, and a dozen others) and living organisms (sessile and mobile), with density and type depending on elevation and planet type. The original could all fit on a double-sided 5.25" floppy. Braben/Bell's classic Elite (1984) is, perhaps, even better known for creating eight galaxies worth of planets you could fly and trade within.
Starflight 2 even included villages you could trade with.
More recently, Sporedemonstrated procedural model generation and animation. Here, players could tweak the length and girth of a creature's bones, add limbs, eyes, ears, wings, and so forth, making creativity a part of gameplay.
Creature generation in Spore.
And .kkrieger wowed the world some years back by stuffing an entire first-person shooter into less disk space than this article.
.kkrieger, which uses only 97,280 bytes on disk.
PCG's been used throughout the history of games, and is still being used today. Surely, it should be used for everything...
Great article! I'm curious if you guys have heard of/played Vib Ribbon? A PSX game that makes PCG-based levels from your own music? Unfortunately it only came out in Japan and Europe... http://en.wikipedia.org/wiki/Vib_Ribbon
I played a ton of Vib-Ribbon at the time. My favorite thing to do with it was to burn mix CDs and then see what order the game spat out (it analyzed CDs you put in, and then played the songs in its own chosen order, which was consistent across playthroughs, in terms of what was harder or easier per its analysis.) It was very cool.
Hey! Nice article! This is my life. I've been developing procedural pipelines for film and games for 20+ years. Currently at EA, here's a bit from AIGameDev.com:
That's fantastic; thanks for sharing the links. I had no idea SSX is using PCG. And I'll have to take another look at Houdini; it seems to pop up a great deal.
PCG based on evolutionary local rules can be a lot of fun:
For example, using Massive (what we used for crowd AI in Happy Feet) to direct plant growth and build environments in Avatar - giving individual species of plants local rules in the same way you would give individual characters local rules to help them determine how to act in a crowd - “Do I eat sunlight? Is there sunlight? Grow grow grow! Oh shit...there’s another plant here...Am I aggressive? Do I eat this?” http://www.cgsociety.org/index.php/CGSFeatures/CGSFeatureSpecial/avatar
Richard Dawkins did some nifty things with Biomorphs back in the day. That was fun!
Wondering if I can apply the same concept to procedural experiences based on player state - kind of like telling a fable, the details between the major beats are always different...but so long as you hit those beats you’ll get a good story every time.
Some stories will be better than others, but it’s pretty hard NOT to tell a decent story so long as you hit those beats. Players as storytellers here - game provides the framework.
Brain noodling: Player’s experience follows a fable storytelling framework - game responds with appropriate content based on which beats the player has gone through and which beats they’re due to hit. Variables introduced via player actions/choices categorised by story archetype.
> PCG based on evolutionary local rules can be a lot of fun
> [example here]
AHA -- I've been concerned about the time it takes to construct a level, so I hadn't even considered introspective/reflective PCG that takes an iterative approach to things. Growth over time may solve the problem I'm having of intersecting pieces.
The first honest and balanced piece I've read about Procedural Content Generation for gaming applications. But why do I feel that it will be lost on a lot of programmers...
Bah, it's no fun to feel that way. Folks who are interested will dig it - folks who don't are probably interested in different things.
Programmers, artists and designers only have so much mental ram available - need to dedicate processing power to current design permutations. If procedural generation is important for the game concept you're exploring right now - follow that. If hand crafted materials is important - then don't deviate mental energy towards stuff you don't need to know how to do yet.
@Epona Except that's not how the brain works. Creativity favors variety and mental pacing.
For example, a level designer for a non-procedural game might take from this article that creating algorithms just to experiment might give them ideas they would have never before considered, while still being able to manually craft the end result.
Don't get me wrong, I think PCG has its place and that most games could benefit from some of it -- even if it is just "problem 1" generation as Bart has pointed out below. So, you can't just "ignore" it and focus on something else.
I just think, like Jacob, and from reading the feature. That specifically for levels it is of more benefit when it is a tool used to generate a framework quickly that is then modified, tailored for the game by an actual person -- they weren't promoting using PCG to generate levels as needed for immediate play by the player.
If I'm not mistaken, that was one of the points of the feature, in that PCG quite often would result in levels that were just unplayable. In order to make them playable, you would have to tweak the system (algorithm) so that the levels generated would actually become more consistent in structure and playing style.
In other words, they would all become "generic" -- the same. Which is quite boring to most people; or at least to me ;). I also think, as pointed out in the feature, that more often is the case where you could get quicker and better results if you hadn't attempted to generate the (random) content with PCG in the first place.
As the article jokes, there is no one button to press to generate a whole game with, nor is there a button to replace the designer with -- which is quite often how I feel at times when PCG is raised ;).
One of the things I ran into when I started learning about PCG is that it's really two separate (though related) problems.
Problem 1 is structuring and writing code that renders relatively short data strings as complex-looking visuals. Problem 2 is designing algorithms for semi-randomly generating data strings that will be aesthetically pleasing and support the intended gameplay.
The conceptual hurdle I had to get over was that a lot of people loosely use the term "procedural generation" (problem 1) when what they're really talking about is "random generation" (problem 2). That's understandable; in some ways figuring out how to generate good data (as this article demonstrates very well) is more interesting.
But it's still potentially confusing for someone trying to learn what this PCG stuff is all about.
I'm wondering whether 'endless' games like Temple Run, Jetpack Joyride, Cannabalt and Cordy Sky are technically procedurally generated content. They feature preset (ie. not randomly generated) sections but those are randomly connected onto the player's run in real-time and easier sections get swapped out for tougher ones as the game progresses to increase the difficulty. If they are PGC then that's a whole genre adopting the technology (or at least a simple version of it).
I think so! Games like those use a fairly simple algorithm to generate levels, but I'd still say their levels were procedurally generated. And by that argument, you could say that Robotron 2084's levels were procedurally generated, which is okay by me.
So: I'd consider PCG to be more of a continuum than a binary.
yunno really procedural content, it's an ambiguous term,
to me though it comes down to the concept of not storing like an array of data but using a function, and it's pride and wonder at using certain fascinating techniques to create predictable content from seed numbers...
elite was like this, it didn't roll the dice each time you started a new game
so actually this is why it's ambiguous, a game can't design itself, you spend ages with your random model trying to make it actually fun to play
This is an awesome article. Surprised Minecraft wasn't mentioned... lol
Have you guys heard of Substance textures? It's kinda like Genetica, but they can be modified during runtime. They're just about as procedural as textures can get as far as I know.
Printer-Friendly Version
http://aigamedev.com/open/teaser/investing-in-procedural/
I'll be giving a talk at SIGGraph on this subject this year:
http://s2012.siggraph.org/attendees/sessions/100-135
Hope to see you there!
http://freekhoekstra.blogspot.ca/2012/01/graduation-project-procedural.html
For example, using Massive (what we used for crowd AI in Happy Feet) to direct plant growth and build environments in Avatar - giving individual species of plants local rules in the same way you would give individual characters local rules to help them determine how to act in a crowd - “Do I eat sunlight? Is there sunlight? Grow grow grow! Oh shit...there’s another plant here...Am I aggressive? Do I eat this?” http://www.cgsociety.org/index.php/CGSFeatures/CGSFeatureSpecial/avatar
Richard Dawkins did some nifty things with Biomorphs back in the day. That was fun!
Wondering if I can apply the same concept to procedural experiences based on player state - kind of like telling a fable, the details between the major beats are always different...but so long as you hit those beats you’ll get a good story every time.
Some stories will be better than others, but it’s pretty hard NOT to tell a decent story so long as you hit those beats. Players as storytellers here - game provides the framework.
Brain noodling: Player’s experience follows a fable storytelling framework - game responds with appropriate content based on which beats the player has gone through and which beats they’re due to hit. Variables introduced via player actions/choices categorised by story archetype.
Hrrm.
> [example here]
AHA -- I've been concerned about the time it takes to construct a level, so I hadn't even considered introspective/reflective PCG that takes an iterative approach to things. Growth over time may solve the problem I'm having of intersecting pieces.
Thank you for sharing the link and thoughts. :)
Edit: and most others as well ;)
Programmers, artists and designers only have so much mental ram available - need to dedicate processing power to current design permutations. If procedural generation is important for the game concept you're exploring right now - follow that. If hand crafted materials is important - then don't deviate mental energy towards stuff you don't need to know how to do yet.
:)
For example, a level designer for a non-procedural game might take from this article that creating algorithms just to experiment might give them ideas they would have never before considered, while still being able to manually craft the end result.
I just think, like Jacob, and from reading the feature. That specifically for levels it is of more benefit when it is a tool used to generate a framework quickly that is then modified, tailored for the game by an actual person -- they weren't promoting using PCG to generate levels as needed for immediate play by the player.
If I'm not mistaken, that was one of the points of the feature, in that PCG quite often would result in levels that were just unplayable. In order to make them playable, you would have to tweak the system (algorithm) so that the levels generated would actually become more consistent in structure and playing style.
In other words, they would all become "generic" -- the same. Which is quite boring to most people; or at least to me ;). I also think, as pointed out in the feature, that more often is the case where you could get quicker and better results if you hadn't attempted to generate the (random) content with PCG in the first place.
As the article jokes, there is no one button to press to generate a whole game with, nor is there a button to replace the designer with -- which is quite often how I feel at times when PCG is raised ;).
Problem 1 is structuring and writing code that renders relatively short data strings as complex-looking visuals. Problem 2 is designing algorithms for semi-randomly generating data strings that will be aesthetically pleasing and support the intended gameplay.
The conceptual hurdle I had to get over was that a lot of people loosely use the term "procedural generation" (problem 1) when what they're really talking about is "random generation" (problem 2). That's understandable; in some ways figuring out how to generate good data (as this article demonstrates very well) is more interesting.
But it's still potentially confusing for someone trying to learn what this PCG stuff is all about.
So: I'd consider PCG to be more of a continuum than a binary.
Diablo 2 does the same thing.
thanks
to me though it comes down to the concept of not storing like an array of data but using a function, and it's pride and wonder at using certain fascinating techniques to create predictable content from seed numbers...
elite was like this, it didn't roll the dice each time you started a new game
so actually this is why it's ambiguous, a game can't design itself, you spend ages with your random model trying to make it actually fun to play
Have you guys heard of Substance textures? It's kinda like Genetica, but they can be modified during runtime. They're just about as procedural as textures can get as far as I know.