Game of Design

This interview with Valve’s Doug Lombardi highlights Left 4 Dead’s AI Director, which I hadn’t heard of. Dynamic spawning is the first step towards the procedural storytelling I’ve been working on for the last couple of years. Finally some of this stuff is getting published.

Yes, dynamic procedural storytelling might ultimately never work. But, if you’ve played a pen and paper RPG you know it probably can. I’ve run these ideas through enough projects and models to feel it’s one of the next big story game revolutions, and these kinds of interviews get me all excited.

I know, I should write about it. Give me some time.

Warning! AI Engineering Content Ahead!

I’ve been distracted all week, but I’ve been thinking about this long enough. Chris gave, in my opinion, the best talk at GDC 2008 and I’m a bit ashamed that I haven’t seen more serious consideration from the AI community about his hypothesis (the exception being here, thanks Dave!). There’s a summary of the talk here. I think he made 3 main points:

1. There are different categories of problems, which I’ve talked about before.
2. AI should be the most useful tool we have to make games. (I actually don’t agree with this. Games are primarily competitions, and many of the games we love best have no AI at all. However, that said, I do think AI is the most useful tool we have to interact with the player. AI, however, along with user interface and mechanics, is the communication between the designer and the player, and AI has the capacity to be the most detailed and most contextual.)
3. Identifying the building blocks of AI will allow us to create artistic AIs.

This third point is the most controversial, but the most insightful and the most ambitious. Can we find a basic set of building blocks for AI? Nobody seems to know. Obviously, it’s a hard problem, because it hasn’t been solved yet. And maybe that’s because it’s just not true. But I think it’s still worth examining critically. Let’s assume it’s true, that there is such a basic set. What would such a set look like? It should model “data” in a “code” system. Given my experience, it seems logically that decision-making (picking your prioritizes at any given point in time) will be our”code”. So what could be our “data”? It would have to be adaptable to the situation, reflect the personality of the character, and allow the designer to construct a set of interactions from it. Like:

• Stats. A questioner brought this up and it was a strong point. Most RPGs use stats to drive the game. Ultima 4 famously extrapolated it out to moral virtues.
• Game state. Stats are just basically game state, and game state is the core of most games. I’m pretty confident that if stats is the right direction, it will ultimately end up using the larger game state as well. Unfortunately, this doesn’t give us a lot of direction on the “code” way to go, and makes characters look a lot more like gameplay then AI.
• Actions or Behaviors. Concrete things the AI can do are another direction we could go in. This implies a “code” language to control them, which is usually script or a complex AI, but it might work. Actions are pretty tricky to imagine as a pure data set though, because they usually involve conditional logic, and have a close history with our friend the finite state machine.
• Goals. The current meme in AI engineering might work too. It’s a bit higher level then behaviors, but they are discrete controllable things. The concern I have is that in practice goal switching and control seems to be very primitive in modern games. This might be a sign it’s the right direction though.
• Objects. The Sims, for the most well known example. Objects that describe how they are used are already understood in the data-code model and are easily extensible. In this example though, Game State is usually used to set the priorities between objects.
• Animations and Motions. On an even smaller level, almost every character is seen through it’s motions. I have a hard time conceptualizing this data as AI, because there’s so many other things that can cause motion that don’t impart an AI. A player-controlled car for example. But if you broaden your definition of an AI, then there are pretty specific designer-created rules that specify when these motions occur, so they could be a core set. Unfortunately, it doesn’t seem like it simplifies anything.
• Others? Then we get down to the crazy list. Colors in the world? Sounds? Player Inputs? What else could be out there?

Of this list, it seems like Game State is the most obvious contender, since it’s a defining building block for many of these options. But it still opens up a lot of worms. How can we have a common game state given that most games are completely different? Is it really unique on a per-game basis? Or is there some sub-set of game state, like health for example, that is part of the basic art of AI? What would a tool for reacting to game state look like? I can imagine a lot of sliders and bars, maybe tweaking and tuning on a stage, until you get something that emergently looks right. We do this in test levels for AI already, so to speak. But that seems better for something like Objects or Behaviors and Goals model then it does for Game State.

This does make it seem, as I contemplate this problem, like there’s a set of underlying data and structures that really shouldn’t influence the art of AI construction at all. You could argue the triangle has the same problem in Modeling, relying on a host of 3D mathematically concepts and definitions like “point”. But I think that is a bit inaccurate - triangles really are the basic data structure of graphics and modeling. If we want to use that model as a guide, then we really should try and follow it.

I don’t know what’s next. It’s these kinds of logical loops that I think have caused others to back away from these ideas. But it seems like a fruitful area of investigation, and if I was doing AI middleware I’d be thinking a lot about this problem. What do you think?

Elephant, meet room. Room, elephant.

Because here it is.  Based on what I just said, you could say my career in Game AI is built around a bad problem. Here’s how I see it:

1. Most of the most successful games have little to no AI
2. True AI takes years of engineering, design, and art work
3. Enemies in most games are dead within 5 seconds.   Sometimes 15 seconds.
4. … and a lot of them were scripted to do something non-AI in that period anyways.

It sure fits the description of a bad problem. But this isn’t black and white.  There are several ways that games have approached this to turn it into a good problem:

1. Many games, like Halo, have readable, memorable AI that stands out (as long as most people don’t end up only playing multiplayer)
2. Middleware and shared technology are making AIs easier to create every year.
3. You can always fake it instead.

I live in the realm of faking it.  Fake, fake, fake. And then push the designers to fake it even more.  When you’re design doesn’t really need True AIs running around and you can get work done faster another way, you can be on the beach that much faster.  Mmmm…. the beach.

Faking it here is exactly what I was referring to as coming at bad problems sideways.  Yes, as most people think of AI, AI in games is a bad problem.  That’s why we have not seen many great AI revolutions in games, despite what Chris Hecker (and I) might like.  AI is a wicked problem, but in most game designs, it’s also a bad problem. Most AIs just flat out don’t need to able to pass as a member of Facade or even The Sims. Turning it into a good problem has always been the AI engineer’s challenge, and we’ve all recognized their work in the games that have memorable characters, enemies and allies. But ultimately, the best way to turn this into a good problem for all games is through shared technology, techniques, and software.

This isn’t the topic I have been meaning to write about Chris Hecker’s talk. But it dovetails into that nicely. If the challenge is to solve this wicked problem so it becomes a good, addressable problem, then I’d like to take a few guesses at what that future would look like.

Chris Hecker coined a comparison at GDC 2008 this year, what I call Simple, Tricky, and Wicked problems.  In a similar vein I’ve coined a comparison of my own: good and bad problems.  Just as some problems are easy or hard to solve, some problems are important to solve and some aren’t.  Or rather, some problems are worth solving and some aren’t.  It was worth solving “rewinding gameplay” for Prince of Persia because it significantly improved the game.  Strict design control of hundreds of characters is a bad problem. Bad problems aren’t bad design decisions, necessarily. Rather, they are production problems that can led to more work then the problem is worth to the game.  AI Engineers run into this all the time, because a lot of AI work is concentrated on it just not looking bad.  As a team member, being able to identify where coming at a bad problem sideways or avoiding it all together is a valuable learned skill.  The more you can look at a design and identify the good problems to solve - the problems where you get a huge audience payoff vs. the problems that no one will notice the effort - the better your product will be.  I claim exponentially better.