I’ve learnt about methods of applying explosive damage, asset packs, how to display 3d text as a part of the world, how to work with Unity VR, some components and abilities of the navmesh agent, how to use enum state switches for various purposes, how to primitively animate objects movement and how to call and transition between these animations.

So a trimester is coming to an end once again. It’s been a tough one this time around, but I’ve learned mountain loads of knowledge that will be key to my future within the course and within the world afterwards.

I have learned methods to apply explosive damage within unity through my shmup game and my physics based cannon game, I also learnt how it can be similar methods can be used to apply area of effect damage and area knock back with my final wave surviver game and the fps based game. I gained a more in depth knowledge of how to well use asset packs from the unity asset store by purchasing and utilising a low poly pack in my projects. I learned some small things about unity shaders when I needed to get some 3D text to appear to be a part of the world rather than float in front of everything else. I gained some experience with the steam VR plugin for unity when I worked on my Cookie Defense VR game which I have now released a version of on to itch.io. I learned many things about unity’s navmesh agent while becoming very frustrated with the many errors I have encountered, but I do believe I can more easily repeat these processes now that I have learnt so much. As I said in the previous week, I have learnt a large amount about enum state switches and I am very excited to continue learning about where my new knowledge can lead me in the world of programming. And finally, have learned about how to primitively animate things within unity and how to use these animations to trigger events. But even with these magnificent new skills, I still have lots more to learn and I am very excited to keep learning new skills and applying the ones I have already learnt.

I have a project that I am a part of coming up in the next few weeks and I hope to greatly expand my programming knowledge when taking part in it. However, I hope to even greater expand my design skills and knowledge in this project, due to the fact that I am taking on the role of lead designer for this project. But of course this is not my only upcoming project and I know there will be endless more opportunities to expand and practise my programming and designing skills. It’s thrilling to think of the possibilities.

During the past week, I extended my knowledge and experience with enum state switches. I managed to do two things that I had not done before with the state switch systems. The first being a pseudo AI fleeing mechanic, which required me to consider more about the switching of states rather than the states themselves, and a wave progression system that controls spawning of enemies.

 

Firstly, the pseudo AI system that I implemented is indeed the one I mentioned in a previous week. However, while it functioned well and I was proud of the behaviour, this intended function does still contain the failures that I mentioned. Being the case where the enemy will run past the player to run away from the player. I have had some ideas on how to solve this, but will not have time to implement them due to how close I am to shipping the project. But in the state that it is, the pseudo AI has had great effects on combat.

 

While I was creating this system, I of course ran into some issues. At first I was not setting destinations when the date changed, but instead I would set destinations in the update while in the state. This resulted in my enemy’s dancing back and forth trying to decide which destination to take. I hadn’t yet realised that I could set the destination when it switched to the flee state instead, using the update to check for when to change states rather than to state a behaviour.

 

For the second use of the state switch system was the wave controller. I needed to create a function that would wait until all enemies were dead before giving a rest period and spawning new enemies. To do this I used three states: spawning, killing, and waiting.

 

During the spawning state, the game will spawn an enemy after an assigned time until the required amount of enemies have been spawned, then move on to the killing state. During the killing state the game will wait until all enemies are dead, then move on to the waiting stage. During the waiting state, the game will wait for the assigned time then move back to the spawning state

 

I again had to use the switching of states to control behaviour, like setting spawn counts and wait period lengths. While this use is new to me, has opened up many possibilities and ways that enum state switches can be applied and it is exciting! Here is one person who has used enum state switches to both increase waves and difficulty, I would love to do this at some stage in the future.

This week I needed to fix my enemy movement. Well, the enemy does move, but occasionally the enemy will clip the floor and get some kind of phantom force applied to them making it shake and slowly shimmy away from the player. I believe this is because once the entity collides with a physical object the rigidbody is given force in the opposite direction to the navmesh movement.

This causes the entity to want to move in two opposite directions and due to the way the navmesh controls movement, the entity shakes back and forth on the spot. My immediate thought for a solution was to turn the collider on the enemy into a trigger. Which worked, but in classic bug fixing fashion, it broke something else. For some reason unknown to me, my trigger colliders started calling both their OnTriggerEnter and their OnTriggerExit functions in the one frame. This became a very large issue for another part of the project, with then prevented me from using this very simple solutions.

 

 

So, my next thought was, what if we just moved it out of the way? So, I spent some time trying to separate the body from the navmesh agent so that the body could sit higher, until I realised that I could simply increase the height. I was a little upset with myself for missing something so simple. So great, the enemy doesn’t hit the floor and dance any more(I’m a poet and I didn’t even know it!)

 

My next idea was to stop the collisions from happening. To do this if need to move the centre of the object up so that the collider sat above the point where it would hit steps. However, while this did solve the issue of hitting the floor, the walls still caused this fancy dance to take place.

 

So I finally gave some proper thought to it and I realised, if it’s an issue with a force being applied to the enemy, rather than trying to prevent the force from being applied when colliding, why don’t I just make the physics of the enemy behave differently. So, I set the rigidbody to iskinematic and voila, parties over, no more dancing.

 

