Update method implements our whole graph. So I'm going to leave it for the end to then face only SetupUpdate. The GetRadius method gives us back the radius we have in our Bot. The GetCollisionPosition gives us back the collision position, which is a position we have inside the bot, we have said that we aren't using this but we can use it. ResetPosition establishes the current position to the PrevPosition. And InitD3D initializes DirectX's extractor part. So, the InstanceActor is working to load its textures and create the Subvertex Buffer and IndexBuffer. The SeesPlayer method, as we said before, checks if the bot is seeing the Player. To do so, it creates a ray and tests it from the Bot's head position to the Player's head position. Then, it checks if this ray collides but simply comparing it with the scenario and the player. This means, the bolt doesn't have to check if it collides against a Bot, it has to check if it collides against the scene or against a Player. In case it doesn't collide with anything it means it sees the Player, if it collides with any element it will be the scene. So, if it doesn't collide with anything it sees the Player. So this will be TestRaycast's side. The UpdateVerticalSpeed method increases speed depending on gravity. The minus 9,81 we see here in line 309. And assigns the value of the exit parameter OutMovement. And then, the UpdateVerticalSpeedByCollision method in case the Bot collides from the bottom or from the top and vertical speed is bigger than 0, we get the vertical speed to 0. This means that if the bot hits the floor, its vertical speed will be 0. If its head hits the wall, and the vertical speed is bigger than 0, this means it goes upward, and its vertical speed will be 0. And finally, the Respawn method, which will reestablish the Bot's positions, reestablish the Bot's purchaser position, give it its Initial Life in the points, establish the CurrentWayPoint equal to minus 1 so that when it is patrolling it looks for the WayPoint and state will be initialized to No State which would be our Idle in the graph we did before. So, the Update method is the Bot's complex method, which basically implements the machine in the states row. So, a states machine is implemented by a Switch. So, inside the Switch, in case we are in a determined state we implement its code. At the beginning of the Bot's Update, what we do is taking different values we need, such as the Player's position, our starter position, our position regarding the Player, we will calculate the Yaw so that it is always looking at the Player based on this direction vector and our distance to the Player. And then we go to the SeesPlayer method, which will give us back a boolean which will tell us whether this Bot sees the Player or not. These would be lines 129 to 143. Next would be the code part, which has very simple states such as Hit, which tells us what we must have done in this graph. In case the animation ID is different from the Hit animation, we change to No-State state, to the Idle state we said before. That is, in case the Hit animation has ended, we go to the No State state. In case it's Dead state, if Dead Animation animation has ended, we change to Respawn. In case of No State, the first thing we will do is establishing the animation. If the active animation in the animated model is different from the Idle-type animation, we set it as cycle-type animation, the Idle Animation. If the Bot doesn't see the Player, we change to the patrolling state. This way we get CurrentWayPoint's value equal to minus 1. In case we see it, we change to the Approach state. In case it's patrolling, if we see the Player we approach directly. In case we don't see it, we check if CurrentWayPoint equals to minus 1, which means we are patrolling and we don't have any WayPoint assigned, we assign CurrentWayPoint's value to the closest WayPoint so that we start moving towards this WayPoint. So, to move towards this WayPoint, we get WayPoint's position and we use the uniform linear motion to move towards this WayPoint. Bot's position, object we are going towards position, that's the director vector. We should normalize this director vector. So, when we normalize it, its length, its module, will be 1. The linear motion formula is: X equals to starter position plus speed multiplied by time differential. If our speed is 3 meters per second, and the time passed is 1 second, we have to move 3 meters. If the starter position is this one, we have to move 3 meters, 1, 2, 3. So, in 3D this will be X equals to starter position plus vector director, multiplied by speed, multiplied by time differential. That's why it's important that the director vector is always normalized. If we used the non-normalized vector, in example, if it was this one which heights 2.5 meters, if speed was 3 and we multiplied it by 2.5, and it measures more or less 3 meters in 1 second, we will move 3 per 2.5 per 1, which would be 7.5 meters. This wouldn't be correct. Let's go back to the code. And this is what we've done. We get the position of the WayPoint we're heading towards, we calculate the director vector which joins our position with WayPoint's position in line 180. We discriminate Y because we don't want to move in the Y plane, we just want to move in the XZ plane. We normalize the vector. Next, we update in this movement vector the Y movement based on the vertical speed, calling the UpdateVerticalSpeed method and in the line 187 we move the CharacterController in the movement's XYZ position, and we do the movement. Then, in the area 189, updating depending on this Flag which gives us back the MoveCharacterController method, the UpdateVerticalSpeed which will basically tell us what we said before, if we collide with the floor it will set the vertical speed to 0 and if we collide with the roof it will set the vertical speed to 0 as well. So, once we've moved our CharacterController, we look at CharacterController's current position and we calculate the displacement our character has had. Then, if the movement the character has made from its starter position to its new position is bigger than the distance between its starter position and the WayPoint, this means it will have overtaken the WayPoint. So, in this case, we go and search the next WayPoint. So CurrentWayPoint will be GetWayPoint to CurrentWayPoint. Give me the next WayPoint to the current WayPoint. And we establish the Yaw facing the Player, facing the WayPoint. So, the Bot will be moving facing the WayPoints he's going to. And in case the cycle animation isn't in the walking animation, we execute the Walking cycle animation, lines 201 and 202. This would be in case of Patrolling. In case of Approaching, if we don't see the Player we change to the Patrolling state and we establish the CurrentWayPoint equal to -1 so that when it swaps to patrolling again the closest WayPoint initializes again depending on the Bot. In case our distance to the player is less than the squared distance to the shoot distance, we swap to Shooting state. That is, if he is close enough to me to shoot him, I swap to Shooting. In case our distance is less than the approaching distance, we will approach. How will we approach? Just as we did with patrolling. But in this case, instead of going towards a WayPoint, we will go towards the Player, moving towards him. In any other case we swap to Patrolling state. And finally in lines 231 and 232, if the animation our character is currently going to do doesn't correspond with the animation we want to establish, we will establish this animation cycle. In the case of Shooting it is: if we don't see the Player we swap to Patrolling state, and the CurrentWayPoint is -1, again. In the opposite case, if the distance from our position to the Player's position is less than the shooting range, we set the Idle Animation cycle, lines 245 and 246, and we shoot towards this direction, that is, we execute the shoot in the shooting animation. If the shooting time is bigger that 3 this means the Bot has been in shooting state for a certain time and so, we are going to take away HP from the Player, lines 250 to 256. This could be improved setting an error percent so that the Bot can miss, such as forcing it to face the Player sequentially or lineally or interpolated with the player. Because currently it is always facing the Player, so it always sees him, it always shoots, it always hits. So, this could be improved. So, here we have many TO-DO we will do next. And here ends the Update part.
