Fort Django

A little reflection on the making of a Commodore 64 game. It's the first C64 machine-code game project I've really finished. All right, it was made with cc65 C with inline assembler but what I mean it's not made in BASIC. Significantly, it's the first 8-bit game I've made public in some way.

I guess making an 8-bit game is something I would have liked to do for a long time. Fort Django was started in 2014, and after a long pause I found the energy to make it into a release.

Djangooooooooohh....!

The game

You guide the character with a joystick in port 2. You can run, climb, crouch, jump and shoot. Shoot down the baddies, collect money bags and find the exit. The descending bonus timer means the faster you can collect the next bag the more $ you can get.

The game is very short and not at all hard. The only challenge comes from trying to be faster, for example it's possible to break the $10000 barrier on completion.

Get that bag, shoot that baddie

Inspired by Saboteur! from Durell, I at first thought about making a beat 'em up oriented game. As I needed to scale down the project I found it would be simpler to turn the game into a shooter with a western theme. The map is very small, but then again I like short games such as Saboteur! and Bruce Lee, as they have a strange kind of replay value. Much like with Saboteur!, I wanted to ensure there was a definite ending to the game and score could not be milked forever.

Making of

I created the game with cc65 C compiler, using inline-assembler for speed critical parts such as the sprite routines. The C64 has eight sprites, eight 8-bit addresses for the horizontal coordinate (0-255) and one address that holds the highest bits for all the X coordinates, so the sprites can also reach the right hand part of the screen. (256-320)

For a beginner it can be a bit tricky to decode these 9-bit sprite coordinates, especially in pure assembler. I have eight separate 16-bit memory locations for storing the X coordinates. These are then broken down into the hardware sprite coordinate values. This approach is a compromise between ease of use and speed.

The figure below shows how the 16-bit X coordinates are stored in $C000/$C001, $C008/$C009, $C010/$C018 byte pairs (the grey stuff in the middle). The less significant byte of these 16-bit values can be copied directly to the $D000, $D002, $D004... but the high bit is taken from the lowest bit of the most significant byte of the 16-bit values and combined into a value that is stored in $D010.

This is done once in a frame, so the high-bit issue can be forgotten in other parts of the code. The handiness of this is only really apparent in C, where you can then move the sprite x coordinate around with:

*(unsigned*)0xc000=*(unsigned*)0xc000+1;

Comparisons between coordinates become easier, too.  This checks if sprite 7 is right of the sprite 0:

if(*(unsigned*)0xc038>*(unsigned*)0xc000){do_stuff();}

Basically all the "collision detection" is built from this type of statements instead of the hardware sprite collision address, and as such is not pixel perfect. In these box-collision cases it's better to be lenient toward the player and a bit biased against the enemies.

The "16-bit" coordinate ought not to exceed 511, because only one bit is taken from the more significant byte.

The sprite Y coordinates are 8-bit values anyway and can be handled directly with the $D001, $D003, $D005... hardware addresses.

The whole X coordinate copying is achieved with the code below, starting from the less significant byte copying and ending with the high-bit construction. Obviously other locations than $C000- can be used for the coordinate storage.

     lda $C038
     sta $D00E
     lda $C030
     sta $D00C
     lda $C028
     sta $D00A
     lda $C020
     sta $D008
     lda $C018
     sta $D006
     lda $C010
     sta $D004
     lda $C008
     sta $D002
     lda $C000
     sta $D000

     lda $C039
     clc
     rol a
     ora $C031
     rol a
     ora $C029
     rol a
     ora $C021
     rol a
     ora $C019
     rol a
     ora $C011
     rol a
     ora $C009
     rol a
     ora $C001
     sta $D010

This is a starting point for a fairly generic solution, but of course it can be adapted for any particular needs. For example, the top sprite coordinates of the dudes in the game are copied and transformed from the bottom part coordinates, which changes the above routine a bit. Also, if less sprites are used why bother going through all the eight?

About the graphics

The graphics are made with PETSCII editor. Not only the background tiles, but the game map and even the sprites have been edited there. It goes to show that the PETSCII editor multiframe-editing is surprisingly powerful way for controlling this type of game "assets".

The game map tiles.

Another PETSCII screen was wasted for defining the movement rules for the above tiles. These are used for building a movement table every time the player enters a room, just as the room is drawn from tiles. How all these sprite, tile and movement table elements exactly relate to each other is a bit too intense to explain here, especially as they are not that well thought out.

The tile movement rules. @=space, A=block, B=platform, C=ladder

The map was also edited in the PETSCII editor. The 40x25 area is divided into 5x3 tile elements, giving 64 simple screens. Coloring indicates enemies and money bags. Not everything is absolutely visible in the picture below, as some spaces can be "colored" too. The game engine allows only certain combinations and positions for the enemies and objects.

The game map.

The map memory area is also used for indicating whether objects or enemies are removed, from the 1 (white=enemy) and 2(red=bag) status into 255 and 254. After the game is over these are changed back into 1 and 2.

Editing a multicolor sprite in PETSCII editor. The sprite export is not a standard feature!

What next?

I dropped many game elements I toyed with at some point. For instance, the chests could have contained items, and the doors could have potentially led to other areas in the fort.

The gold bags were a fairly late addition when I felt that only shooting bad guys would be far too minimal. From adding the bags it was a small leap to increase the jumping elements in the game. The bags also inspired the time-based "bonus dollars" mechanic. Still there might have been a bit more to do.

Code-wise, a music routine would have been nice but in the beginning I was a bit scared to sync the animation with a music interrupt. The sound effects are also sparse due to my inexperience with SID.

