Chris Hecker on AI at GDC 2008

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?

4 thoughts on “Chris Hecker on AI at GDC 2008

  1. This was, indeed, and interesting lecture from Chris. However, I object (mildly) to your statement that it hasn’t been considered since by the AI community. Please check out my column on the subject and the ensuing discussion.

    I do like some of your other suggestions, though!

  2. I did see your post a couple of weeks ago but missed the lively discussion. It’s largely the only post I did see (which is why I qualified the statement), but I was remiss and probably should have linked you regardless. Fixed. Thanks for pointing it out!
    As I’ve discussed this with engineers over the past few months, I’ve found it easy to get caught up in all the complexity nuance, like pathfinding and perception, which has much to do with the day to day but it’s not clear is critical here. I kept having to come back to the simplest AI cases I could think of – like a block moving in a pattern, and then a block moving in a slightly random pattern, and then a block moving in different patterns based on game state like health, etc. – to get back to the “code”/”data” core at the center of Chris’ argument. I like your comments on Atoms and Tasks quite a bit, which combines Action and Movement in the above list, I think. Inputs and outputs reminds me of academic AI and “insect AI” language representations, which might be spot on too.

  3. Pingback: Game AI Roundup Week #18 2008: 10 Stories, 1 Video, 3 Jobs, 3 Quotes — AiGameDev.com

  4. Pingback: AI IDE 2008: Day 2 « Game of Design

Leave a comment