Fat Worm Blows a Sparky (click to play)

Before I went to university and saw the wider world, my only hobby was programming computer games in an out of school hours. In fact, that's just about all I did. Games were the only things worth writing, and assembly or machine code was the only option you had to make anything good. I knew the entire 6502 microprocessor instruction set off by heart. This let me poke in programs into the second cassette buffer of the Commodore Pet. My little programs often made the screen scroll in a funny way and took one lunch hour to write.

Later on, with a friend, I wrote three games on the BBC Micro. Whatever you say about this machine, it was the tops for programmer friendliness. There was even a machine code assembler built into the BASIC language interpreter which you could open with just a square bracket. How radical is that? Normally you have to find, buy, load, and learn how to use a special program to perform this advanced task. Machine and assembly code is for experts, you see. This throws up a considerable barrier for new people who can't go through this process if they don't know what assembly code is. And you can't find out what it is, or what it does, unless you have access to it. So, having no barriers to programming, and encouraging curiosity is vital if fourteen year olds, for example, are to discover that they are interested in it, and can do it well.

After A-levels, and before university, I had did one long stretch down in Taunton attempting to program my magnum opus. Everyone else was getting rich on computer games, and I had an idea for a very ambitious piece of graphics. I was going to make my fortune at last.

I started writing the graphics routines (with no idea about the game) on of the Amstrad computers just as it was was going out of fashion. (There had been a massive proliferation of microcomputers at the time.) Some people write novels by just writing with no idea of where it's going to end. And sometimes this works to get the creativeness flowing. Without planning, you can get yourself into a real fix from which only a stroke of genius lets you escape. But there's a good chance that you do get stuck properly and it doesn't work out.

The idea of the overhead graphics with its building blocks, wedges, and centred perspective view came from sitting at the top of the World Trade Centre building and looking down on the streets of New York.

The game protagonist was, of course, going to be a car. It's always a car. Or a man. Overhead views of men don't really work out, and I am awful at drawings. I had a car all working, made up of a dozen polygons. The picture was cached in a little buffer and re-rendered whenever the car changed directions or drove up a slope. The resulting frame rate was getting a little bit too slow.

I panicked. I had got this wonderful polygon renderer, specially tuned to making trapeziums (the shape of all block faces that are oriented with the sides of the screen), and I had just implemented the general quadrilateral case, to render the little panels of the car, but I could only make about a dozen polygons per frame if I wanted a something better than one picture per second!

So I limited myself to four polygons for the protagonist. And so was born, out of desperation, the tapeworm. I should have put eyes on it. Except tapeworms don't have eyes.

At some point I ported all my work over to the ZX Spectrum, and got the screen rendering going all over again. I'm hopeless at hardware. The ZX Spectrum is not adequate for development, so I had to build something to download machine code into the computer through some port interface. I'm hopeless at these things, and burnt myself with the soldering iron many times while building the socket. The computers in the Durell offices were wired up to some sort of noisy hard disk in the corner that had two megabytes of memory on it. That was all. Towards the end of Fat Worm's development it took 20 minutes to compile (assemble) the code, and another four to download it, only to find that you had left some tiny bug in and had to do it all over again. My work was pipelined. I was constantly programming something new, at the same time as debugging something older, while waiting for it to compile.

You have to remember that I was working about twelve hours a day or more, including weekends. For the final month I worked a night shift to avoid distraction from other people. Working nights is not healthy. My deadline was the start of University in October. It was final. In university at the start you don't time or intellectual energy for other projects.

So, I had a worm, I had some blocks, but no game. Easy. Games all have the same default design since the days of PacMan: collect stuff and run away from monsters, get killed if they touch you. And so it went. It was a war of attrition. It was a chore rather than an entertaining diversion. As you get further, and you have more to lose, the monsters get tougher and it gets harder. They try to beat you out before you get to the end. This wouldn't be so bad if there had been levels, floors above the starting point which you don't fall below once you have reached them. Being chucked right out to the beginning is not particularly fair or friendly. How many people I have frustrated due to my insufficient understanding of game-play, I do not know.

Game-play is not something many of us kids who did the programming knew about. All we wanted was cool graphics. We had suffered for hours and hours making these programs, so it seemed logical that the players ought to suffer too.

There should always be a games designer, like an editor, who is separate to the games programmer. They'd have a difficult job because they would have to be polite because programmers develop a bit of an ego. The get understandably possessive and proud of their work.

