Esteban Ibarra

Apr 24, 2021

5 min read

Writing a Thruster And Cooldown System for our Galaxy Shooter

One idea that can make a game more challenging is temporarily limiting your player if they happen to like to use up a particular resource. In this case, why not have a limited supply of thrust power that can be filled up by just staying still? This is similar to the Action Points system that Skyrim and Fallout use when a player wants to sprint across the wastelands, they can do so, but they’re going to come to a complete stop when they run out of AP. Afterwhich, they’re going to have to slow down and walk until the ActionPoints bar rises up again.

You can make ActionPoints regenerate faster, maybe this can be a powerup in our game too!

Just like the laser bar we implemented before, I created text that just says “Thrusters” and also added an image that used the thruster graphic and set to the image type to Fill so we can implement easy health-bar type behavior.

in the UIManager script, I created only two variables:_thrusterPower to hold the players thruster power information, and _thrusterPowerBar to of course to place a handle to the canvases image:

then a public function is made to be called by the player. It will take and make a copy of the players current thruster power, and then change the fill amount on the canvas. As 100 is the limit of thruster power and is either constantly being subtracted or added to, it gives the perfect percentage that we’ll see represented in healthbar like behavior on the screen.

On to the Player script where all the action happens!

So some variables:
_thrusterPower, this will be the actual amount of power the player has to move around with. The limit will be 100 for simplicity.

_thrusterUseSpeed will be a number that gets subtracted every frame from the main _thrusterPower variable over time until it reaches 0. At that point, the player loses the ability to move.

_thrusterRefillSpeed, I made this a little higher than use speed. No need to punish the player by making him wait longer than they need to.

_isMoving. It’s exactly what you think it is: a boolean to check whether the ship is moving or not. While we know the ship is moving, our program does not and everything needs to be spelled out for it.

and the ever so handy boolean, _canMove which we’ll wrap around the movement code and through a simple true/false switch, we’ll be able to stop the player from moving and force them to think about their life choices.

A bit of redundant key checking here. Basically if any of the movement keys are pressed, then _isMoving is true and if not, then _isMoving is false and ThrusterRefill is called. We’ll get to this soon.

TurnThrustersOn is a function that’s called in the Update so it’s always running at 60fps on average.

We check if the ship is moving and if we’re able to move. If both conditions are true, then we turn on thruster graphic and play the sound.

Most importantly, _thrusterpower is now reduced by _thrusterUseSpeed multiplied by Time.deltaTime. Once it reaches 0, _canMove is set to false and the UIManager is updated.

If the the ship can’t move or just isn’t moving, we’ll turn the thruster graphic off and stop the sound.

And for the opposite of reducing the amount of thrusterpower, this is the thruster regeneration code. To give it that authentic arcade feel, we’re going to wait 1 second before beginning to refill our players gas tank. If the player isn’t moving, then we’re going to quickly begin to refill the _thrusterPower variable with _thrusterRefillSpeed multiplied with Time.deltaTime so it does so over time instead of say .35 every frame which means an instanteous fillup.

Just to be safe, we throw in a check to see if it goes over 100, it resets to 100 so the player doesn’t overfill and throws all the other algorithms off.

Of course the UIManager is out of the loop until we fill it in, and we want to tell it our thrusterpower info is changing now that we’re filling it up so we tell it to update the thrustercount. and of course now that the player has gas, he can move.

if the player starts moving before he ends refilling, we’re going to let him start moving anyway in good faith that if he runs out of gas, _canMove will be triggered to false again when the player reaches zero again.

And that’s it! Let’s see it in action!

Lookin good! Thruster bar is going up and down depending on how much ‘fuel’ we have! Tomorrow we’ll give our game a bit of camera shake!