In aim to implement our AI we have created two classes: BotManager class and Bot class. We go back to the code and see that BotManager class comes from XMLParser, so it will allow us to read an XML file. It has a bots vector, it has the onStartElement's overwritten menu. Builder and debuilder, the AddBot menu, the render, the bots initialization and the update. If we go to the CPP we have the debuilder which deletes all the dynamic elements in our BotManager class, and the methods to read XML files which is an onStartElement. Then, to do so we are going to stack up the XML file as it was set. Inside the XML folder, there is a file called actors which is telling us our actor, from Cal 3D, CoreActor, has a name called bot. We will identify it with the name bot. And the path where the Cal3D structure with the information which comes from the mesh, the skeleton and the animations are inside the folder data/models/bot. And then we have the fact our game is going to use three actors, which are bot-type. And the positions where our three actors are inside the scene. So, if we go to the code we see that what onStartElement does is, if we get the CoreActor element, it tells Cal3DActorManager to load an actor giving it the name, or the value of the name attribute and giving it the path attribute's value. So what it will do is loading all the structure in aim to build the Cal3DCoreActor. In case we get an actor, it jumps to the Pos attribute position and adds a bot of the type requested by the attribute, Core and in Pos position. Lines 60 and 61. If we go to the AddBot method it simply receives the CoreActor, the Cal3DCoreActor number we are using in the manager, and the position where it has to build or where it has to create this bot. What it does is asking Cal3DActorManager, CoreActor depending on CoreActor's name. The second parameter we give it is the path. It isn't necessary to pass CoreActor's path because, presumably this CoreActor has been previously loaded when loading the XML's CoreActor tag. If we had to pass it then it would make the code a little more complicated. The easy way would be this one. First we load CoreActors in a first phase. And then, as they are already loaded, we know we can call them without the need of the path, as they won't be loaded or built by CoreActor. So the manager gives us back the CoreActor. We create a Cal3DInstanceActor instance, which is the animated model. We initialize it in the Core, which is the Cal3DCoreActor. We build a bot which will be the artificial intelligence initializing it, giving it Cal3DInstanceActor's instance. We give it its position and we add it to the bots list we have in our BotManager. This would be the initialization part. And the other initialization part needed would be the one called InitBots, which will basically initialize the bots at a DirectX level, going through all the bots list and calling the InitD3D method where the DirectX part of each of the bots, which in this case would be each of the InstanceActors, will be initialized. After having the initialization part we will go to the update part, lines 35 to 39, where we will go through each of our level's bots and update each of them depending on the ElapsedTime. And finally we have the Render method, from lines 41 to 49, to which we give the Device. And we go through each of the bots and ask the CameraManager whether the frustrum would see a sphere containing this bot. That means, if the camera is going to see the bot we paint it. If it isn't going to see it, we don't paint it directly. In case it's going to see it, in case it says the sphere containing the bot is visible by this camera, we paint the bot. Lines 46 and 47. This would be the Manager part, inside the bots manager. Now let's go to the part of the own bot, which is where we implement the artificial intelligence In the bot class we have an enumeration where we find the different bot states. Line 13. We have the no-state state, which in our arm would be the idle state. The states Patrol, Approaching, Shooting, Dead and Hit. Then we have the properties m_yaw, m_pitch, position, PreviousPosition, state, InstanceActor, BotRadius, Bot's life, the Time Shot which is the time shooting takes, the chat controller from the Physics controller to be able to move our character depending on physics, the bot's vertical speed, and the CurrentWaypoint to which we are going in case we are patrolling. Yaw and pitch are the orientation. Yaw would be, as we said in the first session, the angle where we move our head from the left to the right. And the Pitch would be if we were moving our head vertically, looking downward or upward. Then we have UpdateVerticalSpeed method, which will update the bot's vertical speed depending on the fall's physics. The SeesPlayer method, which gives us back true or false depending on if the bot sees the player or not. To do so, we will use a Raycast, a ray from the bot head's position to the cranium's position. Then we have another method which updates the vertical speed depending on the collision flags it gives us back when moving the controller's chat, and the Respawn method which will restart the bot, which would be the Respawn state we had previously done in the graph. So, public methods. We have the builder-debuilder, the initialization part, update. These would be the classic ones. Render, as well. Then we have ResetPosition which sets back again the last valid position of the bot in DirectX's initialization, which will basically initiate InstanceActor. SetPosition establishes the bot's position. GetPosition gives back the bot's position. GetCollisionPosition gives us back the bot's collision position. We can use this to define some positions where it will hit the bot. Adding life, which will be both for adding HP and to take it away. If the amount is negative it will take life away, if it is positive it gives it life. The yaws' get and set. And the pitch's get and set. And finally the GetRadious which gives us back the radius of the bot's containing sphere. Let's go on with the bot.cpp class. We have different macros or fixed values we define here such as speed, shooting range, approaching range, bot's scale. Our scene is scaled regarding the original size, and we have to rescale the bot as well. The legs' height, the legs' radius, the chest's height, the chest's radius, the head's height and the head's radius. It's not the same, but we can use it to have different reference points to shoot at. So, depending on where we shoot the enemy we can take more or less HP away from him. The initial HP in this case is 100. And then animation IDs. We have walking, hitting, shooting and death. We have the builder where we build the member variables and we create the physics controller, a character control. To do so we use a CreateCharacterControl from the Physics class, to which we give the height, the radius, the step this offset can climb, and the maximum gradient angle the character can climb. Then the character. And finally the group where this character controller belongs, which in this case is a bot. And then we tell the controller that this controller's Actor, in which we are the user_data. That's the 'this'. Line 47. Then comes the debuilder which deletes the memory from the dynamic part. The initial_life method simply receives the Instance as a parameter. And we assign the instance to the InstanceActor. This could be done in the builder but we have decided to do it this way. The Life method adds HP to the bot's HP. But in case the amount is less than 0 it means we have been hit. So we check whether the life is bigger than 0 and the HP result is bigger than 0, then we change to this hit state. And we execute the action-type animation hit_animation. This comes from lines 86, 69 and 70. In case we have been shot and we have run out of HP we change to death state, line 74. And we execute the action-type animation, which has 3 as its index, which in this case should be the dead animation We aren't going to use lines 78 and 79 here, we will use them in the next session, as they are about the audio files. And then we have yaw's get and set effects, which give back or set yaw's position. Then pitch methods, SetPitch and GetPich which, again, establish where I'm moving pitch's position. The SetPosition, which sets the current position to m_position, and the PrevPosition which sets the previous frame's position. And it also sets in the physics controller the position we give it as parameter. GetPosition method gives us back the position. And the Render method creates our bot's transformation material, our animated model. It first creates a scale matrix, a movement one and then the rotation one and we multiply them. In the following order: scale multiplied by rotation multiplied by translation. This gives us a GetUp variable, and it transplants it to give it to the shader. Then it is established as EffectManager's parameters world matrix. And finally, it calls InstanceActor's Render method. Lines 115 to 125.
