So after banging away at the keyboard for an hour or so, trying to elegantly create a routine in Assembly that would, based on a randomize index, load the appropriate cave playfield through a series of data sets, I ended up getting it to work with a simple on…goto command. It’s a bit less elegant code-wise, since there will be a bit more redundancy for each new cave playfield added, though I suppose it’s actually fairly negligible.  An extra 9-10 bytes or so, but I’ll take that if it means that it will work.

So now the game will set a random cave for the playfield and keep it until the player reaches the far right wall, at which point it picks another random playfield. I added a variable to remember which the index of the last cave is so the player never plays the same cave twice in a row.

Now time to crank out n^2 playfields for some variety!

I’ve been pondering the intention to use a ball to bounce around as part of the pulse. Considering how much code it would take to make the ball bounce in a useful way (I’d have to monitor which of the 8 directions the player was facing, then copy it to a variable for the ball, then randomize an inverted direction based on the ball’s current trajectory when a collision occurs), I may just stick with the visual pulse. The effect is pretty nice and it’s challenging. I don’t know think that the bouncing ball would really add anything.

So I just need to finish up these playfields and then add in something for randomized, moving enemies to add some extra challenge now and then. This game may well fit in a 2k cartridge, as I have 2076 bytes to spare but haven’t even used a custom include to cut out all the unnecessary assembly routines that I won’t be using, like playfield drawing.