Presentation on theme: "Robert C. Broeckelmann Jr A Little About Me… BS Computer Science, Wash U – 2002. Fingers crossed, Masters CS, Wash U, Dec, 2007."— Presentation transcript:
Robert C. Broeckelmann Jr
A Little About Me… BS Computer Science, Wash U – 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 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 ml ml
AIPlayer Objects Flocking To Boids
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.
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.
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.
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.