Aloha!
Today there was finally a breakthrough in the behavior for the homing shots and the mechanic is more or less complete. The shots will now target whatever is the closest enemy to the player and if the current target of a shot is destroyed it will then start traveling towards the next best target. From more testing the problem that was occurring was that the distance check calculations were still recognizing an exploding enemy as a valid target until it was either deleted using the Destroy() function or another enemy got closer to the player. The main issue that turned out to be the cause of this behavior actually turned out to be a simple fix, it was that there was no logic in the script to get the “foreach” loop that I was using to ignore any detected enemy objects that have their “exploded” boolean set to true. There was previously one check for this boolean that was used outside of the “foreach” loop that would reset the saved values of the best target and distance checking function. Adding that same if-statement to contain the entirety of the logic within the “foreach” loop meant that if the iteration that is being done by the loop finds a enemy that is exploding it will exclude that enemy from all distance check calculations. Making this change had an immediate effect and the desired behavior was achieved.
Following some additional testing I made some further adjustments to the behavior of the homing shots and built a way for them to have two different types of tracking methods either strict or lazy. The two tracking methods are controlled by a boolean named “strictTracking” that is stored in the Player() script. When the boolean is enabled the homing shots will adhere to strict homing behavior where they will change their trajectory mid-flight to a new valid target if one is detected, either through an enemy other than their initial target getting closer to the player or from their previous target being destroyed by a shot that was fired earlier. When the boolean is disabled the shots adhere to a lazy homing method where they will only travel to the position of their initial target and will not change direction if another enemy gets closer to the player. If the shot’s target is destroyed the shot will continue to fly past that target’s location and continue on the current trajectory it was traveling in.
After cleaning up and finalizing the feature I also wanted to take some time to make a few quick adjustments to some parts of the game’s presentation. This led to a minor UI redesign that moved the important gameplay relevant UI elements such as the player’s ammo, thruster fuel, and lives to the bottom of the screen. The reason for this is that the top of the screen is where all the major threats in the game come from which means moving these UI elements to the bottom clears up screen space for the player to better see the incoming enemies. Additionally the Score counter was moved to the top left of the screen and scaled down a bit to account for potential of extremely high score values that would scale off the side of the screen if it was placed onto the top right corner.
In addition to the UI update I also made some changes to the feedbakc the player gets for a few mechanics. The first and simplest was adding screen shake to destroying the asteroid that starts the game to give it a bit more impact. The two more important changes were updates to the ammo counter and the thruster sprite on the player ship. The ammo counter was the largest change which involved giving the counter the capability to detect when the player runs out of ammo and react to this event. When the player runs out of ammo the text for the count will turn red and start flickering on and off to better catch the player’s attention that they are no longer able to fire. Implementing this feature involved adapting some of the logic we used to make the flickering “GAME OVER” message when the player dies.
The change I made to the thruster allowed it to scale up whenever the player activated their thrusters to make the thruster activation a bit more visually interesting. I tried two methods of accomplishing this with the first simply adjusting the scale and position of the thruster sprite every time the thrusters were turned on and off. However this led to positional issues where the sprite would start to drift away from the player sprite every time the thrusters were activated and the distance would increase as the player moved around. The second attempt at implementing this avoided dynamically changing the transform qualities altogether and instead I duplicated the thruster sprite and modified the copy to match the desired scale and position. With the larger copy in place it would start the game as deactivated and whenever the player activates their thrusters the regular thruster sprite would be deactivated and the boosted thruster sprite would activate and take its place. Once the thrusters were disabled the boosted thruster would then be disabled and the original thruster sprite would reactivate to indicated that the player is back to their regular movement state.
This finishes up the last of the major features for the Framework phase of the program and I plan to move on to the Core Programming phase soon although with tomorrow being Thanksgiving I will be taking a day off from development and resume on Friday. Some of the plans I want to accomplish on Friday is to continue cleaning up some of more bits for the Framework build before finalizing it then starting on the Core Programming material which starts with a requirement to develop new enemy movement patterns. Until then I hope all of you have a safe and happy Thanksgiving and mahalo for reading. Aloha!
— Kurt
