I made a 3D-ish shoot'em up game for the Commodore 64. At the moment, the file can be downloaded from CSDb. Grab a joystick and play.
The following is mostly about the background inspiration for the game.
Star Wars Arcade 1983
The Star Wars arcade game by Atari is maybe the greatest arcade experience I ever had.
I'd like to reminisce how I poured coins endlessly into the machine, but in truth I likely played the real coin-op only a handful of times.
And maybe for the better, as the home version on C64 and Amiga showed the game in itself doesn't have that much longevity. It's perfect for arcade, an audio-visual-physical experience leaving you hungry for more.
I can pinpoint my likely first encounter with the game to July/August in 1984, when a cabinet was present at the Space 2000 (Avaruus 2000) exhibition in Dipoli building, Espoo, Finland.
At that time I didn't quite get the 3D perspective and probably the colorful Zaxxon next to it made a bigger impression on me. I'm even unsure if I personally played Star Wars at that occasion. Later I experienced it both as upright and cockpit versions in amusement parks.
Commodore 64 versions
|Domark/Vektor Graphics: Star Wars, Space battle and navigating the surface|
There's a brave conversion made for the Commodore 64 by Vektor Graphics and published by Domark in 1988.
Although this version is nearly complete, it is also quite slow on the C64. Using a smoothly moving sprite for the crosshair does mitigate it somewhat. Some 8-bit computers lacked this advantage, but the BBC Micro version looks quite fast, although it has other problems.
|Domark/Vektor Graphics: Star Wars trench run|
The space battle is quite fast, but I also notice the enemy ships rarely come very close, and the action is often obfuscated by the ever-growing mass of fireballs.
The tower scene is very impressive, the ship rolls and there are many towers and bunkers approaching. It's also quite slow at times. The tunnel works very well, it has quite a lot going on and yet it isn't that slow.
The earlier Parker Brothers' version of the arcade game made around 1984 is also well known among Commodore 64 users.
|Parker Brothers' Star Wars: Tower scene and Trench Run|
The Parker game is not very impressive, but it is fast and the tunnel section is quite nice, it has lot of catwalks and a three dimensional projection of sorts. That portion isn't especially fast, though.
The tower scene does not have ship roll and the towers chug along in steps, not well synced to the dot effects on the ground. The on-screen player ship elements don't move at all, further adding to the stiff feel of the game.
The space battle is especially lazy, there is no attempt at all to have the TIE fighters in different depths. It is still nice to play. The Atari 2600 version is in some ways a bigger achievement, considering the limitations of that platform.
|Parker Brothers' Star Wars: Space Battle|
I began asking myself if there was a third path, something that was faster than proper vectors yet would not look so silly as the sprite-based enemies.
The result, Lancess Priya, is more of an "inspired" mini-game and not any kind of attempt at full conversion. All my games tend to be quite short, partly because of necessity and secondly because I usually prefer short games when I go vintage (Blue Max, Rambo, Saboteur, Bruce Lee...)
The game lacks many elements you'd find in the Star Wars game, and adds some that weren't really there. For example, here you have a direct control the ship even in the space battle, and you can dodge the fireballs more easily as they are not "stuck" to the screen position.
|Lancess Priya: Space battle and the Trench Scene|
I could say I'm using the the Parker Brothers' version as a springboard, building up from the compromises present in that game. Here the lasers aren't full beams, but small bolts, and pre-calculated character graphics instead of full vectors are used to draw the enemy fighters.
The number of objects and lines has been reduced to the minimum where I could still get it work at 1/2 frame rate, also using the full frame rate reticle trick from the Domark game.
It's tricky to get a screenshot that would make the game look very interesting, but it does look a little better in motion, I think!
|Lancess Priya: The tower scene|
Some technical notes
One day I might make a more thorough technical breakdown of the development process, here I only give a brief explanation to why the game looks like it does.
I toyed with the idea of making a PETSCII character-based game, but after a couple of doodles of TIE fighter frames I felt it would not be the route. The idea of using pre-stored animation frames did stay, though.
The PETSCII experiments gravitated towards using the 2x2 blocks for more motion accuracy, which made me ask whether it would make more sense to use self-defined characters.
So, this new game would use a pseudo-bitmap display built from characters, but not the ones included in the PETSCII set. Splitting one character into 8 cells gives me an 80x100 resolution.
This is quarter the amount of pixels compared to 160x200 resolution, and the benefit with a character mode is that it uses less memory and can be faster. Animation frames can use less memory than sprites for a comparable screen area. Line graphics aren't enormously faster than I guess bitmap drawing would be, probably because I can't write fast routines.
One byte defines a physical screen area that would need 8 bytes in a bitmap mode, this also means I can use 1000 bytes to define the full screen instead of 8000 bytes of bitmap. Or 2K versus 16K in double-buffering.
There are 256 characters ranging from empty to full, based on the above bit pattern.
More technically, there are some occasions where left/right can be adjusted by ROL/ROR instructions, and vertical shifting isn't that expensive either.
I decided the routine should work on 25fps if possible, or it would not be worth it. I worked with 1/3 framerate in Digiloi (2018) , but that was full color 2D character graphics.
So, the end result works on a double buffered character display with 80x100 effective resolution.