Enemy AI/Trajectory Planning Integration in the Torque Game Engine

2. Enemy AI/Trajectory Planning Integration in the Torque Game Engine Robert C. Broeckelmann Jr

3. A Little About Me… • BS Computer Science, Wash U – 2002. • Fingers crossed, Masters CS, Wash U, Dec, 2007.

4. 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.

5. 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.

6. 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.

7. 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.

8. 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

9. 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.  

10. 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.

11. 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.

12. 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.

13. 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.html

14. AIPlayer Objects Flocking To Boids

15. More Flocking

16. 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). 

17. 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.

18. 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.

19. They’re coming…

20. 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.

21. 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.

22. 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.

23. Still Coming

24. 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

25. 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).

26. 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.

27. 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()

28. Split, Circle, and Attack

29. 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.

30. Still Coming…

31. 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

32. 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.

33. 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.

34. 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.

35. 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.

36. 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.

37. 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.

38. 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).

39. 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.

40. 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.

41. 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.

42. 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.

43. 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.

44. 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.

45. 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.

46. Questions??? • Thank You…