Introduction

This was a relatively minor update in terms of content added. Enemy shooting finally works, as does a maximum speed for player acceleration/deceleration.

Enemy shooting

One of the earliest problems I had in making the game was getting the enemy to shoot. For its aim, I used a raycast function. I reused my code from a tutorial exercise and modified it for the Enemy Aim script,  so that it only casts rays in four directions. However, when I tried this out, the rays' end points were stuck at different points of the screen, not moving when the player moves.

With help from Ian, I was finally able to do this on Monday. One of the solutions was to make the distance variable only contain the magnitude of the direction ray, and another was that, when I draw the debug line, I had it end on a point some units away from the enemy's position (transform.position + up). 

After that, I made the rays change colour when they hit the player. This was the starting point in implementing a shooting mechanism. Next, I created a copy of the bullet prefab for use by the enemies. Back inside the Enemy Aim script, reused my player's shooting code for when the enemy fires bullets. The enemy did indeed fire bullets when it detected the player, but it fired too quick. I decided to use a Coroutine so that the enemy fires bullets only after a certain time. I simply placed my shooting code inside it and had the update method call it when a ray hits the player.

A new enemy

Having created the necessary enemy mechanics, I went on and added my cop enemy. Like the badger, its design was modified from the player, but made chunkier.

This enemy uses the pursue script, instead of the seek script used by the badger. This means that it will try and predict where the player is going. I also changed its bullet speed to be faster. I intend this enemy to be harder to fight than the badger. 

Max speed

To implement a maximum speed that the player can move forwards or backwards, I again required the assistance of Ian. On Thursday, just before I uploaded my third build, I asked him for help in implementing this. The solution was that, if the magnitude of the player's* velocity (or rather, its RigidBody) is greater than the max speed (a float), then make the velocity normalised and multiply it with the max speed (that is, keeping the speed stuck to the maximum). Otherwise, accelerate as usual. When going in reverse, this changes so that when the player is going less than negative max speed, then multiply the (positive) max speed with the negative, normalised velocity.

This has worked well for going forwards. In backwards, it still appears to be uncapped, although it may be because the capping is less obvious backwards.

Criticisms

As usual, when I submitted my build on Thursday, I received some suggestions. I already pointed out two problems that I wasn't sure how to fix:

• The game is intended for 16x9 displays, but when I upload my build it defaults to 4x3 or something close. As a result, the camera stutters a lot when going to each side of the road. I didn't know how to change the aspect ratio in Unity; the itch.io display settings didn't fix this problem
• When an enemy pushes the player, the player will continue going in that direction even when they are only pressing W or S. I could fix this by touching the side of the road

I'm sure that I could fix the aspect problem now, and as for the enemy pushing, I'll probably make it so that enemy collision results in death of the player.

One student also pointed out that, when driving alone, something happens that causes the player to get stuck on the side. I think I have noticed the problem when testing the game on Chrome. This may be related to the aspect ratio, since I don't encounter this problem when playing in the Unity editor.

Conclusion

I am currently implementing the animation code for the driver, and likely the enemies. Since there is already some animation code in the script I used as a basis for my movement controls (Eight Way Movement, from tutorials 8-15), this shouldn't be too hard. I'd also like to add more obstacles for my game, such as potholes and wooden barriers.

But until next week, this is Siderun, signing off.