Domain 83 for Commodore 64

Domain 83

This Commodore 64 game has been long in the making. Not that I've coded it for that long, it's just that the first version was started around 2016, abandoned, had a few false starts, and then I wrote again entirely new code at the end of 2025, salvaging whatever I could from the previous projects. Some of the sprite graphics and background tiles have made the long trip from 2016 with very few changes.

A small number of game projects were started very soon after Fort Django (2016), but they were mostly abandoned and what eventually came out was Digiloi at the end of 2018. Digiloi also resulted in a flurry of ideas for PETSCII games, which didn't materialize, but that's another story.

So, Domain 83. This game combines ideas again from Bruce Lee and Saboteur yet puts them through similar streamlining as in Fort Django, this time with more effort towards visuals and more complex game content. 

An early version from around 2018

Over the years I also looked at diverse ideas from Athena, Impossible Mission 1/2, Freak Factory and Nexus. Amiga versions of Stormlord and Wolfchild also occupied the same mental landscape.

At times I figured the game could have more exploration and adventure elements, especially the weird tone of Nexus seemed intriguing. In the end I streamlined the game a lot and the result is more "fast and simple Bruce Lee" than anything else.

Later exploration of a scrolling bitmap as a game background: nope.

The 2016 graphics were strongly influenced by Impossible Mission II, but I found the perspective too inaccurate for the kind of engine I was working with. Also as I heard of "Impossible Mission III" being in the making I wanted to avoid that association. I made the perspective simpler. Near the end I drew a lot of visual inspiration from the Amiga game Flashback.

I especially wanted to avoid the narrative-driven arcade adventure. What I mean I just don't want to see character dialogue or ominous text messages on a terminal screen in a game like this. Or even cut scene animations. Some may feel it's a missed opportunity, but I'm really always impressed by the replay value of short games like Bruce Lee and Blue Max, where such narratives do not intervene.

New start: Domain 83 in mid-December 2025

This game really started from the sprites. I had this idea that if the player could be made from a vertically extended sprite, and highlighted with a non-extended sprite, I could have 4 such entities on screen without even considering multiplexing. And furthermore, if the said game character were to make a flying kick, it could use a horizontally extended sprite instead. And if these extended sprites were drawn in a certain way, they wouldn't look blocky.

The sprites were drawn in Multipaint C64 hires "limitless" mode, so I could just freely create a sprite sheet I wanted. I needed to mentally understand the pixel shapes of the extended sprites, as I wouldn't rewrite Multipaint just to have a quirky sprite handling mode. A Processing sketch was written to convert all the sprite frames and their exceptions from a png into a source file.

As there are more than 80 sprite definitions, and I was expecting more to come, I preferred not to have them at the video bank locations, where they might complicate memory use. Instead, animation frames are copied to the video bank positions when needed. For the enemies, this is not done for each screen update, as the copying would take too much processor time. In addition it was easy to add some programmatic animation to the sprites, especially their disintegration when killed.

I also took advantage of free positioning of the two sprites, so the overall animation frame size can be maximized where needed. So the punch animation frame for the player is wider than 24 pixels, as the bare hand extends beyond that limit.

Part of the sprite sheet, over a 24x21 pixel grid (normal sprite size).

And although the main character gender wasn't a determined outcome of this process, it struck me early on that the ninja from Saboteur 2 could work here. Yet I didn't want a ninja hood covering everything. Maximizing the top sprite led to the "bare midriff" idea. Honestly. So the design of the main character game arose almost entirely from the technical schema.

This also helped establish the color balance for the game. The usual C64 black backgrounds I have mostly favored, would be out, and colors like grey and cyan would be in.

From the days of Fort Django the bar for decent C64 game has been raised quite a lot, or better said there is now a sea of releases. I wanted to see if I could make a more polished output this time, yet I'm not too keen to overdo it or pour on a lot of presentation. I'm still very fine with "1983" style video games, and the self-imposed single file limitation gives a suitable project scope.

The previous release, The Last Z-8 in 2024 was made quickly, based on "safe" and known techniques and learning almost nothing new about the C64 itself. In turn, Domain 83 explores more complex sprite graphics and multicolor character-based tile maps with more detail than I have done before, adding some beat-'em up elements.

A green room.

In 2016 I was still too inexperienced to finish a C64 project of this complexity. Character graphics, tile maps, sprites, music, sound effects, it was still all too much and I ended up with something that looked promising but glitched too hard and I lost track of memory use.

