Robert C. Broeckelmann Jr A Little About Me… BS Computer Science, Wash U – 2002. Fingers crossed, Masters CS, Wash U, Dec, 2007.

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, 2005Die Sphere, Die!Why?  Most ridiculous name we could think

of on short notice.There were five of us.Good mix of talents/interestAli Gardezi assisted in putting this

presentation together.

My Role: Lead ProgrammerBe 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 ExterminatorDownload 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 problemsStill playable.

CSE450/451Why 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

TorqueIntegrating AI into Torque – how we did it.Controlling AIPlayer objects.Some advice

What I attempted to accomplishTAs 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 TorqueDifficult develop/test algorithms in game engine.

Long compile time.complexTracking 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, IntegrationThought 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 AlgorithmWe 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

correctlyMore info on Boids

http://www.vergenet.net/~conrad/boids/pseudocode.html

AIPlayer Objects Flocking To Boids

More Flocking

Demo 1It 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 2Introduced 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 TorqueAIPlayer'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 ObjectsI 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 3Introduced 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 IntensiveEasy 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 SideAll of the AI happened on the game server.

Good designSecurityEasier 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 AttacksMy 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 4A 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 DesignThe 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 ImplicationsUsing 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 AIPlayerFive aspects of controlling an AIPlayer:

Point moving towardsSpeedFacingAm I Firing?Point Firing atI'm sure there are more.

These are the ones I had time to address.

Same As A Player ObjectReally 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 TwoAspects

Point moving towardsSpeed

Focus of what we are talking about here today.Set mMoveTowards point.

An algorithm such as Boids will provide coordinates & vectors.

AttackingAspects

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 QuirksQuirk1 – 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 -- chasingIn 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.

FacingWhich 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 MachineAnts 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

HuntingDifferent phases of the attack pattern.Being dead.

Tuning Trajectory Planning algorithmsTuning 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…