Thruster Control and Limits
In Player Thrusters Vs. Speed Boost Power Up, we talked about setting up a player Thruster, beyond the Speed Boost Power Up, and how we would introduce a payment for its use later. Well, the time has come to pay the coder… err piper.. You know what I mean.
For the UI Display, We are using a modified version of the Shield Display Shader that we made in Using ShaderGraph with UI elements. For the Thruster, we are fading from just one side and keeping a bit of the feathering which causes the edge to fade gradually.
To more finely control the Thruster functionality more than on or off we need to set up a couple new variables.
We will also modify the Start() so that the Thurster Power is full and that the Display is showing the proper amount.
Now, let’s look at the coroutines that control the Thruster Power and the Display. First, the Power Up Routine.
When this Routine is set to run, It will increase the Power or ‘Fuel’ that the Player consumes while Using the Thruster. At the end of each frame this is active, we increase the Thruster Power by the DeltaTime divided by two. The division is used to slow the refuel process down to add stakes to using the Thrusters too often. We can come back when we refactor the code and replace the hard coded 2 with a variable the Designers can adjust. Once completely full, we set the CanThrust flag to True and preform a bit of overflow balance (Using DeltaTime does not guarantee ending on a whole number).
Next is the more complicated Power Down Routine.
In this Routine, we want to make sure that it is only draining fuel when the Player is thrusting and while there is fuel to drain. For this reason we have the double conditions in the while statement. Which is other than subtracting from the Power the same as the Power Up Routine.
After the Player stops using the Thruster, we add a check to see if their is more than 25% of the fuel left. If not, the player can’t use the thruster again until it is fully powered again. This is to discourage the Player from using the Thruster to carelessly.
This is followed up by our Overflow balance to once again make sure we are at the complete mercy of DeltaTime for our final value.
Everything is now in place to modify the Thruster() method to incorporate the new functionality.
Here we modify the If/Else to allow for the new checks for Power Amount and CanThrust Flag. Inside, we a line to stop the Power Up Routine in case it is running from a previous use. The we check to make sure the ThrusterActive flag (Which is turned on by the PowerDown routine) is not on before we start the PowerDown Routine. IF we don’t do this check, we will start the routine again each time the frame updates while we have the shift key pressed and consume the power nearly instantly.
In the Else, we make sure the Power Routine is stopped and the Active Flag is set to false.
Then we add another IF to watch for the shift key being released. This is when we want to start the PowerUp Routine. We are also making sure that the Active Flag is false and the PowerDown Routine is properly stopped. In fact, the pair should be turned off here before the Else is triggered, But I have found that the extra lines of redundancy worth any extra usage in the memory. Coroutines can be slippery objects to work with when coding.
Now the Player has another commodity to worry about not over using.