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\u00a0negligible. \u00a0An extra 9-10 bytes or so, but I’ll take that if it means that it will work.<\/p>\n
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.<\/p>\n
Now time to crank out n^2 playfields for some variety!<\/p>\n
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.<\/p>\n
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.<\/p>","time":"April 27th, 2013 8:20 am","title":"Oh, 6502 Assembly\u2026"}