A soft spot for homemade retro games

The idea must sound crazy. Developing a game yourself, fine. But for the Commodore 64, and in Basic at that? The project was born purely from nostalgia. From a longing to recapture my first experiences with computers. And thankfully, I had just as much fun as I did back in the late ’80s.

Back then I wasn’t programming on a Commodore 64, but on a children’s computer that could only display text. I could only dream of visuals to accompany my texts. Therefore, getting to program a game with graphics is fulfilling a boyhood wish for me.

Countless hours passed from the first vague idea to a finished game. I sacrificed most of my free time for almost a month. Although the game is quite modest, I don’t feel it was a waste of time. I’m even a little proud of the result.

The central game loop is simple. You control a heart using the WASD keys. You must reach the gate in the opposite corner, avoiding bad guys and obstacles along the way.

My passion for this project is hard to put into words. Nostalgia is only partly responsible. The process itself plays a greater role: a game like this requires a lot of thinking, divided into many smaller tasks. Each subtask solved brings me closer to my goal, immediately visible and playable. It’s very motivating.

Above all, it’s a satisfying feeling to make something yourself from scratch. Without prefabricated add-ons and tools, as would be the case on a modern computer. It’s all completely homemade.

Coming up, I’ll show you how an initial idea gradually bloomed into a finished game.

Requirements: key input and placement

First of all, your program must recognise when you press a certain key and react to it immediately. This is what the Basic command GET K$ is for. It stores a currently pressed key in the variable K$. As a child, I only knew the command INPUT. This doesn’t allow for real-time games, as your computer won’t react until you press the return key after typing.

Placing elements freely

Second requirement: being able to freely place an element on screen. Even with text alone, it isn’t a simple feat. The command PRINT writes text wherever the cursor is – the C64 doesn’t have a Basic command to place your cursor. You’ll need to change a specific address in the chip memory using the command POKE.

Visuals as text

Ironically, my first attempt at a visual game consists purely of text. There’s nothing onscreen but two special heart characters. The blue heart must catch the red one.

Whenever a heart moves, it can’t just appear in its new spot, the previous location must be erased too. I solved this by first inserting an empty space in the previous place, followed by a heart in its new position. This happens for each loop – every frame, so to speak. That’s why the hearts flicker.

This preliminary build includes only 41 lines of code. The red heart moves randomly and is therefore easy to catch.

Proper graphics using sprites

A sprite is a graphical element that moves freely across the screen. Unlike my text-based heart, the computer updates locations by itself. I don’t have to delete the sprite every time it moves.

In addition, I can freely design the appearance of my sprite. On the C64, a single-colour sprite consists of 504 pixels (21 rows and 24 columns). There are also multicoloured sprites, but I don’t want to overdo things.

Without tools, creating a sprite is extremely tedious. To conjure up the sprite on screen, I have to edit the C64 memory map again. To do this, I need to calculate the values pixel by pixel. Fortunately, there’s always the C64-Wiki and the excellent C64-User-Manual, to grant me all the necessary info.

A sprite editor would be extremely useful for drawing and calculating. However, I’m impatient and want my first sprite right away. So, I create it manually.

It was supposed to be a broken heart. Granted, it looks more like an ass, but it’ll do.

What I don’t like is that the game runs agonisingly slowly. But why? It’s extremely simple. I can hardly improve it or add complexity, that would just make it even slower.

Compiling to machine language

The solution is surprisingly simple: Basic programs can be automatically translated into machine language using a compiler. This makes the program much faster. I run the Basic Boss compiler and boom, it works right away.

However, even at an acceptable speed, I don’t enjoy the game. It seems even duller to me than the text version. The heart no longer moves randomly, but flees from me and can also jump to the opposite edge of the screen. But that’s not enough to make the game interesting.

I therefore decide to swap roles: now the playable sprite is a runner, not a hunter. To make things a little more difficult, there are two characters to escape from. And because a bunch of hearts just looks strange, I’ll need a new sprite. I need a bad guy. And maybe a new, less asinine heart too.

Compiling makes the game much faster than in Basic, but still slow. As soon as I make it more complex, it starts to chug again. Thankfully, a necessary boost is provided by so-called compiler directives. These are notes for the compiler, placed as comment lines in Basic. This allows me, for example, to declare small integer variables as such, which makes computing much faster. Using directives, I’ve optimised the speed to the extent that I can’t even win the game any more. But hey, maybe you’ll manage – you can download it here. Just drag the unzipped .d64 file into the drag-and-drop field of this Online Emulator.

I create a sprite editor

Since I don’t feel like calculating another graphic by hand, I promptly decide to program a sprite editor. That’s a lot more work, but it’s fun.

This piece of software is far from perfect, but it gets the job done. Besides, it only took a whole weekend to program the editor. In the process, I learned a lot about loading and saving on the C64. And I now know how to cache a full screen and restore it later. I can make use of that down the road.

Collision control

Since you no longer have to catch a heart in the game, but escape, the game needs a new goal. Again, I make it as easy as possible for myself: your sprite must reach a small gap without being caught. To increase the difficulty a bit, I place some obstacles.

The C64 features built-in collision detection. By querying the value of two specific memory maps, my program knows whether the sprite will collide with a villain or the obstacles, respectively.

Multiple levels and multiple lives

Next, I want to make several levels. This can be done with little effort. In principle, I only need to change a few variables such as the starting position of the figures or obstacles and then run the program again.

What’s trickier is tweaking levels so that they’re neither too easy nor unsolvable. After all, I can only play the game up to speed after compiling, requiring me to recompile after each change for testing. I can speed up the CPU in an emulator, but that only gives a rough impression, it’s not the same.

For eight levels, multiple lives seem a fair feature. These are displayed on the right as hearts – my text-based icon is back!

In addition, the game needs a start and end screen. Again, I make it easy for myself and inflate the size of the sprites. The C64 can do this out of the box. When you have completed all eight levels, a small animation will also appear. At last, my game features all the basic elements.

Conclusion: not so simple after all

In its final form, the program contains about 240 lines. Despite its simple appearance, a whole lot of work, ideas and concepts go into making a game such as mine. At least if you create it yourself from scratch. Now that I have the foundation, I can expand it relatively easily by adding more levels, incorporating other sprites, and programming new enemies with different paths. In addition, there’d also be more complex additions, for example, allowing enemies to avoid obstacles or making them crash into them. Or characters changing their appearance under certain circumstances. Music and sound effects are a wholly separate issue.

I won’t get bored anytime soon. Let’s just hope all the madness ends around the same time winter does.

Here’s the download link one more time: Herzschmerz (Heartbreak) for the C64