Zub Archive

Zub Sprite

Zub was a pretty sparse and empty game. We choose to spend the limited resources we had (both development time and RAM) on making a great main character, so even if there wasn't that much to the rest of the game the player would enjoy jumping around as Zub. John had written a cool 'sprite editor' on the Spectrum, which was better than any other tool available at the time, and I made good use of this creating quite a lot of frames of animation (by the standards of the day) for Zub. We even lavished 5 frames on a death sequence, which was very extravagant!

John also spent a lot of time working on the 'feel' of Zub, making sure it felt nice to jump around, to walk, etc. This was virtually unheard of at the time. There were only a few weeks allocated to program the whole game, so this would be broken down into the minimum time required for each essential programming task; get character walking - half a day, get character jumping - half a day, get character colliding with floor and platforms - half a day, get character colliding with vertical walls - half a day, etc. John spent two or three days messing with the variables controlling gravity and inertia, movement speed and jump height, animation speed and frame pauses, until he felt that it was satisfying to control Zub. For this he got into a lot of trouble for wasting time, making the project late, and losing money.

Sprites for 2D video games, both then and today, tend to be drawn facing in one direction. When the sprite needs to face in the opposite direction the sprite is 'flipped' in the x or y axis, using the same data but with the pixels drawn on screen in a different order. Some wag in the Binary Design office pointed out that as Zub was drawn holding his gun in his left hand, when he was flipped he then appeared to be holding his gun in his right hand. We were annoyed at the inconsistency of this, so I drew a little two frame 'flip' animation where Zub appears to pass the gun from his left hand to his right as he switches direction. I thought I was so clever!

10 Planets

The plot of Zub involved navigating through 10 different planets to find the lost Green Eye of Zub. We didn't have the time or resources to create many differences between each planet - they were all essentially the same, a floor, a series of platforms with three exits, and some baddies. What we did was draw a different floor and platform graphic for each planet, and a unique baddie. I think we originally planned to make each baddie behave differently, and have some unique gameplay, but there just wasn't time. John had already 'wasted' about three days on the main character's play control, so there was no way we'd get to spend time making each baddie play differently once the scheduled half day on baddie movement code had been spent.

I think its really interesting to see just how little data we had to make do with on a 48K machine. Each of the 10 planets was allocated just 56 bytes (yes, bytes!) for the background graphic data (32 bytes for the floor pattern, and 24 bytes for the platform), and 360 bytes for the local baddie (72 bytes per frame of animation). Even that took up just over 4K, a significant chunk of available RAM.

We'd lavished a lot of RAM on the main character's animation, and had some unusually large graphics on the side panel, so Zub was a little bit more sparse in-game than most games at the time, but these numbers must be mind bogglingly small to anyone who's messed around creating graphics files in Photoshop or MS Paint. Go on, have a look at the sizes of PC graphics files.

My inexperience as a video game artist is well illustrated here. I drew 5 frames of animation for each baddie, 4 of which formed the main animation. There are lots of things you can do with 4 animation frames; you can cycle 1, 2, 3, 4, 1, 2, 3, 4, etc., or you can ping-pong 1, 2, 3, 4, 3, 2, 1 etc., or you can have a two frame animation in one situation, and a different two frame animation in another. I wanted to use all these techniques as I designed the baddies. Most of the baddies cycle, but #3 and #6 are supposed to ping-pong, #8 was supposed to cycle through the first 3 frames then blow up using the last frame when it got close, and #10 was supposed to use the first two frames flying towards you, and last two as if flew away, after dropping a bomb.

My inexperience was expecting all these different animation / behaviours to actually get programmed! John got the first baddie working with a 4 frame cycle, then there was no time left to spend on exceptions or alternate versions of the code for every other level. In fact, there might not have even been enough RAM for more code! As a result some of the baddies looked really bad - #8 especially so as the 'zap' frame kept flashing up flipped horizontally and unreadable half the time. Never put text in graphics!

I think I originally intended the 5th frame to be a 'flip' frame for when the baddie changed direction in flight, and we'd have either some separate animation, or some other explosion effect for when the baddies died, but lack of time and RAM meant this wasn't possible, so John used the 'flip' animation frame as the 'death' frame.

Anatomy of a Zub

We treated ourselves to a sizable chunk for RAM for these large versions of the Zub sprite for the cool and original front-end. We re-used the first and last frames for the in-game health indicator, and for the end of game screen, but mainly we wanted a great looking intro sequence with Zub being built up from a skeleton to a genetically engineered fighting machine.

