Still Here.
It’s been a long time since posting here.  I guess I spent more time making the game work, than documenting the process getting there.  There were a few reasons for that.  The biggest reason for me, was that I really didn’t know what I was doing.  I spent an awful long time trying to get key things looking and working the way I wanted.  I tried things and failed.  I researched a whole bunch, and failed to emulate what I was reading.  I would step away for a month at a time in frustration, to finally come back to it with an “aha” moment.

I was also busy with many other projects and of course, work gets in the way.  In the end though, I made a game I’m proud of and hit many of the goals I was shooting for.  Let’s go down the list:

Download the game here:
lunarlander.d64 (.d64 image)
lunarlander.prg (prg)

Make it look dated. No problem there.  I was shooting for that late ’70 look and I feel like I got there.  I pushed a little of the green mono screen at the beginning and kept the colors to the minimum throughout the game. I followed through with trying to represent the vector graphics look of the Atari arcade game.  For me, it definitely has a retro feel I was going for.

Use the High-Resolution mode and Sprites. Well, I backed off on this a little.  Sprites are definitely being used here.  Where I changed things up and what took me so long was making the landscape work.  I was looking to use hires graphics to create the mountains, but it led to some struggles.  I was trying to have the C64 generate a fractal landscape, so the play would be different every time.  As I said earlier in this article, I don’t know what I’m doing, so writing the code to generate fractal mountains, draw them on the screen, and make them interactive with the LEM proved to be beyond my meager skills.  It also would have been a challenge for scrolling across the landscape.

In the end, I created a mountainscape by making building block characters in my custom character set and mapping them out to build a decent looking mountain.  The mountains are 256 bytes wide, so there is a decent amount of (smooth) scrolling before the mountains repeat.  Very much like the Atari version of the game.

Write the entire thing in assembly. Yes!  The entire game is written in assembly language.  The one basic part of the program is the SYS statement needed to get everything started.  I broke the game down into several modules that I wrote separately to test and then linked them in using the library directive in MADS (Commodore’s Macro Assembler Development System), all on my Commodore 64C.  This had some good points and bad points.  I sometimes found myself trying to figure out where I put some code.  Sometimes I edited one .LIB file to break another.  I don’t regret building the program this way, but it did lead to some difficulties.

Make some sort of soundtrack. Okay.  I didn’t write the soundtrack into game play, but there is title screen music. I used a section from Jupiter by Holst for the opening title screen.  I built a very limited tracker of sorts, figured out my own method of notating notes that stored both pitch and duration in a single byte and used interrupts for timing of the music.  If you play this on a PAL machine, the music will be somewhat slower than intended.

I had originally intended to have some in-play music going, but I was not satified with anything I was writing for it.  In the end, I decided to leave the LEM pilot with the cold silence of space!

Do it all on my Commodore 64. For the most part,  this is true.  All of my coding was done using my C64c and MADS.  I did, on occasion, load up VICE and run the assembler to make a decent printout of the program.  My Seikosha printer works, but is very slow and the ribbons I purchased had dried out pretty quickly.

I really like programming directly on the C64.  I think it gets me in the right frame of mind for what I’m doing.  I know there are some amazing developing systems out there for the PC and Mac, but for now, I’m going to stick to coding on the C64.  For other things I’m writing, I have found an amazing debugging tool on MAC and PC, that lets me see what the memory is doing while the program is running.  I’ll talk about that in a future article.  I did not discover that program until after I was done writing Lunar Lander.  If I had, some long debugging sessions would have been a lot shorter.

What I Struggled With:
There were a few things that I just couldn’t get my head wrapped around for a while.  The first was interrupts. It seemed like no matter how many different tutorials and howtos I read, I couldn’t get the computer to do what I wanted it to do.  In the end, I found a routine that worked for me, modified it, and understood it.   Part of my problem was understanding when I needed to go back to the regular interrupt vector since I was jumping in more often than the computer normally does to do its work.  I also had to understand how to push and pull onto the stack which is something I had never done before.

Also, as mentioned before, I struggled with making the mountains for this game.  In theory, a fractal based landscape would have saved me some upfront work with mountain building and would have made the game more dynamic.  Building a 2D fractal mountain is not very hard.  I made a prototype version in BASIC and character graphics without much issue.  Transferring that program into assembly on a highres screen proved too frustrating to tackle this time around.  My next project has been dealing with hires, multi-color graphics and fractals on the C64, so I’m getting a much better handle on how it’s done!  In the end though, I think my solution worked really well and made other aspects of the game better.

What Can Still be Done?
Well, I am pretty happy with this product, but there are always things that can be improved upon.  I had some people over at Afterlife bbs (AFTERLIFE.DYNU.COM:6400) beta test it for me.  One of the suggestions was that it’s too hard for new players to successfully land the LEM.  Adding an easy/hard levels could be done.

For me personally, the arcade version does a close-up display when you approach the landscape.  That is something that I may re-visit in the future.

Adding game-play music is always a possibly.

A nice outside utility I could build would be a mountain builder routine.  This would give the game player a way to make custom mountains to keep the game interesting.  The landscape file could simply be loaded to overwrite the mountain data in the game before the game is run.  Should be relatively easy to do and probably the one I’m most like to try.

Post-mortem. This was a great project and something I wanted to do so much as a kid.  I’ve learned so much about this amazing computer building this game, and plan to keep making new programs that are interesting to me.  Now that the game is done, I want to go back and document some of the things I did to make it, and continue where I left off a year ago with sharing what I’ve learned.  I hope you enjoy playing this game as much as I enjoyed writing it!

Mike