But it could have been easy to point out, logically, what was going wrong with games design at the time. The process had been going on for years. Whenever a game came out, and got popular (people would buy anything that looked cool), you'd get all the magazine reviews (bought and paid for, might I add).

Then a couple months later there'd be the reader's letters.

These letters contained the pokes, hacks, slight tweaks to the program code here and there to make the game-play loads better. These were the cheats (infinite lives, unlimited ammunition, and so forth) that people had to do in order to make it fun. I think of them as the retrospective fixes. If the guys who decoded and worked out these fixes ever got in touch with the software companies in time, and told them what to put in, we could have had games that were playable from the start.

What would I know?

I went to university and studied mathematics. I started coding up a new game for a few months, unable to break the habit, and then, suddenly, over the period of about three days, lost interest. You don't normally notice changes in yourself, but this was so striking that I could tell instantly that something had realigned in my brain. Maybe it was all the pure mathematics I was learning. It does change the way you think.

I got some money from this game, but not riches. It was just enough to keep me out of debt in university. This gives you an edge, staying out of debt, which is why the system tries so damn hard to get people into debt, to make them desperate to take and keep jobs, whatever comes along, and whoever is their manager. If people are not in debt, they start looking for what they want. I got into hang-gliding for a while at university, because I felt I could afford it. I should have bought a better glider, though. So many hours wasted not flying properly.

I was in university for seven years, the last three doing a PhD in Bristol. I never programmed a computer until the last year of my degree when I thought I'd really have to pick up a trade, and went on a course to learn the C programming language (continuing in mathematics looked way too hard to me). During this time there had been the rise of the PC, probably the most un-programmer-friendly computer in the known universe. The barriers to making any program at all on that beast, let alone do any graphics, are immense. You basically have to work in a company if you are to stand a chance of getting the support to find out how to do it. This keeps all the children and other outsiders from learning how do things, as they did during the era of the BBC Micro. They have to make do with paying for computer games and playing them. There was no outlet for creative participation.

When I finished university I had a job lined up to go write computer games up in Manchester, but the company folded before they took me on. I then got taken up by an employment agency and hired by a CADCAM company in Cambridge as a support engineer, a most inappropriate job because I knew nothing about hardware and my soldering skills had not improved. Fortunately, I was able to manoeuver my way into the programming side of the business, which was at least something I could do. I therefore utterly refute the idea that company managers are at all wise in their hiring policies. If they have any success, it's because they got lucky, and the people worked it out for themselves once they got through the barrier.

After about a year of this tedious programming, I tried again to get back into the computer games business. It was booming all over England, and there was a shortage of qualified programmers, so I was told. I went to dozens of interviews. I didn't make it through the first interview once and was never paid costs. I got rejected because I was not qualified, apparently. Not sure how they worked that out in a twenty minute interview. Maybe they didn't like their first impression of my personality, or something, although that's not got much to do with the job of programming which, let's face it, involves mostly staring at a screen and typing. I was out of touch and out of practice for working within the tight parameters of games software. I didn't know about modern games design. However, this didn't make sense because every computer game written in those (and these) days is done by a team, half of whom are programmers, and half of whom are games designers. I'd do the programming half, not the design.

So it goes.

Not that I am particularly grumpy about this, but turning people down who learnt to hand code machine code for computer games since they were thirteen is just plain wrong and stupid -- and no mistake. But this is the problem with an industry that has professionalized and got loads of managers and companies who build a barrier against people who may try their hand out and potentially prove themselves. These guys get in there to get after the money, they put themselves in charge, they make employment contracts with people, and they make decisions based on their gut instincts. This is all very well, except that their gut instincts are untrained and unaccountable. They never find out whether they are wrong. They don't care if they are wrong. Nowhere in the system can they follow up on their decisions to check whether the guy they have turned down was actually talented or not. It stinks.

What's even more irritating is that the default interpretation is that the guy who turned you down at the interview is always right, and you must have done something wrong to annoy them. So? Is that my problem? I thought they were looking for programmers. They are supposed to be hiring programmers, not some professional interviewee candidate who is going to work undercover to infiltrate other companies through their interview processes. The fact that I did go on to work for another eight years in my old company (after failing to get away), and I contributed heavily to a totally new application for generating instructions for machine tools, about which I know nothing, is a sign of someone who might have done well.