Yet, all additions would have also expanded the complexity of the game and the testing time exponentially. I'm glad I could finish it as it is. With this experience I already have some ideas about how to approach this type of project better.

Links

You'll need a Commodore 64 or an emulator to play the game.

Fort Django v1.1 at CSDb
Read the blog post about the v1.1

1.0 (older version):
Direct download
Alternative link
Page at CSDb
A cracked version in a T64 format

New 8-bit pictures

Here's some pictures I made with Multipaint and the PETSCII editor. I participated in the Vammala Party 22 graphics competition held at Ikaalinen, Finland in 16th of July, 2016.

#1. Star Kerk

The first one is an MSX picture. I worked with the wrong aspect ratio (because Multipaint) and here I have approximated how it might look on a real screen.

Apart from the obvious Star Trek connection the image was inspired by the bridge of USS Pisces from a game I played long time ago on MSX, Knight Tyme by David Jones. (Spectrum screenshot below).

#2. Imjärvi UFO Incident

This is a C64 multicolor image. It is loosely based on the artist impressions made of an alleged UFO encounter at Imjärvi, Finland in 1970. However, I focused more on the colors and atmosphere than trying to include all the "facts".

#5. Botbot

I finished a PETSCII image that has been lying around for a while. I think it turned out ok, but I could have worked on the background a bit more.

#11. Fompo Killer

Another C64 multicolor, but with much less effort. It turned out the compo did need no fillers really :) I think it's nice for something that was done so quickly.

The graphics competition results in full. (in Finnish)

PETSCII games

Here's some screenshots from older Commodore 64 games with visuals made mostly with PETSCII, the internal character set.

It seems that in the early days of 1982-1984, programmers took the character set pretty seriously. Well, there probably were not that many tools for producing bitmaps, so the character set provided an easy and memory-efficient entry to the world of visual games.

Many commercial games were even produced in BASIC, and in there text/PETSCII was pretty much the only choice, as the C64 sprite commands were so slow.


Back to Nature, 1982 Commodore

A simple but ingenious game where pressing keys 1-9 will direct the tongue of the frog to different parts of the screen. For such an old BASIC game it's pretty impressive and the use of PETSCII is already quite sophisticated.


Lemonade, 1982 Commodore Educational software

A bit of a cult game, this. At one time it seemed every type-in BASIC game for a computer was something to do with fiddling money and resources. At least there's something to see here. The PETSCII use is quite minimal, we're talking almost text art here, but as the game is so old I wanted to include it.

Commodore Educational published a huge amount of tiny math/physics/history etc. quiz and workbook type software, which have a nominal amount of character visuals in them.


The Attack of the Phantom Karate Devils, 1983 Phantom Software

Can't help but to mention this game. Me and some of my Karate-hungry friends would play this in absence of better games! It's not that bad and pretty much precedes the entire 1980s beat-em-up craze. Both the logo and the game background make use of simple PETSCII, the very definition of "old school" text graphics. Later sprite and bitmap-based efforts made this kind of game look very primitive.


Murder, 1983 Rabbit Software

Here I'm mostly impressed with the two-story building plan rendered in PETSCII and displayed in parts. The game is very slow but rather well done murder investigation game. The program builds a random murder case and you have to solve it by logically deducing the killer from the answers you get from people.


The Secret of Bastow Manor, 1983 Computer Classics Pty

An early text adventure made in BASIC, with quite poor PETSCII visuals. At least it is somewhat atmospheric, though, from what little I played it. (Obviously it's very slow.) Combination of PETSCII with text adventure was quite common back in the time, and there are numerous examples in different languages.


Stroker, 1983 Magic Carpet software

An infamous yet iconic 'ma5turbati*n simulator'. Enough said.

(Well, ok, the PETSCII animation is actually pretty well done for something so old, I just won't show it here. Find the game at your peril...)


Snoopy, 1983 Commodore Educational software

Goddammit, I thought the wonky sprite-driven Radarsoft Snoopy (which BTW also has PETSCII backgrounds) was the first Commodore outing of that character. What sad state has Snoopy declined into, he seems to have more in common with Rudolf the Red-nosed Reindeer than a WWI ace.


Murder on the Waterfront, 1984 Softgold

Softgold made a few of these games with the same "engine". Here we have an inventive PETSCII logo (+ some ads in PETSCII before the game) and the game appears to be the same murder-fare as before, but in a more text-adventure vein. The character sports a Dick Tracy-style watch, rendered in glorious PETSCII. But I could not get into the game really. Could-a-been a contender, though.


Alien, 1984 Softgold

Here's Alien from the same. The initial scenario is pretty intriguing, you are driving a car in Arizona desert and spot an UFO (an animated sprite). Then you encounter an Area 51-esque compound but can't get in without any credentials. Hmm....

The environments seem better than in the 'Waterfront, there's even some attempts at one-point perspective as can be seen from the piccy.

Apparently Alien was also published for the Sega SC-3000, but with crappier line-based pictures.


Subsunk, 1985 Firebird

Subsunk is yet another plain old text adventure created with an adventure writing package. It's a bit better than the earlier BASIC efforts, and the pictures have been cleverly combined with the text box to form graphic layouts. In fact I suppose the pics+text are both contained in the same data. I don't know how common this was at the time, but clearly it's an easy way to integrate some neat visuals in an adventure. The Firebird logo is pretty decent!


The Toy Store, 1988 Loadstar/Softdisk

Just an example that even fairly late, commercial software could excuse having PETSCII visuals if the theme was "educational". The letters have been changed and there are sprites so it's not so pure PETSCII. The layout appears borrowed from Donald Duck's Playground, though.