Robert C. Broeckelmann Jr
A Little About Me…
 BS Computer Science, Wash U – 2002.
 Fingers crossed, Masters CS, Wash U, Dec, 2007.
My Group, Fall, 2005
 Die Sphere, Die!
 Why? Most ridiculous name we could think of on
short notice.
 There were five of us.
 Good mix of talents/interest
 Ali Gardezi assisted in putting this presentation
together.
My Role: Lead Programmer
 Be honest with yourself about your strengths,
weaknesses, and goals.
 There needs to be
 A Good Developer.
 Visionary/Game Play Specialist.
 Project Manager.
 Some people in between
 One person in the group had a lot of experience with
AI algorithms, but was not a strong C++ coder.
 Most of the ideas described here started with him.
Our Game: Universal Exterminator
 Download it
http://www.rcbj.net/html/UniversalExterminator.html
 Ran the game in CEC ~2 weeks ago. The video card
driver & the older version of Torque seem to have some
problems
 Still playable.
CSE450/451
 Why are you guys in this class?
 How many people thought this was going to be a blow
off class?
 Reality: hard math, a lot of coding. Largest project I
did at Wash U (besides Masters Project).
 Exposure to game industry. Do you want to do this for
the next few decades?
 Probably the best opportunity to work in a group and
experience a "software project" during your academic
career. Mention it during your next interview.
What are we covering today?
 What I attempted to do in our game with AI.
 Developing/testing algorithm outside of Torque
 Integrating AI into Torque – how we did it.
 Controlling AIPlayer objects.
 Some advice
What I attempted to accomplish
 TAs told us that AI was hard. It is.
 Wanted to create a 3D 80’s-style Arcade game where a
deluge of enemies would provide
 a constant attack.
 hunting and perform coordinated attacks.
 Only accomplished a fraction of what we wanted to,
but it was a good learning experience.
Developing/testing AI outside of
Torque
 Difficult develop/test algorithms in game engine.
 Long compile time.
 complex
 Tracking down bugs is difficult.
 A little openGL programming experience can go a long way.
 Feel free to use the Test Bed from DSD’s code base.
 Some CS453 code.
 Other pieces stolen off the Internet.
 Can move cubes around in 3D space.
Development, testing, Integration
 Thought it would be helpful to present this in terms of
what we delivered for each demo.
 This changed a lot as the semester progressed.
 Started with the Torque Demo game.
 Flattened the landscape.
 Added one hill to hide behind.
Boids Algorithm
 We used the Boids Algorithm to produce a basic
flocking behavior in groups of enemies.
 Mimics flocking behavior of birds or swarming
behavior of flies.
 Need current velocity vector and point in space for
each Boid during each iteration of the algorithm.
 True for most trajectory planning algorithms.
Boids Algorithm (cont)
 In the next slide, notice the bugs look like they are
overlapping, they are.
 Never got the second Boids rule to work correctly
 More info on Boids
 http://www.vergenet.net/~conrad/boids/pseudocode.ht
ml
AIPlayer Objects Flocking To Boids
More Flocking
Demo 1
 It took weeks to get Boids working--frustrating
process.
 First step was to get ten AIPlayer objects to run
towards a predefined point.
 Next, I got them to run towards the Player’s current
location (only worked with one player).
Demo 1(cont)
 Then, we had to get the AIPlayers to start firing and
aim at the Player.
 Our first Demo was a group of AIPlayer objects
chasing one Player object.
 Each AIPlayer fired at the ground of the previous game
iteration’s Player position.
 AIPlayer objects fired all of the time; knew exactly where
the player was located.
Enemies need to be handicapped
not omnipotent.
 First piece of feedback: Enemies are too aggressive.
 Player object was killed with mathematical precision
very quickly.
 All of this logic was in the game scripts.
 Had to make minor tweaks to what was already there.
 Important lesson: you have got to build in a handicap
for the AIPlayer objects.
 This can come in many forms.
 Easy to build an omnipotent enemy. Much harder to
build a realistic one.
They’re coming…
Demo 2
 Introduced Boids algorithm.
 Worked well enough.
 Added ability to handle more than one flock.
 Required to make the game multiplayer.
 Second Demo had multiple enemy “Flocks" attacking
multiple players.
 Flocks went after the closest player.
 Flocks still just chased an enemy and continued to fire at
all times.
 Implemented an EnemyContainer singleton that all
game objects (we touched) could access.
Trajectory Planning Algorithms
behave a little differently in Torque
 AIPlayer's mMoveTowards value is a hint of where to
go.
 Torque doesn't guarantee it will get there.
 Our Boids algorithm made the assumption the
AIPlayer object would get there.
 Caused many headaches.
 Had to abandon one of the Boids rules to get it to work
in Torque.
 We were penalized for this.
Keeping Track Of Game Objects
 I didn't control all of the data structures that pointed
at my objects.
 Torque had its data structure for AIPlayers; I had my
own.
 Didn't dig into Torque far enough to understand its own
data structures.
 Had to add a lot of checks to determine if an object
was still valid.
 Should have done this part differently.
Still Coming
Demo 3
 Introduced our first (and only) Attack Pattern--Split,
circle, and attack.
 Flock of ants broke into two.
 Some AIPlayer objects circle at a distance.
 Others began moving towards and away from the player
firing the entire time.
 All movement was relative to the players position (this is
very important).
 Extremely complex data structures.
 Had to maintain a parent-child relationship of each
flock
Demo 3(cont)
 Pulled the decision of when to fire and when not to
