1

KIPA Game Engine Seminars

Jonathan Blow

Ajou University

December 16, 2002

Day 18

2

AI in Games• Traditionally has been pathfinding and state

machines

• State machine example: Guards in a game like Thief or Metal Gear Solid

• Pathfinding example: Guards calling for support

• How to come up with the state machine to use

3

State machinesare not very good, really

• Hard to code sophisticated behavior; fluid concepts, emotions don’t state-ify very well.– Thus gameplay ends up feeling mechanical

• AIs will only do things the designers explicitly thought of – They had to put the transitions in!

4

But most AI in games is still just state machines + pathfinding

• AI programmers are generally not as good at AI as graphics programmers are at graphics– Most technical emphasis has been on graphics– Graphics is visual, so it’s easier to judge the

goodness of results

• So AI systems are generally unimpressive

5

The alternative to state machinesis some kind of planner (?)

• The simplest planners are about finding a “path” through a first-order predicate logic database

• Preconditions, effects– Example in text file

• Essentially a “theorem prover” for first-order predicate logic

6

Planning example

• Maybe you want to shoot some guy

• You need a gun, and that gun has to be loaded…– Type up quick example in a text file

7

Problems with First-Order Predicate Logic

• Combinatorial explosion– Inability of the planner to properly prune out potential

search trees• This is a very difficult problem!

• Inability to store subtle / nuanced data• Hofstatder’s paper clip example

– We know huge amounts of things about a simple paper clip, that aren’t well-represented by textual statements in a database

• Higher-order predicate logic does not help

8

Planning became more effectivewhen joined with proceduralism

• Procedures that allow the AI to look at the state of the world and make observations about it– Sounds natural in games but was uncommon in AI

when it was first done

• SHRDLU (Winograd’s planner + natural language processing system) did this and was very effective– Some looking at SHRDLU web page

9

Pathfinding

• A* algorithm is usually used– Actually because a lot of game programmers

are lame, they don’t even do something as good as A*

• Basic description of algorithm

10

A* is a graph traversal algorithm

• How do you apply it to a continuous space?

• Build a grid out of the space?– Example on whiteboard

• Difficult to extend to 3D– Ramps? Ladders? Things you could maybe jump up

and grab onto?– Again, subtleties get lost in the gridding process

11

Better than a grid…

• Create an explicit graph of path points that visit the major areas of your map– Maybe created by level-designer?

– Maybe auto-generated?

• To go to an arbitrary point on the map, find the path point closest to it (within view), navigate to that, then to the destination– Example of guard responding to help call

12

Creation of Path Networksin an editor

• Use point or line primitives in Max or Maya– Line primitives if you want to always dictate

connectivity– Point primitives may be easier, if you want ease

of mapmaking, or maybe not…

• Augment these with (invisible) planes describing where the AI should not walk– example: off the side of a bridge

13

Auto-generation ofpath networks?

• Scan the geometry of the level looking for “walkable” spaces– If you have a BSP tree maybe?

• Combine them hierarchically (because there will be far too many at start)

• Paul Tozour’s system for Deus Ex 2 / Thief 3 does this– but I think it’s a very complicated, heavyweight system

• Though to be fair, not many people manage to do even this well, so don’t take this as a big criticism

14

Auto-generation of path networks?

• Want some kind of more general system not susceptible to noise, which can work quickly

• Guided by statistical primitives• Much like the autoportalization task I

discussed on the first day– Haven’t implemented such a thing yet, but I

want to

15

The Big Problem:Combining high-level

pathfinding/planning with low-level events

• If I am just patrolling, I don’t want to walk through the corrosive sewage

• If I am chasing an enemy, I might try to jump over the sewage if I think it is safe to do so

• If the enemy is about to melt down the nuclear reactor, I am going to crawl through the corrosive sewage to stop him even if I am shot.

16

Other examples

• “I am sort of hungry”• “If the path from here to the snack bar is not

too long and inconvenient, I will get a snack, otherwise I will wait until later”– Unless I remember that later I need to go, so I

can drive home before rush hour, so I really should get that snack now

• Because otherwise I will be very hungry on the long drive home and that will be bad!

17

Example on Thief

• Circular zone around player parameterized by direction, showing appealingness of each direction

• Used to modify the fine level of the pathfind (but not necessarily the coarse level)

18

Overall Goal of AI

• is to be interesting and fun

• Not to “beat the player”– We can already beat the player easily in

shooter-type games without AI; just aim perfectly.

19

Scripting Languages

20

What is the goal of a scripting language?

• In other words, why do we want to make one?

• We don’t know exactly!

21

What is the goal of a scripting language?

• Data description language– Don’t need to write C code to make new

objects– Designers can make objects

• Get programmer out of the loop

22

What is the goal of a scripting language?

• High-Level programming language– Easier to write game logic in than C++– Maybe designers can write simple programs

with this?

• System safety– Buggy game code does not crash the game

• Again, important because of who’s writing the code

23

What is the goal of a scripting language?

• Expandability– Mod authors can write things that change the

game around– Easy to integrate new modules into the game

(just drop some files into the right place)

24

Things we are learning

• Non-programmers can’t program– Even if you give them a “high-level language”– All existing programming languages are too

low-level for a “normal person” to use

25

Things we are learning

• Maybe it’s best to integrate data description into the editor– If we’re going to have visual tools, they should

be as unified as possible, right?

26

Scripting languages introduce problems

• Bugs in parser/execution system

• Actually less expressive than languages like C++

• Absence of a debugger / profiler

• Creating a new language is a lot of work

27

So you shouldn’t make a new language if you don’t have to

• Use an existing system…– Tcl?– Lua?– Objective CAML?

28

For a good game, none of these systems will probably help

• Tcl:– Way too slow!

• Lua:– Bad garbage collector, unacceptable performance

• OCAML:– Hard to learn, hard to integrate with the rest of your engine

which is probably written in C++

• All of them: lacking some primitives and models of interaction that we want– Explicit yield, etc

29

Brian Hook’s Rant:Do we really want

a scripting language?

• He thinks in many cases programmers make scripting languages without clear ideas of their goals

• And often these goals could be accomplished more directly just with C++ and a simple data description system

30

But if we do want a language…

• It helps to realize:

• There seem to be two levels of tasks, “script writing” and “component programming”

• Explanation on white board of the difference

• Designers can definitely do “script writing”, but not “component programming”. Maybe there should be 2 different languages?

31

Charles Bloom’s point:Thread-like model, explicit yield

• Want to write AI / series-of-events like a blocking thread:

– Go to the door

– Open the door

– Step through

– Close the door

– Lock the door

– Sit down

32

Example of a scripting / data system: Scott Bilas’ presentation

on Dungeon Siege

33

Example of a scripting / data system: Doug Church’s presentation on Thief