Post on 01-Apr-2015
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…