Phase 1: Thruster Scaling Bar

A while back I had to implement a thruster speed boost where the user could press shift to go faster. This system was very basic and had no cooldown so a player could potentially hold shift and have an indefinite speed boost. Today’s challenge will change that.

Create a UI element to visualize the charge element of your thrusters.
A cooldown system is required.

Boy, this challenge was by far the hardest. Seemed simple to implement but after 3 iterations I still couldn’t make the speed boost stop when you ran out of time. Everything else was working and I had to ask in the program slack for help and eventually, it clicked when a fellow student helped me out. Fortunately for you, everything is already been figured out so today I’ll be sharing how the implementation would work.

It starts with UI

As always I like implementing the UI first and then work from there. But this time we’ll be using something different from the regular image sections. I created a new image component and added an image that would create the housing, and named it “FuelStatus”. Inside the image as a child, I added an empty object, named it “ThrusterBar” and on that object, I added a slider component. I deselected the interactable button and set the transition to none. We won’t be using the slider as an actual slider but we’ll instead be using the values as an easy and prettier way to create a fillable bar. I set the min value to 0 and the max value to 5 giving the player 5 seconds of thruster boosting.

I also added two image objects as children on the ThrusterBar object. I named one to “Background” that holds a semi-transparent shadow image and named the other to “ThrusterLevel” that would hold the actual image that we’d use as a fill. Lastly, I added a text component and named it “OverheatText” that would flash when the fuel bar reaches zero and prevent the player from boosting until the bar is full again.

In the UIManager script, I created the variables I needed and also created three new functions that would update the value of the slider, and flash the overheat text.

Finishing with the Player

You may remember my earlier article where I used “GetButtonDown” and “GetButtonUP”. Using these functions causes that part of the code only to run once while the button is pressed. I needed to make some changes to how the thruster boosting worked. I needed to add quite a lot of logic to make this work. I had to create two new systems in the function that if the user presses the boost button that the “fuel” would go down until it reaches 0 and return the player speed to normal and the player could not boost again until the “fuel” is back to 5. And also if the user releases the button that the speed would return to normal and that the “fuel” would regenerate.

I also needed to ensure that if the player stops boosting before the fuel runs out that they can boost again. I needed to create a bool to check if we are boosting, I needed another bool to check if we’re overheated or out of “fuel” We needed two floats, one for the “fuel” and one for the thruster boost.

Since we have a speed boost powerup so I decided to modify the way the speed works in the movement method to have a separate value to modify that the user can still use the powerup and thruster boost for up to 15 speed.

The ThrusterSpeedBoost() function has quite a lot happening. I’m first checking to see if I’m holding in the speed boost button, and if I have enough fuel then I’ll get the thruster speed boost. Then if I let go of the button the boost would stop. Then I also need to check if I am boosting to reduce the remaining fuel and lastly if I’m not boosting then the fuel should regenerate.

Throughout the if-else statements, I also need to update the UI and toggle the overheat text when we run out of fuel. At this point using an overheat text with fuel might not be consistent but nobody playing the game would know it’s actually fuel or a charge or something. In a full-fledged commercial game, it would be wise to remain consistent with naming things in the code and the game, but for now, it’s not a train smash.

Conclusion

Although the concept seemed easy enough the implementation took quite a while longer to implement with only the fourth iteration working without issues. I’ve liked how the slider setup worked out in the end and I’m considering replacing all my existing systems with that since you can later with a shop upgrade your ammo to hold more ammo and then you can change the max value and you’ll never run into any sort of out of bound exceptions that have been happening sometimes from poor coding implementations.