Skip to main content

Repetition and procedural content generation

Last night I innocently tweeted:

And then I watched a movie (Pi! still great) and 90 minutes later I checked Twitter and suddenly I had 50 replies.

My tweet was a bit gnomic and lacked context, as tweets often do. I wasn't talking about repetitiveness: I was talking about how PCG is used by game designers, beyond "hey look we can create a billion dungeons / planets". Not that there's anything wrong with that, but I am interested in using it in other ways.

In Mainframe, the IF game Liz England and I made for Procjam, one of my basic tenets was that we should design the game around repetition, because we were using procedural content generation (PCG). When you play it, you will quickly find the element of the game that repeats. Whether it feels repetitive is a different question, although we don't claim it is not.

This tenet was something I intuitively picked as a design heuristic, but afterwards I started wondering how core it actually is. Is it essence or accident?

I had a lot of fascinating discussions about this last night, and I've thought about it some more, and I now think that using PCG as a game designer will always involve repetition in some way. (Again, I am not talking about repetitiveness. This is not about procedural content generation being "bad".)

My reasoning is that when you make a procedural content generator, you will always want to call it more than once. (See below for a few very rare exceptions.) Because otherwise, what's the point? PCG is more effort than manually authored content, for one single instance of "content".

This is not the case with manually authored content. While we make a lot of repeating content by hand, we also make a lot of unique assets and set pieces.

So my argument is based on the purpose of PCG, and the trade-off between using PCG or manual authoring. This means that if your interest is in PCG for its own sake, you may not be impressed. And that's fine! I am looking at it as a game designer: I want to provide a certain experience, and I want to figure out how to do so effectively. (I am also looking at it as a programmer who finds it fascinating to work on PCG.)

If you call a procedural content generator more than once, there will be repetition, because the generator exists to generate a certain kind of content, and calling it more than once will create more than one instance of this kind of content, ergo repetition, QED.

To put it more plainly, if you have a tree generator, and you generate a bunch of trees because your game needs a forest, you end up with a bunch of trees, no matter how different and unique those trees are. That may sound painfully obvious, but think of it another way. Let's say we could have a chase scene generator. It takes the current situation and generates a chase. That only makes sense in a game where you get a lot of chases.

This is what happened with Mainframe. We knew we wanted to use PCG (because otherwise why make something for Procjam?), so we needed to come up with a design that incorporated repetition. And we did so by picking a base-mission structure. You're in a base, you go on a mission, you return to the base. This is a very versatile pattern that fits both games and stories very well, which is why I'm a fan of it. Many TV series use a base-mission structure. And this hopefully shows why I don't think repetition is bad per se. It is not, it creates rhythm and structure. Repetitiveness is something else. And of course the challenge for game designers is to avoid repetitiveness when using repetition. This is a core challenge whether we use PCG or not!

Liz applied a gameplay loop to Mainframe, a common game design approach. I would argue that IF doesn't necessarily always have a gameplay loop, but it fits well with the repeating pattern, and it was very useful.

(Regarding chase scenes: notice how some games that involve cars sometimes have a chase mode, where they change some rules and behaviors? That's kind of a chase scene generator! Whether that is PCG is a different, albeit equally fascinating discussion.)

Let's talk about a couple of possible counter-arguments to my thesis that PCG implies repetition.

  • What if you generate the entire game, a la ANGELINA or Game-o-matic? I think this falls outside the premise of my argument. I am thinking of this as a game designer who wants to provide a certain experience, and wants to do so effectively. While it is possible to imagine a game creating system that would create the game with me on a very high level where I don't have to think about repetition, I think that is also the point where I am no longer a game designer in the sense I am now.
  • What if you generate the entire content for the game, like Dwarf Fortress? Again, looking at it like a game designer, if I'm going to build something like that, it just means piling generators on top of generators, and each generator implies repetition.
  • What about the generate-and-test approach many procedural content generators use, where content is generated by a piece of code, and either the user or a second piece of code, or both, evaluate it and reject or adapt it? Is that repetition? For the purposes of this discussion I consider that an internal detail of the procedural content generator. Mainframe, for what it's worth, does not use a generate-and-test approach.

There are only two exceptions I can see:

  1. You make a game that requires only one tree (say), and you generate that tree. A sensible use of PCG, and there's no repetition.
  2. You build a game that uses PCG without repetition because it's a constraint you set yourself, for conceptual or other artistic reasons. You can always break a rule on purpose. Jason Rohrer wrote an abstract board game generator, ran it only once (for all intents and purposes), fabricated the resulting game, and hid it in a location unknown even to him. Obviously this was a conceptual stunt. But, yes, PCG without repetition.

A final point about what I said in the beginning: the "hey look we can create a billion dungeons / planets" approach is putting PCG front and center, creating an experience around it. And, like I said, it makes sense, it is effective, there's nothing wrong with it. But I am interested in exploring how we can use PCG in different ways. That may lead me away from what people think of as PCG (that was already a goal I had for Mainframe). But it's a fascinating journey.

Anyway, those are my thoughts. I hope they will trigger as many interesting discussions as my original tweet did.