We continued looking into dot products, including how they’re calculated and what they could be used for. I understood the gist of the information I found out during my research blog post, however (as always) it helped to put it into a game environment context. We were given some examples of how to calculate the dot products of some vectors:
The dot products of the calculations to the left are 10, -47, -41, and 0.5 respectively. As we found out, if the number is in the positive, it means that there are less than 90° between the two objects. Obviously the inverse (if the number if negative) means there are more than 90° between the two.
These sort of calculations are good for vector projection; perhaps going over a booster on an angle and where the two vectors will meet can be determined via dot products. Otherwise, the cone of vision used in our trio game employs dot products, as far as I understand.
The dot product gives the cos of the angle between the two vectors, times by the length of each vector. When you’ve normalised the two vectors, you don’t have to worry about the length – the dot product will then just give the cos of the angle between the two vectors.
After that, our trio were tasked with integrating some new scripts into our practice game. We started by just applying the scripts to our wandering guards, to see how they worked and watch how the cone worked with the game – to us, it wasn’t quite right since it felt like the cone should change depending on which way the guards were facing.
Since this was a rather challenging task, we asked Ant for a little help; we were shown how we could use the direction of the next waypoint to determine the direction the guard was facing. This worked a treat and was going to be incorporated into the cone of vision script, as seen below:
Using this, we changed the cone to actually be in line with whatever direction the guard was moving, as seen in the two screen captures above: the first is the waypoint script, where we feed back the moveDirection to the second cone of vision script. The angle of the cone was no longer fixed, but rather changed depending on the moveDirection. It would then be able to determine whether the cone’s angle and the target overlapped.
Furthering on with this plan, we also knew we wanted to change the way the projectiles work. Marc and I wracked our brains for a while trying to come up with the solution of having the projectile move in the same direction the player was in – this sounds a lot easier than putting it into practice. I was on the right track, I think, while looking into how to so it – I needed to use the searchTarget from the cone of vision script to determine where the projectile would be going.
We needed to ask for help once more and was shown the following addition to our AutoFire script:
Essentially, we determined the direction the projectile would go by taking the searchTarget’s position and subtracting the transform.position. We then needed to calculate the angle, which I hadn’t realised I was using the 3D Unity methods rather than the 2D unity methods – a bit annoying, but I still learned something new for future games! In any case, we calculated the direction and the angle, thus we were able to instantiate the projectiles using the angle as the z value in the Quaternion calculation. After that, it was simply a matter of playing with the values for the shotTimer and rateOfFire to get something that worked with the gameplay.
Below is a GIF that shows the scene window while the game is being played; this is where the cone of vision for one of the guards can be seen, along with the waypoint paths being taken. For testing purposes, we have the sprites change their material colour to red when the player is in the cone of vision; in my mind, this sort of represents aggro and can help the player out if the situation is sticky.
I think there are a couple more things I’d like to do on the trio game before we’re demoing them on Monday. I think the biggest one is that the projectile sprite should be something other than the original bullet fire we were shown. It also feels like it would be neat to add some trebuchets or something, just to see how the code can come together on a stationary object that might still rotate on the spot.
Overall, I think it’s a good example of everything we’ve learned for the last few months and I’m looking forward to putting it all on show for others to see. I’m sure there are many other games that can be made with these mechanics (or variations of them) and I might even revisit the Animal Rescue game my friends and I made during the Christmas holiday.