Retooling for the Boss Jam

Once upon a time I created this game in a mere 8 hours of coding.  It was more of an experiment in how long things take, and in getting a project going quickly. It was good practice, it was playable, but now it's time to make something more of it.

Enter: DragonRuby BossJam

The idea is simple, create a game with a boss battle in it. It's the perfect opportunity to get more mechanics and content into this game. But to do that, a little housekeeping was needed first. The game was made in 8 hours, and I was (and still am!) a rookie developer. It's a mess in there! 

The first thing that needed doing was updating the game to run with DragonRuby 3. DR is very good with compatibility, so there was only one issue to address... a NilClass error from DR reducing the amount of bullying it was doing to NilClass. My fault, of course. I don't recall now if the game predates my state management snippet, or if I simply failed to implement it, but instead of a playing state and a game-over state, there simply was no state. To end the game, I deleted the player. Entirely. It worked, but a few calls were still being made against the now nonexistent data, and DR had stopped bullying Nil to make it cooperate.

So in went my state control snippet. A fairly simple retrofit, there were only two states! A first victory in this new adventure, but immediately valuable. Not only did this fix the game, it also made it trivial to add a new third state: Pause. With better control over what code was executing, it was simple to implement a game pause - split the rendering into background and foreground, always render background, and stop calling foreground and any game logic while the game was paused. And so we have it, the first update on this road to a "real game"!

So what's next? What's this about a boss battle?

There's much to do, but it wouldn't be an adventure if there wasn't. Most of it is going to be converting hastily assembled behaviours into real features:

- enemies don't have hitpoints, they just die when shot; well we'll need to implement hitpoints and shields if we want bosses, won't we?
- enemies don't have AI, they just run around like headless chickens and change direction at random; boss phases will likely need distinct AI
- enemies just spawn every few ticks; we'll need waves and triggers

There's more, of course, but this is where I'll start. Fix up the current enemy capabilities and make them customisable, and then make them respond to logic. Before long, we'll have elites, and after that we'll have bosses!