ArantorAt this point we had the shell of a working game – the bat could keep the ball in the air, bricks get broken etc.
I was still putting off dealing with the balls going off the table and the inevitable joy of resetting the board state for the next life, let alone the game over state, so I started working on other things, namely: what to do with that right hand side of the board.
It seemed fairly easy to me to use the lower of the two spaces in the bottom right for a score and I already had a place to track the score, in the player object.
This means dealing with text and fonts and oh dear this is going to be fun. Now, the image set does come with a font:
All I had to do was get the font out and… actually, let’s not worry about the whole font because that brings questions about tools to actually make a BitmapFont and the fact that the 1 is narrower than the 0 and… I don’t want to deal with any of that just yet.
All I need are the 0-9 digits plus the dimmer version of the 0 because I’ve never liked having 000123 where the leading zeroes are the same colour. I always thought it was cooler to dim the digits that don’t mean anything yet. Easy enough to slap that into a sprite and draw the them on the screen in the right place, adjusting which bit we draw as needed.
Next up then, powerups. I have, of course, already by this point looked at what powerups are in Arkanoid and Arkanoid 2 and I’ve played a bit of Arkanoid: Eternal Battle by this point, and decided which ones I like, which ones I don’t, and which ones I easily have assets for.
This last point will be more important than it seems. I can maybe stitch together things in a not-tragic way but drawing entirely new things is hard. This in my head rules out doing things with the expand-base style powerup (Arkanoid ‘E’ pill) or the reduce powerdown (Arkanoid 2’s ‘R’ pill) because that would involve trying to animate the base sprite somehow and I really don’t think I have that in me (even though it doesn’t seem hard to rearrange the collider to match by just updating its control points)
But anyway I run with the first powerup that occurs to me: shield. In Arkanoid: Eternal Battle, it’s the T powerup and puts a shield along the bottom to prevent the ball going out of play. I already have an icon for it – I can just reuse the metallic shield from the display, I can butcher something together from the icon set to make a glowing-ish bar along the bottom and it’s… it’s a collider.
The first version of this wasn’t pretty – I’d made the powerup spawn from the brick collision (fine), it just snapped on, then I did a timer in the process routine based on the delta until it passed 30 seconds and then made it disappear.
As per the previous post I didn’t have to do any work, it was a collider set up to collide normally with the ball and it would just do that, but the ‘snapping on’ and ‘snapping off’ felt wrong, especially with my janky way of determining the timeout.
Time to learn about Timers properly, I figured, and in so doing realised how powerful they really were without it being awkward. I ended up making 3 timers for this object, a FadeInTimer, a FadeOutTimer and a LifeTimer.
As soon as the object is instantiated, the collider is there immediately, but I wanted to give it some semblance of life, so I made it so the FadeInTimer started when the shield was added, ran for a second and during the object’s update cycle, checked the time spent vs time left, applying this to the shield sprite as an alpha level – the less time out of the Timer spent, the less visible the shield is. It’s not a huge effect but it’s nice to have and makes it feel more polished.
We then kick off the LifeTimer for 30 seconds, and when that runs out, the FadeOutTimer begins which works in much the same way as the FadeInTimer, with the difference being that once the FadeOutTimer ends, the whole object is destroyed. Simple, elegant and feels like how things are meant to work rather than my shoddy do-it-myself approach.
And since there’s a time component, might as well use that little bar space to draw in a timer for how much there is left on the clock. Practically, not difficult – it’s just adding a Sprite2D in the right place and updating which bit of it gets cut over time.
I did for my own convenience make this generic, as a Power widget because I could see I’d want more than one of them potentially concurrently and at this point it doesn’t feel like a big stretch to be able to construct it as a scene, instantiate as needed and pump the values in from outside.
Couple of little caveats: just drawing the thing as a sliding sprite looked weird so I had it drop off an entire wedge of the bar each time the relevant amount of time passed, so it doesn’t so much smoothly tick down as ‘lose a chunk, pause, lose a chunk’ but it does exactly what it needs to do. More confusingly, Godot realigns its position horizontally if you resize the area being drawn so I have to reposition it if I resize it. (I have just realised that it is doing exactly what it should be; the origin of the bar is the centre so it is resizing about its origin logically.)
I still didn’t know what to do with the other spaces in the sidebar though.
So… I procrastinated from that as well and instead went off to make a main menu. That’s definitely a story for next time.
