KIPA Game Engine Seminars

1. KIPA Game Engine Seminars Day 18 Jonathan Blow Ajou University December 16, 2002

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