This was the first completely original game we'd developed together and I think we naively thought that all we needed to do was make a great character, people would love it, and then this would become the first in an ongoing series of Zub games.

In fact, we probably spent more time and energy on the Zub character than on the game itself, which was a mistake.

We made a tiny font (3 pixels wide!) and John programmed a simulation of what we imagined 'windows' systems looked like on fancy high-end computers. We'd never seen anything like this in real life, probably only in movies, or in a feature on the 'Eliza' in PCW magazine.

Coding fancy stuff like this wasn't accommodated in the schedules at Binary Design at all, so this was the kind of stuff John would program himself at home, in the evenings or at weekends, completely unpaid. It was a bit of fun, and we hoped it would make our games a little bit better, and stamp a little bit of our personality on them.

Zub 128K

Right at the end of development our boss came in to tell us that Mastertronic wanted to do a 128K version of Zub, to help sell the game on the new 128K version of the Spectrum. We had to come up with something which made use of this extra memory. We already had Lightfarce (which had been written as part of a secret competition between the programmers at Binary Design to see if they could each write a complete game in a day) which we could stick in as an 'easter egg', but we needed something 'proper', so we came up with a little James Bond style movie credit sequence at the beginning, for which I drew a large animated version of Zub in a tuxedo, and a large font.

It was really weird going from counting every single byte to squeeze a full game into around 40K, so suddenly having 64K to fill up with anything you like. We probably still only had about a day to add the 128K enhancements, so the extra credit sequence wasn't particularly polished or ambitious. We'd do better with the 128K intro sequence on our next game - Amaurote.

This screen, which was part of the 128k intro sequence, illustrates just how pressured for time we were.

The game was called Zob for most if its development life. Then, just as we were finished, our boss got a frantic call from Ron Harris at Mastertronic demanding to know why we were f*cking him about. Apparently he'd just come from a meeting with his French distributors who'd demanded that Zob be removed from the sales list. It turns out that Zob is some French slang word for penis. We were of course delighted by this unexpected bonus, but Mastertronic demanded we change the title immediately. The whole game was completely finished at this point, so we had so scramble around for the easiest possible change, and Zob to Zub was going to be the least work. I was able to slightly re-draw the loading screen and in-game logo on the panel, but mustn't have had time to redraw the logo on the credit sequence, so John just bodged a couple of paper black / ink black attribute squares over the top of the 'O' in this little logo. We probably did all the changes to the graphics, text and loading screens, then remastered the game and ordered a courier to bike the new cassette to London, in about an hour.

Zub Font and miscellany

» Notes on the font can be found on the Bitmap Fonts page.

I was really pleased with these control panels at the time, even though they look rubbish now. I loved the idea of high-tech computer-type stuff looking broken and bent, rather than sleek and perfect, and the idea of looking underneath the skin or the surface of something to see the hidden workings below. I have incredibly vivid memories of those stickers which came free with issue 2 of 2000ad comic, which were little panels of circuitry and wiring which you could stick on your arm to make it look like you were the bionic man and you'd left one of your maintenance panels open by mistake.

Long after the stickers had run out I used to draw little panels of circuitry on my forearm in biro at school, then try to slyly let my shirt slip up my arm in the hope that my school friends would notice and secretly think I was a robot...

The first four frames here are the Green Eye of Zub - the goal of the game (well, only half way through the game, as the persistent player would discover). The item below is the 'power pill' bonus item. We planned to have a whole system of different power-ups, which would be items like this one floating around on each planet, giving Zub different abilities, acting as smart bombs, or adding health etc, and generally making Zub into a more finished-off game. We just didn't have the time to put these in though, and in the end John bodged a screen in at the end of each planet where you played a little game to decide whether you got the 5%, 10% or 20% health power pill (rather like the little 'bonus chance' mini-games in some Mario games), which was probably coded in desperation on the last day of development.

Zub Loading Screens

» Notes on the loading screens can be found on the Loading Screens Gallery page.

Amstrad Graphics

In light of the very limited RAM space we had to work in on 8-bit home computers, it's interesting to compare the Spectrum and Amstrad versions of the same game, as the machines were pretty similar in internal architecture. The Spectrum had 48K RAM, but the screen (256 * 192 pixels, 1 bit per pixel) took around 6K or so, and with other bits of system stuff reserved there was around 40K free for the game to use. The Amstrad had a whopping 64K RAM, but the screen was a fair bit larger, and had 4 colour graphics, so the screen took up something like 16K (320 * 200 pixels, 2 bits per pixel), and with system stuff reserved there was probably only about 44K free.

