Introduction to 3D Rendering

Download Report

Transcript Introduction to 3D Rendering

KIPA Game Engine Seminars
Day 18
Jonathan Blow
Ajou University
December 16, 2002
1
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
2
State machines
are 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!
3
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
4
The alternative to state machines
is 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 firstorder predicate logic
5
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
6
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
7
Planning became more effective
when 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
8
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
9
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
10
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
11
Creation of Path Networks
in 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
12
Auto-generation of
path 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
13
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
14
The Big Problem:
Combining high-level
pathfinding/planning with lowlevel 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.
15
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!
16
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)
17
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.
18
Scripting Languages
19
What is the goal of a
scripting language?
• In other words, why do we want to make
one?
• We don’t know exactly!
20
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
21
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
22
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)
23
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
24
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?
25
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
26
So you shouldn’t make a new
language if you don’t have to
• Use an existing system…
– Tcl?
– Lua?
– Objective CAML?
27
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
28
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
29
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?
30
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
31
Example of a scripting / data
system: Scott Bilas’ presentation
on Dungeon Siege
32
Example of a scripting / data
system: Doug Church’s
presentation on Thief
33