Last night I innocently tweeted:

Does procedural content generation inherently imply repetition or is it just a really strong connection?

— Jurie Horneman (@jurieongames) November 21, 2015

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.

Last year I wanted to do something for PROCJAM, Mike Cook's "make something that makes something" one week game jam, but circumstances conspired against me. This year, I collaborated with Liz England, and we made a horror interactive fiction game called Mainframe. It's about a spaceship and its mainframe and something is wrong and it needs help.

Making it was a great experience. I learned a lot, and I'm going to be talking about it more.

The texts, assets, and source code can be found on GitHub.

A few days ago, Julian Togelius tweeted this:

Exhibit 1A: The mindset of someone who has no interest in artificial intelligence. https://t.co/uE8BdWb4dS

— Julian Togelius (@togelius)

October 27, 2015

I replied that I have an interest in AI, and I agree with the quote. Julian didn't reply, but I was still motivated to write this small blog post. (Thanks Alex :))

I don't, in fact, know the context of the slide in question, or Julian's position. But it strongly reminded me of a problem I have encountered a number of times in my career: the conflict between game design and AI programming.

This is not a juicy conflict with battle lines between people in different disciplines. It is, in fact, an inner conflict. I have worked as a game designer, and while I cannot claim to have done any real AI programming, I have worked as a game programmer, and I've been following AI for 25 years, so allow me to pretend I have a shiny, if unused, 'AI programmer' hat here.

When I think about how to approach certain gameplay situations, as an AI programmer I go 'OK, I could use this and that and such and such a technique'. But then, as a game designer, I go 'Or I could use a trick here and do something there to make the entire problem go away'. And of course game AI programmers are very, very aware you can do this, which is why there are sessions like 'The Simplest AI Trick in the Book' during the AI summit at GDC.

Here is a fun example from Dene Carter's Gamasutra post on 'punk AI':

Did you know that villagers [in Fable 1] get into bed? I don't mean just lie on top of the beds. I mean actually fold back the sheets and get into bed. No? That's because nobody ever went into houses at night because they were locked. Oh, you could break down the door but nobody ever did, and you'd get arrested if you were spotted anyway. We actually discouraged players from seeing it. (Note: we dropped the entire behaviour set for Fable 2, along with many others such as children's school days. Nobody noticed)

So I have a kind of mental trap I fall into. If I approach the problems I occasionally chew on as a game designer, I come up with tricks to go around them, because as a working game designer, that's what you do. But that leads to coming up with the same designs as everyone else. If I approach the problems as an AI programmer, I end up wandering around with a hammer, looking for nail-like objects. Or focusing too much on the hammer. (Sorry for being vague about these 'problems' - think virtual dungeon master / narrative AI / social interactions type stuff.)

And that is what the quote on the slide made me think of, and what I wanted to briefly write about. It's not a problem that blocks me, but something that occasionally slows me down.

I've had a couple of requests for the slides of my talk on the dark side of game development which I gave last year at ENJMIN, and last week at the Northern Game Summit in Kajaani.

After some thought, I've decided not to publish them. The actual slides are very spare, often showing just a single image or a few words, so they're not very helpful. I don't have detailed presenter notes (as I found to my dismay when I started rehearsing it again about two weeks ago).

One of the images is a portrait of a personal friend, and I feel weird enough using his photo as it is. Some of those words are "stress" and "depression" and "sexism" and "homophobia".

Because I talked about sexism and mentioned some of the female friends who helped me with that section, I want to reduce the contact surface in case Internet idiots come across the slides.

This is a very personal talk, and I feel that only the actual performance - all the words I said, the way I said them, and the questions I answered afterwards - comes close to saying what I meant to say. This talk only works when I fully believe everything I say, it's not a dry technical talk at all. Writing slides with full presenter notes that say the same thing would be very hard, perhaps impossible.

And both times the talk wasn't recorded. Sorry!

If you want to get an impression of what I talked about, the resource post may be helpful.