The conflict between game design and AI programming

A few days ago, Julian Togelius tweeted this:

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.