One of the nice things about procedural content generation (PCG) is that it encompasses a wide collection of designers and programmers, who all use it for different purposes and at different stages of their game and its development. That’s how we get the amazing variety of approaches, applications and tools that you see in games today, and the research we’ve covered in this column. What similarities can we see? And how might that help us think differently about the systems we already use? This week on The Saturday Papers: a study of procedural generators, and an interesting means of classifying them.
We’re reading Design Metaphors for Procedural Content Generation in Games, by Rilla Khaled, Mark Nelson and Pippin Barr. In the paper, the authors present four metaphors that they observed people using to describe procedural content generators. They discuss the metaphors at length, and what light they shed on the different types of generator they denote. We’ll briskly go through the four types, and then have a talk about how thinking about these metaphors might help us apply new types of generation to our games.
PCG As A Tool
The first metaphor is possibly the most common – the Tool. In fact, the authors say they feel that PCG tool and PCG system are almost interchangeable terms, and used very generically to describe ‘things with PCG in them’. Tools are things we use specifically to achieve certain goals, by effecting change to our games in ways that we might not otherwise be able to do. A great example of PCG as a Tool would be Tanagra, a level-designing tool packed with PCG (we looked at some related research, in the form of Endless Web, in a previous column). Tanagra helps people directly interact with its procedural generator by tweaking and modifying levels output by the system, and can also help extend the abilities of the user, by analysing the resulting tweaks and seeing if they make a level unplayable. The Tool metaphor seems more common in PCG used by designers, rather than systems experienced directly by players. This is because PCG systems are typically experienced by players rather than being directly interactive. We can think of exceptions though – Endless Web, which we covered previously, allows players to use PCG systems as a tool to moderate their own experiences. Many scenario designers for PC strategy games use procedural placement of some assets, to speed up the player’s design of the level.
PCG As A Material
A less obvious metaphor for PCG is a PCG system as a Material. The Material metaphor is quite delicate. The authors put it quite nicely, saying that materials have ‘no specific form, [and] can be shaped, modified, and manipulated according to need’. In other words, unlike the PCG tools which are used in intentional, directed ways by people to achieve their goals, the PCG-as-Material metaphor describes PCG systems as possibility spaces, which a game can call upon to produce content according to various parameters and setups. The big examples given in the paper are middleware like SpeedTree, where parameters define the overall space of trees the system is likely to produce, instead of thinking about individual trees. Another example is given that’s quite interesting: the guns in Borderlands, which are procedurally generated by using variable parameters and randomised effects. The Tool metaphor says that this system is a big machine that you point at the game and it squirts out guns. The Material metaphor, however, says that the Borderlands gun generator is malleable. Poke it a bit, and run it, and a particular kind of gun comes out. Take it away, change some values, and now it produces other guns. The metaphor helps, I think, because you begin to think of each parameterisation of the gun generator as a different PCG system. This one you sculpted into the shape of an assault rifle generator. This one is an explosives generator. Another one you sculpted so precisely that it only produces one or two kinds of revolver. This is quite an interesting way of thinking about PCG systems, especially when you’re working with a content-rich game like a roguelike.
PCG As A Designer
After Tool, I think Designer might be the most familiar application for PCG, even if it is not quite as commonly employed. Designer PCG systems solve game design problems with little involvement from a human being, whether that’s at design time (like letting a PCG system propose puzzles, like the ones in the Puzzle Dice system we saw earlier) or a PCG system that produces content at runtime while respecting game design concepts, like Cloudberry Kingdom‘s procedural level designer that can test levels to verify their quality. PCG as a Designer is an appealing metaphor, especially for programmer-designers who perhaps create PCG systems to take over a task they would normally have to do. These systems are replacing the role a designer once had, and are often given heaps of knowledge from the programmer to help them produce solutions which respect the game’s mechanics and systems.
PCG As An Expert
PCG systems are sometimes referred to as experts of some kind, or used in places where human expert knowledge might normally be expected. The authors distinguish two kinds of Expert metaphors in PCG: the Player expert, and the Domain expert. The first kind is normally seen in PCG systems which adapt games to the plays. They’re experts in the sense that they know how to analyse the game and its player, and how to use this analysis to tweak and alter a game’s design. Domain experts, on the other hand, normally have expert knowledge of some very specific topic that isn’t related to games directly, but has an impact on the particular game it’s located in. Domain experts are a special case, and the authors mostly refer to this in the context of serious games (where the ‘domain expert’ system supplies the knowledge that makes the serious game relevant to its topic, like training emergency service personnel.
So What?
If you’re someone who comes here for interesting things to implement, your coding fingers are probably pretty itchy right now. How will metaphors make your games better? Well, they might not. Some of these metaphors might be obvious to you, while others might seem so specialised they could never apply. The authors put it quite nicely – this is not a taxonomy of PCG systems, here. Any PCG system can be thought of as being many of these metaphors all at once. Designer systems that express Expert knowledge. Tools that help out with Design to assist novice users. The reason I wanted to cover this paper, though, is that these metaphors are really good ways of thinking about PCG systems from new perspectives. By taking a PCG system that you only really use in one kind of context, and thinking about how it might be used in another context, you can come up with new applications or new ways of tackling PCG in your game.
Let’s say you already have a nice PCG system in your game to generate levels, and you already think of it as a sort of material. You have a Treasure Room generator, a Boss Room generator, a Maze Room generator, and so on, and you stitch them together to make levels.
What if you thought of this system as a Designer? What kinds of knowledge could you give your PCG system so it could act more independently, and stitch rooms together itself? Maybe by thinking of this system more as a co-designer with yourself, you could build a different kind of game mode, where you weren’t needed to design levels individually any more.
What if this system was a Player Expert? Could your PCG system watch the player as they pass through each room type, and use this to change the way a particular room type is presented to them in the future? If they like Treasure Rooms a lot, make the next Boss Room have a bit more treasure in, and so on. What kind of game would that turn this project into?
I really like this breakdown of ways of thinking about PCG. I think it’s helpful to look at things in a different way once in a while, and I’ll be going back to some of my small games that use PCG and thinking about how different metaphors might change the way I develop them further. I hope some of you find it useful to do the same!
Where To Find More
Rilla Khaled is an Associate Professor at the Institute of Digital Games in the University of Malta, where Pippin Barr also works now as a Visiting Designer. Both have previously worked at ITU Copenhagen, where Mark Nelson is currently an Assistant Professor.
Thanks for reading! I’m currently floating the idea of running a Procedural Generator Jam where you have a week or so to make something that generates something else. Make it super general so we can all benefit, or make it super specific so it makes your game awesome, anything and everything would be welcome. If you have suggestions, thoughts, or just want to say you’d be interested, let me know on Twitter!