Giving the game some life

I managed to fit more gamedev time into the schedule this week than I’ve been able to for the last couple of weeks, which feels pretty good. Although I will admit that all of the extra stresses of life lately have sort of fried my brain a little bit, so I feel like I could have gotten more done. Is it possible to ponder development problems so long that your brain just shuts down?

In any case, I quickly polished off exercise #3, which was to add lives to the game. Previously every time the ball was lost off the bottom of the screen, it would reset and reset the score at the same time. Not a particularly interesting breakout clone to say the least.

This exercise adds in the notion of a number of lives (I defaulted it to 3 because that’s how I do); when the ball is lost off the bottom of the screen, the lives count decreases, and when it goes negative the score and the bricks all reset along with the ball. On the whole, not a particularly tricky feat to pull off.

Back about three months ago (according to GitLab) I created an issue in ts-game-engine about the feasibility of custom Entity events. The general idea was that much like adding an event listener for knowing when a link is clicked, is it possible to create a custom event in JavaScript that something (e.g. a Scene) could register as a listener for, and have the ball invoke the event?

I pondered investigating that some more for use here (the original issue related to ts-tennis and having the ball notify the scene when various events occur), and in particular how it might be a better idea to instead have some sort of built in event triggering system built into the event loop. In the end I decided to not worry about that for the time being; game development time is at enough of a premium as it is currently without wasting what little of it there is with researching non-problems.

In the end I went for the old standby of declaring an interface with ball callback events in it. The Ball entity allows registering anything that implements that interface, so the game scene can register itself and all is well. In contrast, in ts-tennis I had the Ball entity require being given a specific GameScene instance at creation time in order to invoke the methods, which made some collision debugging in a different scene more complex than it needed to be.

I also made some forward progress on Exercise #4, which involves the ball spawning stuck to the paddle and requiring a click to launch it. This requires a little bit more thought as to how I want to implement it. My first blush thought was to simply parent the ball to the paddle and have the ball update its position to be relative to the paddle.

I’m not entirely sure that’s the best way to go about things here, or at least the hacky way I kludged it into the code base, since I’m currently just manually forcing the update from the scene instead of letting the ball handle it. I’m trying to keep an eye towards a later exercise in which a power up capsule could trigger a ball stick ability, in which case it should seamlessly integrate there as well.

This doesn’t really seem like a particularly tricky thing to do, in all honesty. Hopefully when my work (and sleep; been working extra hours after dinner the last couple of weeks, as well as tons of weekend time) schedule evens out again, I’ll feel less like a twizzler being shared by a couple of dogs.