That's still slightly more than the Spectrum, right? Wrong! All the in-game graphics took twice the RAM because 2 bits were required for every pixel, rather than 1 bit on the Spectrum. By doubling the size of all graphics, in more or less the same amount of free RAM, the Amstrad version of a Spectrum game (where the Spectrum was the lead version, as it usually was) always required some drastic cuts to fit in RAM. The perception was that the machines were more or less the same, or that the Amstrad was slightly better, so we had to try and make the cuts as close to invisible as possible.

Here you can see that we cut out about 30% of the animation frames for the main character. This was a shame as Zub's animation was the main charm of the game. We wanted to keep a unique baddie for each planet, and as we could change the colour palette for each planet we decided it would be fairly painless ditch the unique floor and platform graphics and just use the first planet's floor recoloured for the other nine planets. Nobody would notice, surely?

About half of the baddie sprites are re-coloured versions of the Spectrum ones, but the other half are unique to the Amstrad version. I can't imagine why I did this, especially as the new Amstrad ones look like Spectrum rejects. I've no idea what I was thinking with #9 - was he supposed to land on the floor and walk towards you? He looks like something out of the first issue of Viz comic.

Zub Cover Art

While John was working for free at home writing the Zub front end, I was also spending my spare time trying to contribute more to the game. I drew this layout sketch intending it to be the design for the game's cassette inlay, again naively thinking all I needed to do was come up with something good and it would be used. Of course as developer we had nothing to do with the publishing side of things, where cover artwork was commissioned, so nothing happened as far as me doing the cover, and I used the sketch as the basis for the loading screen instead.

We were horrified to see the actual cover when the game was released - there was a crappy drawing of a stubby Boba-Fett there instead of our lovingly designed Zub character! I shouldn't be too hard on the cover artist. He was probably paid peanuts and given about a day to paint the cover.

I should have just done a full cover painting myself, for free, and given it to Mastertronic. That would have been the only way to get the character on the cover. We were starting to realise that working in a factory like Binary Design, knocking out budget games was probably not the best environment to try and start new video game franchises!

Zub in 3D

In the late 90s our Zub character was briefly resurrected for an internal tech-demo at Zed Two. John had come up with a clever idea for a game engine on the N64, called Zed Space, which was based on rendered backgrounds created by the N64 itself, with models being added and removed from the background by the engine and turning into live interactive polygon objects, rather like a Resident Evil or Final Fantasy VII rendered background, but with the ability to pick up and move any part of the background and fully interact with it. Zed Space is another story, but for the playable tech demo we wrote we needed an animated character taking the smallest possible number of polygons.

I decided to build a 3D version of Zub for the demo, and for reasons I can't remember now (I think we wanted quite a few of them moving around on the screen at once) I had to try and make the character model out of only 100 polygons, which most 3D artists will tell you isn't really possible.

I managed it by using the cheapo trick of substituting circular 'sprites' - triangles mapped with an alpha channeled circle texture which always faced the camera, like the big bomb boss early on in Mario 64 - for tricky round bits of the model (shown as polygon spheres in the render above). As a square sprite these should only take 2 triangles each, but I think I pushed it a bit further and made them out of single triangles, with the circle bitmap mapped to the centre of the triangle with transparent space around it. I used these single triangle sprites for the head, two eyes, elbows, knees and hands (9 triangles in total) - the joints hid the parts of the model where the polygons didn't join up properly. I then made the limbs out of simple pyramids (4 triangles each), then a simple two section body (25 triangles), fingers and thumbs (9 triangles per hand), and simple 3 section feet (14 triangles each). The result was pretty ropey, but it animated surprisingly well, was recognisably Zub, and took around 110 triangles - just short of my target!

The future

Although Zub is fondly remembered by some, that fact that we never got to properly complete the game we were designing makes Zub feel like unfinished business to us. What we hope to do at some point in the future is create a new game; an update or 're-imagining' of what we were trying to achieve with Zub on the Spectrum, but built from scratch for modern hardware, and designed using the skills and knowledge we've acquired since our first collaboration twenty years ago. We'll reclaim the original title John came up with - Zob - and who knows, maybe we'll finally get to see the first in that series of Zob games we were dreaming of all those years ago?

Zub-like aliens as enemies were the first idea which popped into my head when John and I started discussing ideas for a single player campaign version of Naked War, and after publishing this little sketch on the Naked War Chronicles page I received a request for a proper Zub drawing from a fan of the original game.

Perhaps its appropriate to reproduce it here to finish off this archive: