1. TEMPLATE DESIGN © 2008 www.PosterPresentations.com Last Resort AI, Animation, Modeling, and Networking Alex Bunch, Nick Hunter, Austin Lohr, Robert Schmidt, Eric Shryock, Ian Stitzlein The Ohio State University Computer Science and Engineering Networking AI Cont. Animation Animation Cont.Modeling AI Fog of War When the local player submits a command, the command is sent to the Network Manager, which delegates the sending and receiving of RPCs to the Network Messenger. The Network Messenger sends RPCs from the Network Manager out to other players and notifies the Network Manager when new commands arrive from the network. The Network Manager then gives new commands from the network to the Command List. Although the game is “real-time,” time is actually split into 200 millisecond “turns” during which player commands are recorded but not executed. The commands for a particular “turn” are sent across the network, and commands for that turn are not executed on a local computer until the commands for all other players for the same turn have been received. This "turn" concept is encapsulated in the Command List object. The Network Manager keeps track of the current turn and labels any outgoing player commands with that turn number. When the Network Manager receives a new player command from the network, the Network Manager sends the player command to its Command List object to be organized by “turn” and player. The Network Manager frequently queries its Command List for completed turns and asks the Command List to executed those turns when ready. This process of recording, sending, receiving, and executing turns is continued until one player is declared the winner of the game. The unit models of Last Resort have gone through a few iterations during the course of our development, mostly stemming from the fact that in order for our game to run smoothly units should consist of as few polygons as possible. Initially all of our models were either taken from free sources or purchased for a nominal fee, but soon after we realized that all of these models were too detailed to be used in masse in our game. Polygon reduction tools exist in most commercial software, and since we were already using Maya and 3ds Max we gave each of them a shot. Maya – Performed ‘dumb’ reductions, often creating spikes in the surface or reducing incorrectly. 3ds Max – Had a few options, ‘Pro Optimizer’ successfully reduced polygon counts to approximately a quarter of their old values while retaining the shape of the model (50,000 Polygons) Once we got further along the development process we realized that most RTS games limit themselves to <5000 polygons in order to accommodate hundreds of units potentially being on the screen at the same time. To reduce our models further we used a tool called 3D Coat to put reference points on our model and freehand a convex hull around it that still looked like our original models from a distance. Using this technique we were able to further reduce our models to around 5000 polygons. Figure 2 shows our progress reducing our polygon counts for a single model. Figure 2: Lowering Marine Polygon Counts (a) Initial Model (500,000) (b) 3ds Max (120,000) (c) 3D Coat (4200) The first step of the animation process is to take the models created and attach them to a skeleton so they exhibit lifelike motion, this process is known as rigging. During this process extra joints are added in areas that experience more bending in order to reduce deformation. In addition, constraints are added on most joints to ensure they bend the correct way and inverse kinematics can be used to made animating easier. All of the rigging was done in Maya and Figure 3 shows the end result of rigging a model. Even though there is no computer player, AI was still a significant portion of our project. One thing that we did differently than most mainstream Real Time Strategy games is that individual units are not build. Instead, you build squads consisting of one to six units. Players cannot directly interact with the units, and instead interact with the squads. Figure 5: AI Hierarchy All major AI decisions are made on the squad level, and then the squad decides how to implement those orders. It then passes on to the unit level a set of sub orders that will best implement the squad order. A MVC design pattern in combination with a Behavior Tree are what the squad uses to make decisions. Figure 6: Model View Controller Design Pattern Figure 7: AI Behavior Tree For path finding, a waypoint grid was overlaid on top of the map, with some waypoints being marked as impassable. An A* path finding algorithm was then used to find the best path, which was then smoothed using a curved non-uniform algorithm to create more realistic movement paths. Figure 8: AI Path Finding After rigging the model the next step before putting it in the game is animating it. Inverse kinematics make this process relatively painless, because it allows an animator to simply place then end of an extremity where he or she wants it and all the bones higher in the hierarchy will move naturally to allow for this position. Figure 4 demonstrates using inverse kinematics to have an elbow bend when a hand is positioned. Lastly, animations today can be created quickly by having the animators set ‘key’ frames they want in their animations and letting the program they are using interpolate the position of their model between each key frame. The challenge with networking in any Real-Time strategy game like Last Resort is that there are potentially hundreds of objects on the screen at once. Perfect synchronization would require sending all of the state information (position, animation state, health, attack damage, range of sight, etc.) for each and every unit across the network. A better solution, however, is to send less information across the network, which can be achieved in several ways. Last Resort uses two optimization methods. First, non-critical information is left unsynchronized, and second, calculated information (movement paths, etc.) is left unsynchronized. The only information sent across the network is the players' commands (Build, Mine, Move, Attack, etc.). All other information (animations, sounds, paths, damage) is decided on the local machine. Last Resort uses Remote Procedure Calls (RPC), which are essentially network messages that invoke a function on a remote computer with given parameters, to send these player commands across the network. The networking functionality in Last Resort is built around the three components pictured below: Network Manager, Network Messenger, and Command List Figure 1: Diagram of Network Manager Interactions Figure 3 : Rig for a Human Model Figure 4: Inverse Kinematics of an Arm Rig Fog of war was implemented using a semitransparent mesh and ray casts. Each unit, during the update cycle, shoots a ray into the mesh to find the triangle that was hit in the mesh. Once the triangle has been located we then find the surrounding triangles and we change their alpha to transparent, creating the “fog” effect. To hide the enemy units from displaying on the screen, when they are in the “fog”, we check during the update cycle if the triangle that they are above is one of the visible triangles to the friendly units. If the triangle is visible then we render the unit. If the triangle is not visible, then we do not render the unit. Figure 9: Fog of War in Debug Mode