I burbled a little previously about my aliens working from their scripts and was worryingly proud for some reason; since then the player’s ship has been introduced to the concept of firing bullets, everything has been taught to notice when it’s collided with something that should make it explode and just for good measure the explosions themselves have been bolted in for full-blown kabooms and to fling the odd burst of fire around when bullets make contact with shielded enemies.

So the next step is to slap a simple front end into place and get the game transitioning from titles to game and back cleanly (the number of times I’ve tried this and found that what was assumed to be stable code royally broke when it couldn’t rely on it’s variables being zeroed at declaration is remarkable) before strapping a life counter system into place, a temporary shield so the ship can be thrown back into the fray after death without immediately combusting a second time and the beginnings of the score handling.

I also need to think about scrolling backgrounds – the method of storing the data is already settled on (a large image which gets sliced into screen wide strips that are probably going to be 32 pixels high, essentially a variation on the column compression I used back in the 1980′s) but there will need to be an “editor” cobbled together to make landscape production a little easier.

Today the little… aliens learnt how to fire properly – as with their movement, every nasty has a script to work from that says which bullet to use, initial speed and angle (the latter of which can send “commands” for rings of bullets, aimed shots and random sprays), change values for speed and angle, the delay between shots and how many to actually fire before moving on to the next set of instructions. Currently there’s a hard-wired maximum of eight states, but if anything needs more it’s just a quick change of a constant.

Of course, the system didn’t work first time and I’d have been quite frankly stunned had that happened, as I “joked” on assorted social networks the nasties appeared to be holding their script upside down (I suspect that one or two had perhaps picked up something from an old episode of Emmerdale) but eventually it flew and they in turn let fly with both barrels. Now I can define some fairly complex patterns on an object-by-object basis, trigger pauses, loop to a command rather than just the start and I’ve got plans for more.

Because things have been rather non-visual lately, here’s a quick screenshot of the new and improved Blast Engine (running with some “borrowed” sprites from Tehkan’s classic Star Force for no other reason than I’ve always liked that game):

The curvy ring-shaped firing is handled from the script, the command for the purple bullets look like this:

<fire>
  <bullet=bullet2>
  <speed=2>
  <speedchange=0.2>
  <angle=ring>
  <turn=2>
  <delay=10>
  <repeat=8>
</fire>

Simples!

I’ve come to a decision; the previous iteration of the Blast Engine had become an ungainly mess internally and the object oriented approach used was all but crippling the options for expansion; for a month now I’ve been looking at specific elements of other shoot ‘em ups and thinking to myself that it can almost handle them but not quite – and that inadequacy (as well as the need for lots of little blocks of bespoke code to fudge around the engine’s failings) has finally become too irritating to ignore.

As a result, I started a new version of the Blast Engine pretty from scratch yesterday using an “oldschool” array-based object handling system (still with the SuperStrict mode enabled in BlitzMax to keep my variable declarations on the straight and narrow) and already have a movement pattern system that is significantly more flexible than the previous one and plans for a scripted firing manager that should give the old version a serious kicking as well. At the moment, the only question being raised is how to handle bosses and a few vague but reasonable ideas have already presented themselves…