Aloha!
Today’s focus was entirely on completing the logic for allowing the player to fire shots that will home in on the nearest enemy. Yesterday the progress that I achieved was the ability to fire homing shots that would travel to the closest enemy’s location, but the problem was that any extra shots that were fired after the shot that would destroy the enemy would travel to the enemy’s last known location and orbit rapidly over an enemy that no longer exists.
Today after much trial and error I was able to refine the behavior to behave as intended. Completing this task was a nice exercise in working with a few different subjects such as physics manipulation and optimization. In finding a solution I had to make significant changes to the version of the script that I had last night to the version I have now. The initial version tried to catalogue every enemy GameObejct that was spawned in a list created by the Spawn_Manager script. This list would then be retrieved by the HomingLaser script on every homing laser that is spawned. Using this list we are able to pull the transform and positional date for each of the enemies in the scene and then use this data to find out which enemy is the closest to the laser when it spawns.
This method ran into two major issues upon testing, the first being that the lasers would orbit around their target after destruction, the other being that the lasers would not update or find their targets fast enough. The reason I found for the first problem was due to the lasers looking for the presence of the enemy game object there was conflicting behaviors between this tracking method and how the enemy objects are destroyed when hit by a laser. When an enemy is struck by a laser two Destroy() commands are given. the first one destroys the Collider2D component of the enemy to prevent further collisions with other objects. The second Destroy() command has a delay of 2.4 seconds that takes place before deleting the object to give the explosion animation time to fully play out when the enemy is destroyed. This meant the laser wouldn’t lose its lock on the target until 2.4 seconds after it was already destroyed. To solve this I switched the null check from the game object to the collider on the enemy that is destroyed immediately when an enemy is hit with a player laser. This proved successful as further tests had the lasers breaking off from their homing trajectory on an enemy the moment their target enemy is destroyed and resume traveling straight upwards.
The other issue that I encountered was that the lasers were not updating their targets fast enough. The first action that was taken was to move the retrieval of the data of the enemy objects in the scene from the Start() block to the Update() block. This ensures that the information is constantly updating and the closest target is constantly being reevaluated. The second action that was taken was replacing the list of spawned enemies from the Spawn_Manager script with a simple FindGameObjectsWithTag() command to keep all of the enemy object detection logic within the HomingLaser script rather than having it rely on the functions and values of a completely different script on a completely different object. This method proved just as, if not more, effective than the previous listing method and allowed the lasers to have a constantly up to date list of the targets along with a few null checks to ensure that the distance detection ignores null entries in its created array and will only take valid entries. The result after these two changes was the desired behavior where the lasers will curve straight towards the closest object and then resume a linear flight path if there are are no valid targets.
This version of the mechanic works as a good baseline to work off from as there are still a few minor bugs that still need to be ironed out down the line. However for this point in the development this mechanic is functional and any minor behavioral issues are not game breaking. One notable behavior I caught during testing was the after rapidly firing multiple shots they will continue to drift off the screen instead of finding a new target. This behavior is not ideal and I would like to fix it down the line, however with the foundation for this mechanic being built my plan is to spend tomorrow polishing this mechanic and then move on to the next step of the framework phase which is to create a UI element that displays the amount of time a play can use the thrusters that give them a speed boost when they hold the left shift key. For now here is a video demoing the current state of the homing laser behavior. Mahalo for reading and aloha!
— Kurt
