August’s Program: Space Lander
Move the lander and hope to find the best landing site in this ZX81 game!
Okay, this may not be the large program I promised, but I choose Space Lander for a different reason: it's horrible! Okay, maybe it isn’t that bad, but it definitely wasn’t one of better programs. This was from 1983, clearly one of my earlier attempts. Actually, it is kind of refreshing reminder how much better my programming has become. If this helps others learn, then by all means check out the listing.
For those that are just looking for punishment, you can try to land your spaceship instead. I did say try, right? This game is horrible unfair. You basically move your ship right or left until you feel ready to chance the landing. There are no clues as to where the landing pad is and, to add spice, it randomly picks from three different locations. It isn’t entirely a crap shoot as you can quickly figure out where the three landing pads are and can try to just pick the spot that likely will appear. Yes, I had no clue what fun was back then. Oh, to really mess you up, the controls are backwards from what is stated and the ship will list to the right on its own. (sigh)
Getting back to the program proper, it is horribly redundant. I used the same line to print the ship 6 times! The landing pad could easily have been calculate and printed instead of the three hard coded landing strips. The ship’s controls are two blocks of code with just a single +/- differentiating them. Without changing functionality, the 47 lines of code could have been halved. As little fun as it is to play, I probably just moved on to more interesting programs.
Beyond redundancy, I used poor program control. The program jumps around with GOTO
calls. Not too bad, but GOSUB
/RETURN
would probably have been cleaner. The main loop has two endings due to the use of GOTO
. Clever huh? Not. I also used two infinite loops to end the program. Yeah, really not clever. I could easily have added a nice ending and an option to restart. Or just end like most programs do. Really, you have to break the program to stop it? What was I thinking?
Okay, so not the best program to showcase for the month. However, sometimes the worst programs are the best learning tools. Knowing what not to do, even if it works, is still great training. You should learn from your mistakes and practice is always the best way to better coding. Not that folks programming in modern languages will make these same mistakes. But the concept of optimizing code should never go out of style.
Have another great month!