The start of a new year seems like a good time to reevaluate some things. Even if we are only dealing with human numbering and measurements of arbitrary periods of time, it's still a good excuse for reflection. Although some deep introspection may be required at this time, this article is only going to deal with something a bit less profound.
Around this time last year, I took a closer look at a computer game from my teenage years and liked what I saw. The game itself was Clogger by Impact Software, released in 1988, just too late in the commercial lifetime of the Acorn 8 bit computers to be very influential on those platforms.
The game is interesting in a number of ways that passed me by when I played a one level demo of it on a friend's BBC Micro all those years ago, probably because I was jaded by all the Repton sequels and tile-based puzzle games that Superior Software released in the mid-to-late 80s on the Acorn Electron and its sister machine.
Clogger is a puzzle game, both explicitly in that each level features a jigsaw puzzle that you have to put together, and also in that you need to figure out how to get the pieces to the part of the level where it needs to be assembled. For a puzzle game, however, Clogger is surprisingly fast to play, and only slightly slower on the Electron than on the BBC Micro.
One of the features of the game that I missed initially is its use of colour, probably because I had assumed that the BBC Micro version of the game ran in MODE 2, an eight colour display mode. However, both versions of Clogger run in MODE 5, a four colour display mode. Clever uses of dithering and adjacent areas with different colours trick the brain into seeing more colours on screen than there really are. This works even better when the screen is scrolling because it is difficult to focus on the fine details of the graphics when they are moving around.
The positioning of pixels of different colour has an effect on the way the player perceives some of those pixels. When two colours are quite similar, dithering can give the overall effect of mixing those colours together, but even when the pattern is quite course, as with blue and green, the effect is to change the way the green pixels are perceived. When I look at the sprites used for the cakes, I am tricked into seeing cyan pixels instead of green pixels in the areas where they are combined with blue pixels – this effect is also visible in the soles of the boots on the title screen. Another instance of this can be seen where red and blue pixels are placed next to each other. This is used to good effect on the title screen where the foreground is filled using red-blue dithering, but it also works very well for the wall sprites in the screenshot on the right – they look magenta, but are really red bricks separated by blue mortar.
Scrolling is really very quick and quite smooth for a game on the Electron. I don't know if the BBC Micro version uses hardware scrolling but I wouldn't be surprised if it simply uses the same software scrolling routines as the Electron version. Clogger seems to try and do the least amount of work in order to achieve the effect of scrolling. I suspect that it only draws the changes to the 4 × 8 pixel subtiles needed to update the screen.
Since many tiles contain repeating patterns of subtiles, there is often not much on the screen to change when the player's character moves around the level. The picture on the left shows a section of the second level where the screen is basically static, apart from the animation of the character, as it moves along a long passageway in a maze-like section of the level.
Although the scrolling is not very smooth by the standards of other games, or on other systems with dedicated graphics hardware, the large sprites make up for this. Horizontal scrolling in steps of 4 pixels and vertical steps of 8 pixels hardly seem to matter when the sprites are 16 × 32 pixels in size. No doubt the routines to animate objects were made simpler by the lack of independently moving objects in the game – you can push objects around, but there aren't any monsters to keep track of.
Sound in the game is minimal but atmospheric, with repetitive low pitch “thuds” as the character's boots hit the ground. The BBC Micro version also has some very nice music.
The game is very forgiving, at least at the start, giving the player objects to experiment with that they don't really need to use. The first level looks a lot more daunting than it actually is. It is also very generous with the time limit, at least on the easy levels. This is partly because the main collectable items – cakes – give a time bonus when they are collected, giving the player a reason to seek them out. This went against the trend in the Repton series of games where it became necessary to collect almost everything in order to complete each level.
One feature that is a bit less forgiving is the choice of sprites for the spring tiles – these look almost identical, and it doesn't help that they are made up of blue pixels on a black background. Another minor inconvenience is the lack of feedback the player gets when they have placed a puzzle piece in the correct location. Many of the pieces look very similar and it takes time to flip back and forth from the picture screen to the game, so you might want to know when the piece is in position, perhaps with a visual cue or sound effect. The status screen will increment the counter for correctly placed pieces, so it's not as if the player would be cheating by getting this information.
There are some very nice touches in the game. Since there is a time limit on each level, the game keeps track of time except when you are viewing the status screen. When you are viewing the map or picture screen, the counter keeps on ticking down; there is even a counter on the picture screen to remind you that you need to get a move on. It's a bit of a shame that there's a delay when you return to the game – it makes it a bit tiresome to try and identify which pieces you encounter. It would also have been nice if the picture screen showed which pieces are already in place. Still, these are all nice-to-have extras rather than missing features. An undo last move feature would have been very nice!
As I said above, I had revisited this game at the start of last year, made a simple level viewer and put it aside. It was pretty much a one-to-two evening project that I worked on fairly intensively as I tried to discover which files contained the sprites and level data, and how the puzzle pieces were defined. I made a note that the way the sprites are stored is similar to that used in the first two Repton games – perhaps this was because I had been looking at the way Repton 2 stores its puzzle pieces. Beyond a passing interest in viewing the levels, I wasn't too interested in digging much deeper into the game.
At the start of this year I noticed that there was renewed interest in the editor I wrote. I'm never too sure if anyone will get anything out of these reverse engineering efforts, so I was quite surprised that someone replied to my old message. I was asked whether it would be possible to use the editor to design new levels. It seemed possible, but I hadn't written any code to modify the underlying data from the game, and I still didn't know some basic things about the levels: I didn't know where the level passwords were stored or how the game knew when puzzle pieces were positioned correctly.
The location of the passwords was uncovered fairly easily: I noticed that each of the level files – SLIPPER, BRUSHES, ARTIST and PAINT – started with a character that was the same as the first character in the file name. Since I suspected that the start of each file contained the passwords, and since it was common to use an EOR operation to scramble secrets in games, I eventually figured out that the game would use a counter beginning at zero to unscramble the passwords.
The location of the data containing the target coordinates of the puzzle pieces was easy to find in hindsight, but took a bit of work to establish. Located just after the passwords in each level file, the section of bytes containing the coordinates is one of the parts of the file that differed between level files and whose purpose I hadn't determined until that point. It didn't help that I had been looking for a single set of coordinates for each level – after all, if the puzzle is always assembled as a single block of 7 × 3 pieces, why would it need more than one pair of coordinates to describe it? In the end, it's probably a combination of convenience and efficiency that the target coordinates are all stored in a array, though I don't know why each pair of coordinates is packed into 10 bits then stored in a pair of bytes when each coordinate could have been stored in a separate byte. Perhaps each pair of coordinates is treated as the offset into the level data.
With the new information at hand, the editor has had a couple more days spent on it. It's now possible to create new sets of levels, though they need to keep their original file names, and the passwords for the first level in each set must remain the same. It's also possible to change the designs of the pictures used, so those that feel they can improve on the pixel art of the original can try their hand at creating 28 × 12 block miniature works of art.
The editor can be found on my projects page. Maybe we'll see new sets of levels being produced – perhaps next year!
Categories: Free Software, Retro
Copyright © 2016 David Boddie
Published: 2016-01-09 00:00:00 UTC
Last updated: 2016-10-14 11:14:08 UTC
This document is licensed under the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International license.