Aloha!
I hope you all had a fun and safe holiday. My goal for today was to make a final pass on the Framework build of the game to polish up any of the rough edges in the design that I found and to experiment with adding a few other elements that I felt might enhance the game experience.
Overlapping Powerups
The first aspect of the game that I wanted to work on was revisiting the design of how the game powerups operate. The major design point that needed to be addressed was the logic that takes place when the player collects a powerup that effects their firing mode while already under the effect of the homing or triple shot. From some brief testing the old behavior that would take place if for example I picked up the triple shot power up and then the homing power up while I had two more seconds left on the duration of the triple shot the result was that the homing shot was ignored and it would continue to use the triple shot for the remaining two seconds of its duration, after which it would revert back to the basic shot type.
What needed to be changed was the capability for the game to notice that the player was under the effect of a shot modifying power up and to extend the duration by five seconds if the newly collected powerup is the same as the powerup that is currently in effect. If the collected powerup is different than the active one then the effect of the previous power up should immediately end and the new powerup should take its place and play out for its entire duration time. The biggest challenge for implementing this change was that the current method of managing the duration of the powerup was by using a coroutine that would pause using the command:
yield return new WaitForSeconds(5);
After this waiting period the coroutine would then disable the powerups effect and return the player to their base state. This method of delaying the deactivation of the powerup was very static and after some testing I found that even after calling StopCoroutine() the deactivation would still occur after 5 seconds. To solve this I replaced the yield command with a while loop that continues looping until 5 seconds have passed after the powerup is activated. The code block for was written as follows:
In this case we are using a float variable, called “powerUpActiveTime”, that is equivalent to the current Time.deltaTime + 5.0 and then subtracted by the current Time.deltaTime on every loop. This ensures that the function will loop and pause progress each time using “yield return null” until the powerUpActiveTime variable reaches 0. The benefit to using this variable as our timer instead of the WaitForSeconds() function is that we can change the duration that this loop continues at any point, compared to WaitForSeconds() which will commit to pausing for the given duration and cannot be changed mid process. This means that if the player happens to pick up a second triple shot powerup the function will simply refresh the duration to 5 seconds from the current time the powerup was picked up, thus extending the duration of the effect.
The other behavior that needed to be handled was the case where the player picks up a different powerup that effects their firing mode. To solve this I added checks to each shot type that checks to see if any other shot modifier coroutines were running and to stop their operations if they were, as seen in image 1.1. This ensures that only the most recent shot type powerup is activated.
Revising the Speed boost power up and motion calculations
While I was testing other features one interaction I noticed was that the player would not experience a significant boost in speed if they activated their thrusters while under the effect of the speed boost powerup. The reason for this was that the previous way I handled speed calculations was that the speed boost powerup would simply double the player’s base speed value and then half it once the duration finished. Additionally the thruster speed modifier and the power up modifier were not calculated together which meant that the thruster speed would not take into the account the added speed given by the powerup.
This needed to be cleaned up and I did some code restructuring to ensure all speed modifiers were interacting properly during calculations. A notable change was including the speed boost modifier in all movement calculations but only setting its multiplier value to 1.0f whenever the speed boost was inactive. The end result was that I had also increased the speed that the player travels at while under the powerup to match that of the thruster speed, which was 15, and I capped their max speed to 30. This ensured that the speed boost felt like a significant increase in mobility while not allowing the movement calculations to propel the player at speeds that were to high to properly control.
Implementing more visual feedback elements
With some of the time I also wanted to experiment with adding more elements to the UI to communicate more of the game mechanics to the player. The major change that I implemented were meters that showed the duration of the various powerups using a method similar to the thruster fuel meter that was previously implemented. For the shot types I wanted to try and implement meters that showed the player how much time they had left before their shot modifying power up wore off. To reduce the amount of looking around the player has to do I wanted to try and center the meters that show the duration of the shot powerups next to the player’s ship. This way the player can get the information they might need without having to look away from the action.
The meter was built to follow the player sprite around the screen and to only appear when one of the two shot types were enabled. Additionally the meter would display two different colors to further help the player remember which shot they have enabled. I wanted to have the meters match the color of the icons for the respective shots either green for the triple shot or blue for the homing shot. This mechanic was accomplished by creating a canvas object as a child of the Player object and setting it to render in world space instead of in screen space like the rest of the UI. I want to continue experimenting with this feature and possibly experiment with moving the thruster fuel meter onto the ship in a similar manner.
Another experiment I tried was implementing a meter that displays to the player the current duration of the speed boost power up. I wanted to try a different method of displaying this information compared to the shot meters by making this meter border the thruster fuel meter. The intention for this was to centralize all of the movement relevant meters to a single location to make it easy to glance over and know the status of the player’s movement options. This was accomplished by simply duplicating the slider that was used for the thruster meter, scaling it up and placing it on a lower level of layer than the thruster meter. This allowed the boost powerup meter to act a border to the thruster meter when it is enabled which allows the game to convey more information while taking up minimal screen space.
The logic behind emptying the meter is the same as the shot meters except with it’s own unique variables to keep the speed boost meter separate from the shot meters. I am still uncertain about this experiment as I worry that it may be too subtle to notice. I want to experiment with this feature a bit more at some point with either changing small things such as increasing the scale of the meter to give it more definition or finding a new placement for it.
To go along with taking another look at the movement calculations I also wanted to make a small change to the graphical effect to the thruster sprite of the player. I wanted to add some extra feedback to the player that they are in a slowed state if they use up all of their thruster fuel and have to wait for their meter to refill. To accomplish this I made another copy of the thruster sprite, scaled it down and set it to only appear when the fuel meter is being refilled after completely emptying. I feel like the visually weaker thruster would help the player feel slower and a bit more vulnerable since they are in weakened state where they cannot perform effective evasive maneuvers.
The final major change I made to the game was an extension of this experiment I was performing where I added UI elements that followed the player. This change was to add an alert that would appear above the player if they tried to fire their weapon while out of ammo. Programming this just required a sprite that was a child of the Player object and would turn on whenever the player would try to fire without any ammo and then deactivate after a short 0.5 second delay. The sprite was made using Photoshop and editing the ammo powerup icon.
That wraps up this final pass at the Framework build of the game. Starting tomorrow I will be working on the Core Programming phase of the project. Until then mahalo for reading!
— Kurt
