/Writing a C64 game in BASIC

Writing a C64 game in BASIC

When I was around 10 years old my parents bought a Commodore 64 for me and my little brother. I was immediately fascinated by this machine. It came with a ton-load of games, but it also booted to this fascinating blue screen that welcomed me with the text READY_. It’s on this machine where my love for programming and gaming started, two things I still love doing up until this very day.

For a new RetroGameCouch challenge Rampage and I decided it would be fun to both try and write a game on an actual Commodore 64 since we both have such a machine (I have around 20 of them) in our retro collection. We had given ourselves one month to develop the game, and we could only use BASIC and refrain from using Assembler. We could also not use extensions like Simons Basic, to ensure a level playing field.

I decided to try and recreate the development environment I would have used 30 years ago. So I inserted a Power Cartridge into my main C64, connected a 1541 drive, hooked it up to a CRT and fired it up. The Power Cartridge logo appeared.. oh how I missed that screen.

The first thing I obviously needed was an idea. My initial plan was to do a remake of one of the first games I made on the PC, which was called HackTheGame. It’s a game I wrote in Visual Basic 6 somewhere around 2005. It was quite popular for what is was at the time. I still have it’s website up today (http://www.hackthegame.com) for nostalgic reasons. The game is mostly text based, which would translate pretty well to the C64. After a few prototypes however, I felt I was reaching a dead end.

A new idea came to mind when I was checking out some games for the CBM PET. I saw a game called PET MINER and thought “I can do that!”. The game is entirely made in text-mode and based around the concept of mining for gold underground. Add my love for Minecraft to the equation and the idea was born; A mineral mining game in 40 by 25 columns text-mode! Let’s get to work.

After a first attempt of writing the routine that would draw the level I ran into some problems. It took me a while to realize (or actually re-realize) that C64 BASIC variables can be 80 characters long, but the BASIC interpreter only distinguishes them by the first two characters. So AB$ and ABC$ are the same for the interpreter. As soon as this was apparent to me I head to figure out how to make ‘functions’. Of course, the infamous GOSUB command. I had to work around the lack of parameters, but with these limitations in mind I started working on the game.

The development of the first few iterations of the game went rather smooth. I had a lot of fun working on the game, and seeing it grow slowly into a very basic version of a mining game. The entire game logic is based on POKEs and PEEKs of the video memory (1024+X%+(Y%*40)) and color memory (55296+X%+(Y%*40)). This however posed a problem. The POKE-ing and PEEK-ing of those addresses was rather slow. This meant that the more functionality I added to the game, the slower my character moved around.

After some research I found a program called Blitz, which compiles BASIC and as a side-effect also made my game run about 80% faster. This however caused a new problem; my character moved too fast. As a child I always relied on FOR-NEXT loops to create delays, but this didn’t work reliable after compiling the sourcecode. I needed a better delay routine.

I learned that the C64 has a system variable called TIME (or TI in short). This variable is an interval timer counting “jiffies” (1/60 second increments). It is normally incremented during the standard 1/60th-second CIA1-generated IRQ service routine. Perfect for creating a reliable delay!

T0=TI:FOR T=T0+T*60 TO T:T=TI:T=T-5814e3*(T<T0): NEXT: RETURN

The number 5814e3 is 5184001 jiffies, which is 24 hours + 1 jiffy. To use my routine, I can simply do:

T=0.1:GOSUB 9000

This delay works the exact same on both the uncompiled and compiled version of my game. There is however a small (neglect-able) difference between NTSC and PAL systems using this method. Read more about that here.

After a while I had my own interpretation of PET MINER running and decided to add gameplay elements to make it more my own. I added different layers of stone, which required different levels of pickaxes. Each layer also has a specific chance of spawning certain ores, of which the lowest ones have the best.

If you have collected enough ores, you return to the shop to sell them. If you have enough cash, you automatically upgrade your pickaxe to the next level. The price of the pickaxe incrementally increases as the levels progress.

To add an extra challenge I added oxygen to the mix. As soon as you submerge under ground level, your oxygen level starts to decrease. When it hits zero your health is affected. As soon as you re-emerge your oxygen level restores, but not your health. If your health reaches zero, you die.

All I needed now was an end game; a way to finish the game. So I decided to add one special ORE, the RED DIAMOND. It spawns on a random position on the bottom layer and can only be reached if you have upgraded your tool to the maximum level. As soon as you harvest this diamond, the game is over.

Here is a screenshot of my son reaching the red diamond! He was actually the very first person to finish the game (proud dad!).

I truly had a blast revisiting my very first computer and creating a game on it, like I would like when I was 10 years old. Just, with a better understanding of structuring a game, and making something worth playing.

You can download the .d64 here.