Ah, me and getting sidetracked… the weekend just gone was mostly spent writing yet another horizontally scrolling shoot ‘em up for the C64. This isn’t even close to news (although my actually finishing one might be) but there’s a kink to this particular project. A couple of people have said to me previously that they felt working in a machine code monitor with a single pass assembler and disassembler was somehow easier than using an assembler (most of them were beginners to machine code programming) and one particular individual, an almost fanatical supporter of monitor-written code, commented repeatedly about how much of a “palava” using an assembler was despite not having used one.
Said individual recently resurfaced to post a little garbage to the comments on my YouTube videos and, after I deleted them and blocked him, it set me thinking a little; although I’ve done a lot of work in various monitors over the years and even hand assembled code for the VIC 20 back in “ye olde days” (and that’s so much fun, even now I can remember some of the opcodes in decimal) I’ve never actually written a complete game with a monitor. Some of the people who developed in a monitor like John Ferrari, Stavros Fasoulas and Jon Wells have produced some cracking games (although the difficulty curves always seem to be rather harsh, I have my own theories as to why) which means that, despite certain other examples being utterly appalling, it must be possible to produce something decent.
So to quote Jeremy Clarkson, how hard can it be? Not particularly hard, as it goes, but certainly laborious to an almost masochistic level because tasks that are relatively simple in an assembler such as adding or subtracting commands or even relocating large blocks of code become fiddly operations with the monitor and every subroutine or table of data needs to be documented to avoid forgetting what they do. Usually I can keep the memory map straight in my head (although I usually have a simple memory map at the top of my source code) but the notes I’ve compiled so far for this project resemble something that Ordnance Survey would churn out!
The game itself is coming along nicely though, after three days of occasional coding it currently only lacks background collisions before the most important parts of the core are done – after that there’s just graphics, data and cosmetic code to do. There aren’t any screenshots just yet because the backgrounds have been “donated” by another project for testing and there are only a couple of specifically created sprites to date.
This exercise hasn’t changed my opinion of developing in a monitor; if the assembler is a word processor, using a monitor is akin to reverting to a manual typewriter – yes, with some skill it’s possible to be incredibly creative with either, but with the more primitive choice a significant amount of time will be spent working around the shortfalls of the environment.
