I’ve finished my self-programmed BASIC game!
Background information

I’ve finished my self-programmed BASIC game!

David Lee
10.4.2023
Translation: Megan Cornish

I’ve finally finished my crazy project to make a game for the C64. Thankfully. The code has reached a size that’s no longer practical.

It’s the most anticipated game of 2023 – for me. Not for the rest of the world. One reason being that the rest of the world knows nothing about it. Except maybe you, if you’ve read the article below or listened to episode 136 of the digitec podcast.

  • Background information

    A soft spot for homemade retro games

    by David Lee

I’m talking about «Herzschmerz», a game I programmed myself. In BASIC programming language. For the Commodore 64. Yes, I know, the «WTF» factor of this project is high, but that’s what happens when nerds get nostalgic. The first version was ready by the end of 2022, but a second, larger one was to follow. At the end of my article, I wrote: «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». I’ve been doing just that for the past three months. But it was anything but «relatively easy».

The new version of the game is called «Die Heart» and includes 20 levels instead of just eight. For every third completed level you get an extra life – up to a maximum of seven. Most importantly, the enemies are more varied.

In the first version, there was only one type of enemy: an evil looking head that chased you. At most, two of them could appear on the screen at the same time. Now there are seven types of enemies and the game can handle up to four of them in the same level.

Escalating a BASIC program

The variety of enemies and levels meant that I had to change the program structure. This is tedious in BASIC, especially when it comes to very long programs with many subroutines. Subroutines are program parts that have to be called up again and again and from different places. In BASIC, these can’t be named; you have to know the line number where the routine begins. These line numbers also change again and again. This made up my mind to avoid subroutines unless they’re absolutely necessary.

In the first game version, the pursuers’ movements are calculated in the main routine. In the second version, the enemy’s type is queried and then the appropriate subroutine is called up to calculate the movement.

The individual levels are already subroutines in the first version. The level subroutines in turn call up subroutines again. These draw the walls and other obstacles in the levels. This has the advantage that they can be used several times and combined with each other on a modular basis. For example, I added a wall to an existing level. This means you can no longer stop at the edge, which makes things a lot trickier.

The program comprises about 500 lines or 16 kilobytes, making it about twice as large as the first version.

I didn’t manage one enemy type

I wanted to improve the pursuers so they have to dodge walls like the character rather than running through them. By adding this, the obstacles would have a greater impact on the game and provide more variety. Unfortunately, I failed.

The calculations required for this aren’t easy, but I at least figured out the basics after a while. The program recognised when an opponent got to an obstacle and changed direction.

For reasons I never found out, this only worked when running the game directly in BASIC. As soon as I compiled it, the obstacles were no longer reliably detected. Sometimes they were, but with no discernible systematic approach.

Compilation is absolutely necessary because the game runs much too slowly in BASIC. With that, the idea died.

Music? Forget it

I would’ve loved to have stored the game with a self-composed chiptune. The C64 is well suited for this. But I would’ve had to program the game in Assembly.

While it’s possible to create music in BASIC, it’s complicated and, most importantly, it can’t run in the background. So, I would have had to intersperse a sound in the main routine every now and then. It would have been impossible to pull this off with the right timing. It would also make the code unintelligible.

Download and play

If you’ve read this far, you probably want to try the game too. You can download it here. The easiest way is to drag the unzipped .d64 file into the online emulator’s drag-and-drop field. Alternatively, there are also offline emulators such as VICE.

If you play it, I’d be interested in your feedback. Is a certain level too easy or too difficult? What about the game as a whole? Is it even fun? If yes, for how long?

I enjoyed developing it – apart from the unsuccessful obstacle detection. However, as the program size increases, it becomes more and more difficult. That’s why I consider the game finished now – even though I could definitely improve it a lot.

55 people like this article


User Avatar
User Avatar

My interest in IT and writing landed me in tech journalism early on (2000). I want to know how we can use technology without being used. Outside of the office, I’m a keen musician who makes up for lacking talent with excessive enthusiasm.


These articles might also interest you

Comments

Avatar