fire into the game engine (C++ code).
 Added smarter target determination logic- If within N game units of player, attack.
 Continue to attack same player until someone is dead.
 Flocks traveled along predetermined paths(large
circles, circles are easy).
CPU Intensive
 Easy to see how CPU intensive our AI algorithms were.
 CEC machines were new in Whitiker--did all of our work
there.
 Found that ~300 AIPlayers was an upper limit.
 Visual C++ Debug Mode had a significant performance
penalty.
 Develop/testing with fewer AIPlayers in Debug Mode
was the most-productive, least-frustrating option.
On The Server Side
 All of the AI happened on the game server.
 Good design
 Security
 Easier to understand/maintain.
 Just need one powerful PC to run the game engine.
 Check if you are on the game server with
NetObject::isServerObject()
Split, Circle, and Attack
Coordinating Attacks
 My concept of an “Attack Pattern”.
 Only had time for one.
 Ideally, there would be dozens of different ways
AIPlayer objects could attack a player.
Still Coming…
Demo 4
 A playable level with an objective.
 AI Final Piece: more sophisticated path planning
algorithm for each Flock--beyond geometric figures.
 Introduced a terrain mapping algorithm.
 Entire game world was split into a grid
Demo 4 (cont)
 Each square had a number assigned to it based upon
the terrain height in that square.
 We generated this data from the actual terrain elevation
map that Torque uses.
 Gray Scale Map (0.0 to 1.0). Player objects cannot climb
anything greater than .5.
 Terrain Map was a very important part of defining our
level.


Had to be done first.
Had to define a couple of special cases to make it work. You'll
always have special cases.
Our Second Design
 The algorithm I just described was our second design.
 We changed what we were planning to do about one
week before Demo 3.
 Always check with the TAs before changing anything.
 You’ll learn a lot while doing this. If you come up with
a better (or more feasible idea), try it.
Design Implications
 Using the Terrain Map confined most of our potential
game worlds to hilly terrain.
 Made for one good level.
 Can the entire game be done in mountains and
canyons?
 Think through implications of your design decisions.
Five Aspects of Controlling an
AIPlayer
 Five aspects of controlling an AIPlayer:
 Point moving towards
 Speed
 Facing
 Am I Firing?
 Point Firing at
 I'm sure there are more.
 These are the ones I had time to address.
Same As A Player Object
 Really the same things that are being controlled for a
Player object.
 AIPlayer class extends Player class.
 Player object is easy. A human is telling it what to do.
Trajectory Planning Algorithm
Addresses The First Two
 Aspects
 Point moving towards
 Speed
 Focus of what we are talking about here today.
 Set mMoveTowards point.
 An algorithm such as Boids will provide coordinates &
vectors.
Attacking
 Aspects
 Am I Firing?
 Point Firing Towards.
 How do you know when & where to shoot?
 Default game implements these decisions in script. I
moved it all into C++ code.
 Allowed for better integration into AI algorithms.
 I made this really simple.
 If AIPlayer is within N game units of a Player object, start
firing.
 If firing, always face in the direction you are firing (ie, in the
direction of the Player object that is being attacked).
Attacking(cont)
 The AIPlayers will hunt down and kill you with
mathematical precision.
 Set AIPlayer target to the previous location of the
player. That way, if you run, you might survive.
 Could also have them shoot at the ground of the current
player position.
 Many other, more realistic ways to do this.
Attacking Quirks
 Quirk1 – who do I attack?
 If two Player objects are both within N game units, you create
situations where the AIPlayer objects have a decision making
disorder regarding who to attack (flip-flop constantly).
 Had to implement a sticky-attack-this-player-object
concept. AIPlayer object (in DSD case, the Flock), would
attack until AIPlayer or Player object was dead.
 Quirk 2 -- chasing
 In a situation where an AIPlayer is chasing a Player object,
there were situations(hard left/right turn) where the naive,
follow-the-player’s current position didn’t behave/look right
 This is where some trigonometry comes in handy. Able to
determine if such a turn just occurred. Need to track the
player’s current position.
Facing
 Which direction should an AIPlayer object be
facing/looking?
 More-or-less follow a simple rule:
 If attacking, Face the direction your shooting.
 If not attacking, face the point your currently moving
towards.
 This is coded into the Torque game engine AIPlayer class
by default.
It’s a State Machine
 Ants are managed by a state machine.
 The state machine logic is implemented in the Flock
class in our game.
 In our design, most of the logic was geared towards
telling the flock what to do.
 Everything was a state
 Hunting
 Different phases of the attack pattern.
 Being dead.
Tuning Trajectory Planning
algorithms
 Tuning constants is a big part of any AI/Trajectory
Planning algorithm.
 If you ever took CSE511 or CSE558.
 Vector Calculus and Trig is kind of important.
Further Advice
 I spent ~30 hours a week on cse450—balance.
 Be realistic—have to deliver something.
 It doesn’t have to look pretty right now.
 Concentrate on game play.
 Our first demo consisted of ten Orks chasing the player around a
field—we got an A.
 AI was a major piece of our game.
 May not be true for everyone.
 Source Code control is a good thing.
 Won’t appreciate it until production code is lost.
 Not everything decompiles as easily as Java.
 Test your code before you check it in to Perforce!
 If you find yourself in a semantic argument over what constitutes a
shotgun, back off and reevaluate what you are doing--it's just a video
game.
If we had more time…
 React to being fired upon.
 Ants from different hives attack one another.
 Different attack patterns—randomly choose an attack
pattern.
 Flocks work together to attack a Player—advanced
attack pattern.
Questions???
 Thank You…