Even as I restarted everything in 2025, I ended up facing some of the same difficulties. If the sprites' relation to the tiles is not very well defined, it can result in ambiguities, undesired behavior and glitches. These are then fought against by making exceptions and fixes to different situations. The base "world physics" could only really be written once, whatever came after is sort of a bodge on a bodge, and each fix contains a risk of producing another problem.

As the game has ladders, jumping, falling, punches and flying kicks, it's quite tricky to follow what the player can or cannot do in a particular situation. Suddenly I find it's possible to exploit a room edge to travel through a wall, or something similar. The lesson learned might be the "world physics" could have been written even more thoroughly in the beginning.

Instead of having the player character "stuck" doing an animation I'd rather have the sprite move as freely as possible, following the joystick instantly. So the opposite of the Prince of Persia/Flashback approach, not that I could have that animation anyway.

First three rooms in Tiled: Enemy positions and trapdoors are baked in the map data

The map is of modest size, I preferred to have more graphic variety instead of a large abstract map. There are still more than 40 screens. The metatiles are made of 4x2 multicolor character tiles. I drew the metatile sheet with Multipaint and created the map with Tiled.

Another sketch made in Processing converted the characters, making note of repeat characters and their color variants, and exporting both the characters and the metatiles as a source. So I could be constantly aware of how many characters have been used out of 256, and reduce their use for certain tiles if so needed.

Each metatile points to a "movement tile", or shadow tile, which defines the actual air/platform/ladder/walls. There are less of these shadow tiles, so the shadow tilemap is considerably smaller than the tile definitions. So what is seen on screen is only visual.

Grid showing the 4x2 metatiles

The 4x2 metatile size, instead of 2x2, is something I learned by inspecting the C64 Turrican map. A wide tile can give an impression of square tile, as a few "square tile variants" are baked into the metatiles. This helps save memory with the map, but can make it necessary to produce more of these tile variants. Turrican only has enough variants to help keep up the illusion of a more precise grid.

Domain 83 graphics style and platform screen alignment for these tiles meant I had to produce quite a lot of tile variants, but in the end I didn't really run out of metatiles (160 out of max 255), characters were far more precious in the end and I ended up examining where I could exchange or use same characters without losing real detail.

Part of the metatile sheet

At the beginning of 2026 I was very confident that the game could be finished for Zoo 2026 demoparty, but the months soon went by. At summer I made moderate progress. As the event neared, I learned the deadline was four days earlier than I had assumed. A quick decision was needed. Should I sit on this, releasing the game next summer?

I tried to finish as many rough edges I realistically could, and submitted the product for the game development competition. At this point I knew there were still glitches here and there, and the game content doesn't vary all that much especially towards the end. But it's not likely that the few days mattered much. It's more like I used the impending deadline as an excuse to have an outcome at all.

A problem of pacing was that I wanted the player see early on the technical feat of three simultaneous enemies, but those enemies can be quite difficult. So the difficulty curve is all over the place really. Avoiding the enemies is often easier than fighting them, but will lead to lower score. Hopefully all of them cannot be avoided!

At first crouching had no use in the game at all, I was still toying with the idea of something thrown at the player or avoiding lasers or other items. But in the end it works like in Bruce Lee: player can avoid the enemy hits. I was never very satisfied with this so I made up this thing where the androids become "angry" if you crouch too much. After they become angry, they are able to hit you even if you crouch.

The result at this point is not as finished in all fronts as I could have hoped, but I feel it's fast and playable enough and does what I aimed to do.

Entering the "sewer" section.

There may be a fixed version that addresses some of these things, and the number of small glitches and bugs, but I am not sure if it is worth the trouble.

Oh, the name? It was one of the last things I decided. The title screen just had a few red blobs for a placeholder, produced with the same tile/map engine that does the rooms. Essentially the title screen is just another room on the Tiled map. I could have made a separate routine for drawing the logo in character precision, but I needed to save time. So I knew the name itself would be constrained by the engine limitations.

Thinking about it, one of the words suggested by the space and the emerging lines was "Domain".  Looking at Lemon 64 database, I learned a game called "Domain" had been planned for the Commodore 64 already. Interestingly enough it's a side-view game with big sprites! I ended up with "Domain 83", in reference to the "1983 principle" I occasionally think of when making games.

The game at itch.io:

https://drterrorz.itch.io/domain-83