So, currently the player could spend all their points on sonic pulses and then fly left and right again to gain back any loss within that window. I’m not sure if this could be considered an exploit or not. To prevent it, I’d have to monitor continued player progress and only award points for new pixels explored, but that means a running tally. While that is impractical for a single byte, since one could get to 255 within just two screens, using two bytes would fix that exploit. For now, I think I’ll leave it as is, to see where it goes. The advantage of being able to grab some 30 or so points by flying back and forth is negated by a little addition that subtracts points when you fly backwards.

The lives and pulse all work. Now to take a bite out of the tough part: the Assembly to scroll the playfield and create randomized caves. If I can’t find a good way to build challenging caves randomly, I’ll have to design ’em. I would prefer randomization, since it allows for infinite replayability.

Once I get the Assembly working, I’ll need to add in the bouncing ball, which may take a bit of a trick as well. Hopefully I don’t start overdrawing cycles. The game logic is pretty simple so far (or so it seems), but the Assembly routines to scroll the playfield can gobble up cycles fast.

At least debug cyclescore reports I’m never going under 2300 remaining cycles, so I should be in the clear.

Time to stretch my legs a bit!