Previous Next

Occasionally I am asked why I bother writing Spectrum games today, when surely it would be easier writing for more modern platforms. With user-friendly development tools and languages, better sound and graphics, and extra processing power, surely one would have to be mad to spurn modern platforms in favour of an 8-bit machine. On the face of it I have to agree, it makes little sense at first.

Let us begin with a rundown of the Spectrum's hardware and how this affects a game. A standard machine has 48K of memory, but once the screen display, system variables and other workspace areas are taken into account a mere 40.5K is available to the programmer. Typically, program code is efficient, and will use 15-20% of this. Another 10-15% might be used as buffers and workspaces, and the remainder generally goes to graphics and level data.

The screen consists of a 256 x 192 pixel monochrome display with a low-resolution 32 x 24 colour cell filter, which, like the display modes of most games machines of the early 1980s, might seem restrictive, but with some thought it can be turned to an advantage.

The 'brains' of the machine, known as the processor or CPU, is relatively powerful and makes up for the lack of support that chips enjoyed by some of the Spectrum's contemporary rivals. Running at 3.54MHz, the Z80A is sophisticated for an 8-bit processor and the Spectrum programmer needs all this power for games, because the CPU has little other support.

So where do my own Spectrum games usually start? Actually, I don't really know. One might imagine that the process starts with the idea, as it is reasonable to assume that a programmer needs to know exactly what is intended before embarking on a new project.

Oddly, that is not always the case. Sometimes a trigger event will cause a series of unconnected little ideas to come together and form a bigger picture - a few beers often help here. At other times inspiration is not there at the beginning, and I find myself writing a game on-the-fly, letting the game itself drive the ideas as it develops. Either way, regular trips to the pub are the order of the day.

The main sprites are drawn early on, and are done with Metalbrain's excellent SevenUp graphics utility - a very flexible tool. Here the main characters are decided upon, and the way in which they move is determined. If, for example, a sprite is to move two pixels per frame, then that character's feet must move two pixels per frame, or the sprite will appear to be slipping on ice. Other effects might include rolling the eyes, swinging the arms or making a sprite dip one pixel in height for a couple of frames whenever its legs are fully extended.

Once the player's sprites are designed, work commences on the main game block - or 'engine' - and the program code for this is written in a form known as assembly language. This code is just a series of cryptic mnemonics representing instructions for the processor to do simple jobs such as moving a number from one place to another inside the computer's memory. Alone, these instructions are useless, but sequences of them arranged in the right way can be used to build up more complex blocks that perform useful tasks.

Next week, I'll talk to you about building blocks and hidden games that can be incorporated into 8-bit game design.