I am not annoyed per se by the fact that I failed to re-enter the computer games industry, in which I would have now been locked for life (I'm glad I didn't, as it's a silly thing to fritter your life away on). I am grievous about jobs an job interviews. There ain't no justice.

Work, and access to the tools of work, should be available to everyone at all time, as were computers, the necessary software tools, and publishers willing to buy any half-baked game production that some kid made in his back bedroom, and sell it. When business develops to a point where there is a complete stranglehold by idiot managers who are in a position never to proven wrong, something is lost from life. For example, my career. But, at least they can get rich in spite of having no talent, which is why they are there, forming a facade like a steel wall, plugging every hole against outsiders getting in, except on their terms.

Not that I have anything against the managing profession. Managing is an important skill which, when properly done, works wonders. However, under no circumstance should managers ever be allowed to deny access to work that you can do.

Stop ranting

Sorry. Bad habit. I often talk to myself.

Somewhere, there are a lot of people to whom the ZX Spectrum is a source of nostalgia. Although it is dead, it is still cool. These guys have archived every article on every page of every trashy magazine issue which serviced the market in those days. The games themselves have been recorded, catalogued, and put on display by numerous collectors with the pride of amateur zoologists in the field. It was a long time ago when I mislaid the last copy of my work, before I wised up to how vitally important was source code.

The magazines, when I look back at them, bear a direct relationship to those from the golden age of sci-fi pulps in the 1930s and 40s, with their lurid covers and boundless optimism.

Because it is dead, it can be collected. These microcomputers and everything on them fall out into the public domain of common ownership, where people who are interested can sift through the trinkets and bones of the wreckage.

These people are cool for doing all this work. I don't know what motivated them, what the shape of their community is, or where it is going.

I think... I don't know what to think. Although I can write about it (making certain things up), the memory of those days is quite vague, as though I didn't live it. In twenty years time maybe my brain cycle round and unearth all the memoriess and feelings in their full immediacy once again, and I will really, really care deeply that someone has taken the trouble to archive and collect something I had made. Who knows, it might be my only lasting imprint on the history, like a petroglygh carved in the rock ten thousand years ago by a kid one sunny afternoon that just happened to be in the right place to get sheltered from the weather and not be eroded.

All my years of slaving away, continuing to program, with far greater expertise and know-how could go straight in the trash like the architectural plans for buildings that get cancelled.

Who can tell?

Retro-computing is important because sooner or later our technology will fall back. With an economic system as large and as technically flawed as this one we are running, die-off is inevitable. If we are lucky we will retain the ability to rebuild machines as advanced as the ZX Spectrum. Software emulators are just the start. Real retro-computing, which would hold me in awe, would be a demonstration that people can fabricate components from raw materials independently of the economy, not out of scraps, and build working computers. If this is not possible, we should maintain strategic stockpiles of robust components, like seed banks, and start working on plans now.

For such computers, the value of small, efficient pieces of software will be incalculable. We may not be writing games for these future machines, since there would be work to do. However, it will be necessary to develop skilled programmers from nowhere, and children might do it if motivated by play. In the future, there will be a hell of a lot of data lying around locked up in electronic form behind layers of compression. It might be geological data, forgotten surveys conducted by no longer operative air and radar systems. Since all the superficial deposits of minerals will have been exhausted, in the future, ten thousand years in the future, post-apocolyptic humans who need to mine for metals to maintain a minimum level of technology will have to scan the data that was collected in happier times.

So it goes. So we should think of it going. So time will always pass, and the least important matters will become the most important.

Links and the rest

World of Spectum The place to go.

Fat Worm Blows a Sparky Searched on their page. Or you can put "Fat Worm Blows a Sparky" into google. You don't get very many false hits, believe it or not.

Java spectrum emulator. This is the best way to do it, because it's portable. Shows how fast computers are now that a processor emulator can be written in an interpreted language, and barely touch the power of the machine.

Durell software still lives... sort of... making financial management stuff.

Dieoff.org Economics meets ecology and physical constraints. We print money, we don't print oil which is starting to run out. There are no technological quick-fixes. The sociological invention (what our leaders like to call the cold, hard laws of economics) is going to have to give way to reality, or it will kill us.


Finally, a beautiful rendered image of the playing area of the game. Who took the time, and cared enough to let me see in full what had been punched in as numbers from a few scraps of paper in those frantic last hours before the deadline?


julian@goatchurch.org.uk.
29/3/2003 ... Julian Todd.