So, it turns out this issue was indeed caused by the rigidbody. I had a quick search after solving the problem and found that it did indeed need to be “iskinematic” to prevent this issue. I probably should have searched this issue before I tried solving the problem on my own. I would definitely have saved a lot of time.

This week I spent some time learning more about switch systems. I used this time to create a animation system based on switches for a sidescrolling PVP fighting game. The states consisted of walking, jumping, attacking and idling. Each state was used to play certain animations and certain states gave other specific behaviors. However, it took me a long while to get this functioning properly. However, this was mostly due to my inadequate understanding of the animation systems in unity, rather than my inability with the switch system. I will need to use a switch system for my next project. The enemies within this project need to have a simplistic pseudo AI based around a switch system. I plan on having an idle state, an attack state and a state where the enemy runs from the player. However, I am unsure how to determine when to call the ‘flee’ state or what the behaviours of this state should be. I feel there should be something to do with the threat levels of the enemy, so that they run if they are in danger. But determining this seems to be the hard part. I should probably be something to do with health levels but i feel that this would make it difficult to trigger the flee state. I could also check for a player’s ‘kill streak’ so that the enemies will run if the player kills more than a certain amount of enemies at once. This would be easier for the player to notice when the enemies run. But where should the enemies run to? This is something that would be very difficult to define because of the way the navmesh in unity functions. I feel that it should pick a point a certain distance away from the player and then make the enemy go to it. But this would cause the enemy to try and run past the player and could make the enemy want to run outside the map. A better way to do this would be to make the enemies run back to one of the spawn points, keeping the enemies destination within the map but still causing the occasional event where enemies run past the player. Then they could switch back to the attack state after a certain amount of time. This would be a good solution for my pseudo enemy AI, I just hope I have the skill to implement it.

For my next project, I needed to have a sound controller. However, my initial implementation was very, very sloppy. It consisted of one sound controller for background music, one for sound controller that exists after an object has been destroyed, and one to have individual objects play sound so that the player can position the object by it’s sound. I ended with different objects for all three and two different scripts for their functions. I’m not happy with the way the code ended for these sound controllers and I know there’s many ways to simplify it, however I ran out of time and the game needed to be shipped. Thankfully the messy code had no noticeable effect on the game during run time.

 

I would have prefered to use the single sound controller, and place multiple functions within it. I would then use it to generate sound at all points and when necessary, I would destroy the instantiated sound controller at the appropriate time. This system does not, however, allow for any further tweaking to the sound before its player. The code does not have the capacity to adjust volume or pitch before playing the sound, it also requires any randomisation of the selected sound to be done outside of the controller(however this is not so much of an issue). It clearly is possible to do these things and many tutorials on the unity forums give great examples of sound controllers that do just this. For example, this tutorial gives instructions for a sound controller that allows for randomised pitch, volume and sound file.
Interestingly, after I implemented this system into a VR project I’ve been working on in my spare time(the little I get). I found that the difficulty of the game dropped massively. Prior to implementing this sound functionality, the enemies seemed to overwhelm the player at the beginning of the game, making  me believe it needed to be toned down to help the player adjust. But the moment I added sound, the player dealt with enemies with ease. This is not what I expected at all. I thought that the player might improve slightly from being able to earlier position the enemies, but going from regularly losing lives, to losing none in the first 5 waves, is a big change. So sound clearly has a much larger effect on a game’s difficulty than I thought, I’ll take this into account before trying to stabilize a game in the future.

For this next project, I’ve decided to implement a camera in a similar spirit to that of MOBAs or RTSs. This functionality would be to have a camera that moves independently of all things in the world, but can be locked to a specific object when required. This was a multistep process. First I needed to have a camera that could move with the key, simple task and was easily implemented. Then I needed to have it mount to something when needed. So I needed something to mount it to. I decided to go right into having the player movement as well, to save my time later on in development. So, I needed to be able to have a player move to a point that I clicked on within the screen.

This was not so simple.

I decided to look back at what I’ve done in the past and how I’ve gotten raycasting to work before. It turns out that my immediate belief that it would be too hard was an overreaction, because after generating a raycast at the point the player mouse is, checking if the player has clicked, and determining if the ray cast hit something, (all things I’ve done before) All I had to do was take the raycasthit.point value and feed it to a navmesh agent. So in reality, the only part I hadn’t done before was a single line, that was very specific to this task. Marvelous.

 

Now I had the player moving where I wanted him to, I needed to be able to lock the camera to it when necessary. So when is it necessary? I decided this was when the player pressed shift, but what was more interesting is when to stop following. The camera feels much more natural when you can move it away whenever you wish, with the movement keys. I used a bool that would switch between on and off when the camera locks. Every time the player presses any of the movement keys or shift, the camera lock changes accordingly.
I’d like to be able to get the camera to move with both a minimap and with the cursor by moving it to the edge of the screen. This thread details some ways that I could implement some of these camera systems at a later date. But for now, the camera work, and the player moves. Thats a win.