Andrew Braybrook / ST Software,
Graftgold
Added on August 30th, 2022 (2017 views)
www.c64.com?type=4&id=56
Hello, Andrew, and welcome to the interview! I cannot fully express how much I have enjoyed the games you programmed on the C64, though the number of questions in this interview may give you an idea, I fear. Let's start with where you grew up, your childhood, what your teens were like and what you did back then.
I grew up in Essex, living in a small new road with a number of similar-aged people who all attended the same small school. It was around the time of the Apollo moon landings and then progressive rock. Science, science-fiction and music were thus a major part of my interests, so my geekdom was probably already assured.
How did you first get started with computers?
I largely ignored the desk-sized computer they brought in at school. It didn't have a screen, only a printer, a keyboard and a card-reader (or ticker-tape), and a massive 1 kB of memory. It only featured in a few maths lessons. I applied for an extracurricular job as chemistry lab assistant in the 6th form and got it, which probably improved my chemistry grade and kept me away from the school's next computer: a Commodore PET that lived in the evening electronics club. The job did, however, allow me to buy an LP every week with my wages, so my music collection grew. The school expected all the pupils to go on to university, so the careers office only had a list of universities, not potential employers. I didn't fancy university: A-levels had been hard enough. Maths was getting all theoretical and complicated, chemistry didn't seem to lead to a job, and physics was just formulae and equations, so no job there either.
My dad's firm had a computer and were looking for staff, as were GEC-Marconi. I was offered both jobs after interviews and took the GEC one, where I anticipated better training as it was a bigger department.
Are you a self-taught programmer?
I liked the logic tests that I took for the interviews, and I enjoy puzzles. As it turned out, the one I took at GEC was really quite like assembler – manipulating registers to get the right answers – though I didn't twig that until much later. They spent three months teaching us COBOL and about data, which was still mostly kept on tapes at the time. Then I was unleashed upon the accounts department, to write batch programs. About 50 people shared six terminals, and we had to write our code on paper and then have some fast typists key the programs in. We would then book 15-minute sessions on a terminal to run and debug the programs. This would result in a listing which came off the printer and was delivered about every two hours.
I quickly realised that terminal time was the fastest way to debug programs, and probably started booking more than my fair share of time, flitting from one terminal to another. They each had their own booking list. I also started learning some of the other languages, like EXEC, the mainframe's equivalent of DOS command scripting, but they wouldn't let me near assembler – only the tech support team got to play with that. I could see how much faster it was than COBOL, though, and you could see how much assembler was used in each COBOL command, so I was starting to pick away at what made computers tick.
There were also some games available on the mainframe. We started playing them at lunchtime, then in the evenings. After that, I started to write some of my own in the evenings. I would quite often stay up until 10 p.m. At least I had a terminal to myself. When you logged off, it told you how much you'd spent, in pounds, in CPU time. I wondered when I'd get the bill.
So, to answer your question: I would not say I was a self-taught programmer, but I did learn assembler by myself on the Dragon 32, then the C64 and then the Motorola 68000. As long as you learn the first language well and the techniques for debugging, then moving to another language and toolset isn't so hard, although the tools do get more sophisticated and therefore take longer to master. This is not necessarily a good thing for newbies.
You started working for Steve Turner and his company ST Software in 1983. Tell me about that day. Was there even an interview, Steve being your friend and all?
We always tried to do things properly. I'd started experimenting with a machine-code plot routine in 6809 on the Dragon 32. I thought, rather naively, it could handle doing every dot of a sprite individually. It would allow me to blow up the spaceship I had drawn. I had to write it out on paper in assembler first, convert it to machine code by looking up the hex codes for the instructions, count the distances for the branches and then POKE all the codes in with a BASIC loop. I got it working too, but it was quite slow doing all the pixels separately.
Anyway, Steve and I and two other friends, another Steve and Richard, used to tour the pubs on a Friday night to play the different arcade games in town. Each pub had one machine, and they all had different titles. I don't know if they planned it that way. One evening in the summer of 1983, Steve came round to my house on a Friday evening and said: "Do you want to come and work for me?" I said: "Yes, please!", and that was it. I was still living at home, I took a 50% pay cut to do it, and it got me out of my job at GEC, which because of politically motivated changes was becoming an unhappy place anyway and was ultimately shut down. Steve had written his first two games, got a publishing deal, and was making some money but finding it a bit of a grind working alone. We put two desks in his dining room and set to work. We decided it would be best to diversify and not work on the same platform, so I started on the Dragon 32.
Was getting into the games business something you wanted to do at an early stage?
I had enjoyed writing my own games on the IBM mainframe, and perhaps more importantly, I enjoyed watching people play those games. The last one I wrote was a six-player game that we used to play together after work. We spent many Sundays together playing C64 games, and that continued once I started writing for the C64, so I had my own test team and critique group. It was a lot of fun and didn't feel like a job at all. I got paid to play games! We had a can-do attitude and wrote our own tools. I suppose the machines were simple and well-documented, so it wasn't too hard. There was no internet back then, you couldn't just ask Google. We made our own video leads and parallel port leads and wrote our own communications software, whatever we needed.
What was your first task when you joined Steve at ST Software?
My first task was to convert Steve's first Spectrum game, 3D Space Wars, to the Dragon 32. It was written for the ZX Spectrum 16K, so I knew I had spare RAM, and with a full listing of the original – and the author sitting next to me – it wasn't so tough. It only took me about six weeks.
I then spent a bit of time writing a graphics editor, as it was rather slow drawing all the graphics on graph paper and then converting them to hexadecimal. I wasn't sure if I was allowed to do such things, so I kept quiet about it.
I also wrote a little tool called ABMon which allowed me to scroll through memory and look at the variables and, if necessary, change them, one byte at a time. That made it easier to fix things on the fly. With an assembly time of 15 minutes, and no real debugger, we wrote down all the bugs we found in a test session and tried to fix them all.
When ST Software changed its name to Graftgold, was it still the same company, just with a more professional name?
It was about accounting. We were earning enough in royalties that we had to change from a private company to a limited one. It actually protected Steve more, if anything went wrong, and made sure we got the tax sorted out.
At what point did the company start to employ other people?
We met up with Gary Foreman, because he had sent us his game Orion and he lived in Colchester, which wasn't far from us. We went to see him, and he eventually became our third member. That would have been around 1987. At the same time, we were joined by John Cumming and Dominic Robinson. We started working for Telecomsoft, and that helped us to expand.
Did you own a stake in ST Software and/or Graftgold?
The subject never really came up, it was all Steve's company because he started it. I was on a royalty arrangement, so I was sharing in the success, and that worked fine for us.
Describe the atmosphere at ST Software and Graftgold. Did it change much in the years you were there?
Every person changed the company a little bit. Some made it better, some made it worse. When you're half the company, it's easier to influence it than when you're a twelfth, that's for sure. The biggest change, though, was really when we switched from being self-funded to getting advances. Once you cross that line, you lose some say over what goes on, because the publisher starts to take control. A number of titles we wrote never came out because the publisher decided not to take the risk, and that cut off any royalties we might have got.
We really got squeezed later on, and the pressure on Steve to pay the wages every month took its toll. It's the same with any business, really, you gain momentum but you then have to keep that momentum going. You never get to take a breather.
How did you first get started working on the C64?
By the time I'd finished converting Steve's first three Spectrum games to the Dragon 32, I had caught him up. He was still writing the next one, Avalon, which was going to be a 48 kB game, and so all of a sudden, the Dragon 32 wasn't big enough. Also, Dragon 32 sales were dropping off and the C64 was clearly taking over, so we decided that I should switch to the C64. Having just written Lunattack, I fancied converting that to the C64 just as a way of getting used to writing in a new assembler language. I knew that character mode was really where the C64 excelled, but this was a good way in and wouldn't take too long.
Why was (is!) the C64 such a great machine?
I believe this is to do with the fact that it had a graphics chip to do character mode, which allowed us to use indirection to get some nice effects, plus reasonably sized sprites and plenty of RAM. I did eventually get to use all 64 kB, and it had a nice three-channel sound chip. Did I mention the smooth scrolling? All these things were well ahead of the game, and the programming environment is right there from the moment you switch it on. The documentation in the Programmer's Handbook was pretty much complete, too. The C64 could do a lot of tricks that the arcade machines were doing, but with more of everything, and it was leading the way.
What attracted you to the C64 as a development platform?
All of the above, plus the fact that I could already see what people were doing with it. The CPU was a little slower than I would have liked. It only had four registers, so it was easy to learn. It seemed a no-brainer that it was the superior machine at the time, until the 16-bit machines came along. Actually, there are probably a fair few C64 games that you still couldn't do on an Amiga. Mine would probably all have made it across in some form. We did two of them.
Lunattack was your first game on the C64 and your only conversion from another platform. What was it like to convert a game from the Spectrum, and why didn't we see any other conversions to the C64 from you?
Converting Lunattack for the second time went fine. I knew the game architecture, and the game worked, so there was no design pressure at all, and I was free to add extras. Some people only found the map feature very recently, so I hear, which is a bit of a shame, as it doesn't half help to see where you're going!
I wanted to do my own thing after that and use the C64 for what it was good at. The Spectrum games that Steve was doing were more bitmap-orientated and not suited to the C64. He did convert his own game later on, just to prove me wrong.
When Gribbly's Day Out was released in 1985, it certainly raised your profile. What can you tell me about the development of the game? In making it a non-violent game, was the intention perhaps to stand out from the many other games being released at that time?
Gribbly's was certainly intended more as a search-and-rescue kind of game. I wasn't thinking so much about whether it would be different, I just had some ideas about how to use character animation to do the barriers and the Gribblets. I also used sprite-to-sprite collision detection and sprite-to-background collision detection for the only time ever. I was keen to use as many hardware features as possible. I even used the two clocks on the interface chips, also for the first and almost only time, one as a real clock and one for game time.
Did you have design meetings before and during development, in order to plan the game properly, or did you just go ahead with the programming once you had an idea of the kind of game you wanted to do?
The way I work involves coding something and then seeing what comes out of it. That way, you can hone something over time. If you try to design something so complex up front, how do you know it will work properly? I suspect big companies can just do that and then pick out the designs that work, but in a small company, everything has to work. I used to let the guys try out what I'd written most weeks. I was also trying to make them laugh with the animation. They'd make comments and suggestions, which I would then take on board.
What do you think is special about the game from a programming point of view?
I wanted the game to look after more objects than the eight sprites available. It's running Gribbly, up to two bubbles, eight Gribblets, 16 Meanies and Seon. It has to assign five sprites to the first five objects that want to be on-screen, and deal with any extras, which of course you don't see because they're arriving from off-screen. The Gribblets are characters, except when they jump, so if the screen is already busy with five objects, then none will jump. The walkers turn around and walk away from the screen.
The sequence you see the screens in is also controlled by how well you play, giving the game a less linear feel. It always saves the last level for the end, but it opens up more levels, the better you do.
You are credited for the graphics in your games, which I think is pretty amazing. Normally, you either code or you draw graphics. Were you always into drawing graphics, or did you do it out of necessity because no artist was available or because you felt you needed the graphics RIGHT NOW?
I needed something to do while the C64 was compiling the code on the Commodore disk drive. It used to take 30 minutes to build the code, and that was if there were no errors. It teaches you to code carefully! I had a second C64 for testing on or doing graphics. Four colours doesn't give you too many combinations to play with, so I could manage the graphics, and that also allowed me to better integrate the graphics and the coding. Gribbly is made of separate eye and mouth graphics that are copied in, depending on what he's doing and which way he's facing.
Being a musician, how come you never got into making music for your games?
I enjoyed playing bass, but only what other people had written. There's something magic about music that I have tried, but thus far failed, to learn. Steve liked to compose, so I let him get on with it. He also did all the sound effects. I specified what I wanted, and he created them. Actually, I think he wrote the sound effects player and the music player, too.
Did you develop any programs, like sprite editors or art programs, to make life easier for you and anyone else working on Graftgold games?
My Dragon 32 two-colour graphics editor was the only editor I ever wrote. For the C64, I bought Sprite Magic and its character set counterpart. There was no need to reinvent the wheel. They did everything I needed. The C64 character sets and sprites are sufficiently regimented that you only need one format of data for each. For the 16-bit, we used proper art packages and data conversion tools that we wrote, but I did all my C64 graphics, with one or two individual exceptions, in Morpheus. It does make life easier doing it that way.
Tell me about what setup you used when programming. Did Graftgold have a development kit?
We started off coding on the machines themselves. I had a nice Dragon 32 assembler that I bought from the local computer shop. I had the Dragon disk drive, and that all worked fine. Steve was working on the Spectrum, writing machine code in hex. He can still look at a page of hex and tell you what it does in Z80. The Spectrum was a bit unstable with the 32 kB RAM pack at the back, and there were any number of machine crashes that wrecked his morning's work. It seemed to know when he was about to hit "Save".
As soon as we could, we got a PC each – with amber monitors – and started coding on those. We made parallel port leads and wrote the target software to receive the compiled code from the PC. This speeded up the development time and gave us the security of saving the code to decent media. We were still using those PCs to talk to the Amiga before we upgraded to 486 PCs in about 1990. We did also use PDS for Intensity. That was about the first time I'd had a proper debugger.
Did you use a specific assembler or were you writing your games in machine code? Compiling code back in those days could take quite some time!
I used the C64 macro assembler and the C64 disk drive for the first three games at least. The compilation time was around 30 minutes. Also, there was no capacity for comments in the code. We used to add them to printouts after we had finished. Once we got the PCs, we were able to use a proper editor, called EC, and a cross-compiler to generate the C64 code.
When you started working on a game, how much time did you usually have to finish it? Did you work towards milestones to get paid or were you paid on delivery? What about royalties on sales?
We had a finish date in mind, and in those days, it would be defined by running out of either graphics space or coding space. Even though we carried some code forwards from one game to the next, we tried to cram more in, and each game took longer than the previous one. We would only take the game round to the magazines once we thought it was ready. At that time, we were paying for our own development out of royalties from the previous games, so we didn't have to succumb to external milestones. Milestones might get you a product on time by means of starvation, but does it get you a better product? More likely, it just gets you more bugs. There were no updates in the C64 days, you had to get it right first time.
What tape loader were you using and what company mastered your games? Were you ever involved in the process?
We started off just using the standard C64 load routine. Turbo loaders were invented later, and we were sent some code as an example. We had to understand what it was doing first, we'd not gone down to that low a level before. It's a bit hazy now, but as I recall, the first turbo loader we had was one which supported running a loading program at the same time, decoding the tape on the interrupts using timers to determine the length of the peaks and troughs on the tape. The publisher had a tape replication facility, so we only had to supply a master on tape to copy. I'm really going to have to get the old games out to see what we did. I know the Heavy Metal Paradroid loader scared a lot of people because it was all fairly quiet at first, but then a firefight breaks out half-way through the load.
When Paradroid hit the market, there was no end to the praise it received. It was awarded a gold medal by Zzap!64 who gave the game a four-page review and an amazing 97% to round it off. C+VG gave it 9/10. Being your third game on the C64, that must have felt really, really good, right?!
I was of course thrilled to bits, because it put me on the map. Out of that came some awards, and I got to meet a lot of other programmers by doing articles, mainly for Zzap!64. Plus, you get all the pressure of writing the next, even better game.
The objective of Paradroid is to clear a fleet of spaceships of hostile robots by destroying them or taking them over via a mini-game. Where did the game idea come from?
Steve recently found some of the original archived documentation, albeit water-damaged. Paradroid was probably the most up-front designed game I ever did. I wrote it all on two sides of a piece of blue notepaper. Whilst it was seeded from an old COBOL game I wrote at GEC, the whole design pretty much came to me as I was walking home one evening. I wrote it all down and took it into the office the next day. The hierarchy of the robots, how they're displayed, it was all there.
Paradroid is a typical example of a title with great gameplay, and I think that's the main reason it's still enjoyable today. Did you always make sure you had plenty of time to fine-tune the games before they were sent to the duplicators?
We played the games quite a lot during testing, and were fine-tuning until the end. You can over-do that, because everyone is different, and I'm probably a below-average ability game player. Paradroid, though, did go through some last-minute control mode changes. I had two previous firing modes that involved a gun-sight that moved around the screen. It turned out to be too fiddly: it wasn't possible to hit moving targets quickly enough. I tried to simplify it, but eventually threw it out altogether. That was more coarse-tuning than fine-tuning, but it worked.
Do you think that it was mostly the puzzle elements that drew people to the game?
They're strategy elements rather than puzzle elements. You know there are going to be some big nasty robots on the cargo decks. Do you pick them up one at a time and use them to mop up the middle ones elsewhere, or start a massive firefight that you might not win? Picking up a damaged robot means you have to go and re-energise it before going into battle. There are enough elements, and differences in every game, to force you to learn to play rather than just remembering what's where. It's a simple enough concept, but there are lots of possibilities, right down to how confident you are at playing the transfer game.
How was Paradroid Competition Edition different from the original game, and what was the reason for releasing a new version of the game?
The Competition Edition of the game happened by accident. I was concerned that the game was running at 17 frames per second. It's moving the colour map and the characters, so it was never going to achieve 50 frames per second, but I got to thinking that it should be running at 25 at least. There are times when you can and can't play with the display screen or sprite positions in order to keep the view tidy – there's no double-buffering in there. So there are some timing delays to stabilise things, and I think I found one too many. I removed it, and the game ran pretty consistently at the higher speed, though it did slow again in the biggest firefights. I tweaked it a bit more and didn't re-time everything for the faster frame rate, it just went quicker! We had a second set of levels for Gribbly's Day Out as well, so I believe that a double-pack came out.
And what about Metal Edition Paradroid?
The Heavy Metal Edition came about when I was writing Morpheus. I wanted to see what a game made out of the curved metal graphics might look like. It was early days in Morpheus, and it didn't really have its own game system yet, so I did a one-for-one upgrade of the main spaceship interior graphics on Paradroid. It probably only took me a morning to do, but I was so pleased with the results that we put that out too. It ran at the same 25 frames per second rate as the Competition Edition.
I think Uridium is as close to arcade action as you can get. It's fast and it's furious and I know the game well. What did you update in Uridium+ though? Did Hewson ask for an updated version, or did you have an idea about how to make the game even more slick and really wanted people to see the changes?
It was slightly more sinister than that. There were a couple of Uridium copies that came out a few months after Uridium. I was mad as hell that they could copy the game so closely and still get away with it. One guy even had the cheek to say I had stolen his idea. The lawyers said we couldn't touch them unless they'd actually stolen our code. I bought a copy of one (which pained me greatly), with a view to looking over the code to see if any of it matched mine.
In the end, I decided that the only way to get back at these people was to put 16 slightly harder levels together, along with a couple of small tweaks we had, and release a second edition of the real thing.
Why was Hewson the ideal publisher for Graftgold in those days?
The tape duplication plant was useful. He could react quickly to distributors' demands. Also, he had a good relationship with the magazines and organised some economical but effective product launches. He mainly left us alone to do the games, and not being on advances meant we were quite independent.
In 1986, you won Best Programmer, and Uridium won Arcade-Style Game of the Year in Computer and Video Games' Golden Joystick Awards. Congratulations, by the way! What can you tell me about that awards night?
It was a good day, there were a lot of my peers there, and I got two gongs! Being nearly 30 years ago, though, I don't remember a lot of it, sorry.
Was it nice to get recognition from C+VG's readers, and how important was this recognition for your career?
Absolutely. Getting recognition from the readers is getting recognition from the players themselves, which goes beyond any friendships you might have with the publications.
Did you ever go out to computer shows to show off your games and meet the fans?
Absolutely. We used to go to the ECTS show every year. Mostly, we just attended on our own, we could never justify having a stand, but sometimes we'd go as guests. We got a great reaction, actually, when we went to a show in Germany. The fans there were pleased to see us, and we were well looked after.
Was there a particular programmer, artist and/or musician on the C64 who influenced you and possibly inspired some of your own work?
It was always Jeff Minter. I liked the fact that he had his independence and got on with the job. He'd just follow his nose and had very high standards.
Coming from two successful games, Paradroid and Uridium, did you feel any pressure when it was time to do your next game?
I had the pressure of making sure that the quality was there. I was still keen to get the full-screen scrolling. I couldn't quite achieve that, I had to cheat at the edges with a little animation trick. As well as that, I had sprites dynamically going under and over the background, and another different graphical look, plus a shoot-'em-up racer, and the biggest crash sequence ever done! What could possibly go wrong? Unfortunately, I ran out of sprites. I wish we had come up with the sprite multiplexor by then, and of course had time to run it.
The game we're talking about here is of course Alleykat. Where did the idea of doing a futuristic racing shoot-'em-up come from?
I wanted a vertical full-screen scroller, and speed. I don't think a downwards scroller works, so a race game inside a space ring is what I came up with to explain why the track was looped. So the screen technology drove the game design.
There are some neat little features in the game, like 3D-looking graphics: the ship can be flown through/under hurdles; and you improved on the Uridium loop, which looks really nice. It really enhances the overall feel of the game! What are your thoughts on that?
I can't take credit for the graphics design, unfortunately. I had been playing Pastfinder on the Atari. I liked the stark look, and it only needed three colours and one shadow colour, which was just right for multi-colour mode. Going under the hurdles and over the landscape required some dynamic changing of the sprite-to-background display priorities. It's so subtle that you take it for granted, but there was quite a lot of work involved in getting that to happen. I'm glad someone noticed!
The sprites all look great and are really nicely animated. Did it take a long time to design them?
There are a lot of animation frames for each vehicle. I decided to spare no expense and use a few more frames than usual. I had rather ran out by the time I got to the Katerkiller.
Was that loop idea perhaps borrowed from 1942?
I probably had been playing 1942, yes. It's 1942 meets Uridium. It's use is not limited in Alleykat. Of course, you're not making any progress down the track if you loop, but it does get you out of trouble.
With all that was moving around on-screen, how advanced was the sprite multiplexor?
As alluded to above, there is no sprite multiplexor in Alleykat, that didn't come until Morpheus. All the bullets are done using characters – again, the hard way – because the Uridium bullets use characters too, but only hit 2 bytes. In Alleykat, I had to or the graphics into eight bytes (because horizontal pixels are in the same byte, and vertical pixels are in consecutive bytes).
Do you have any idea who pioneered sprite multiplexing?
Well, I got the idea from Tony Crowther, but we thought there might be a sprite multiplexor in the C64 version of Defender, some years earlier.
It's almost like the C64 designers always intended the hardware sprites to be reused in this way. The Atari 800 and Amiga use one long strip of data for the hardware sprites that goes down the whole screen. You can all but simulate that with judicious use of on-the-fly raster interrupts to reposition and reassign the sprites. It does take more bus cycles away from the CPU during display, but compared to plotting objects, it's a big gain.
In Magnetron, you are credited for graphics with Steve. Do you remember what you contributed?
I'd have to see it running again, to see if that jogs my memory. It could be anything from a font to some sprites.
Morpheus looks and plays really well and took some time to master. Did you feel that it was time to make the gameplay tougher because people in general were getting better at playing the games?
Morpheus was my first original C64 game that I couldn't complete. I did do all 50 levels individually, but my best attempt all the way through only got me to Level 43. I figured that there were better players than I out there, so I left it that difficult.
What can you tell me about the creation of the game?
This was when we started with the sprite multiplexor. I used the main character set for the main spaceship, a star field to simulate movement, and sprites for everything else. It was all back-to-front. The plan this time was to build a ship that can cope with future levels, but parts cost money and take time to build.
Given that most people in Europe used cassettes, was it important for you to squeeze your games into one load? What techniques did you use to get everything in there?
Yes, it was important to get everything into one load. The US Games idea of loading the parts in seemed flawed to me. At best, it wore the tape out, and at worst, it drove the player mad with the constant re-loading all the time. We overlaid buffers into initialisation code which only needed to be executed once. We also used some self-modifying code for speed and to save space. It would have driven the cartridge people mad.
How did you go about planning your code? Did you plan beforehand what routines you needed for a game, and decide roughly how much memory the code, art and music could take up?
The code took up more and more space with each game. There wasn't any spare unused legacy code in any game. We didn't use the full 64 kB of RAM until Intensity. Alleykat was the heaviest on graphics, as it was copying different character sets into the video bank. You had to balance all the data buffers, maps, graphics, sounds and code every time. Since I was both the programmer and graphics artist, there was no dispute. The sound and music didn't change in size much as time went on. Paradroid ran out of space before I got any music commissioned, so it just has sound effects, which is also less wearing over time.
Morpheus is the name of the Ancient Greek god of dreams. Is there a connection between the name Morpheus and what your game is about?
I was drawing names from Greek mythology for this one. We also got interested in the word "ubiquitous", as Mick kept explaining what it meant to anyone who would listen. So I named one of the meanies "Ubique", because it gets in everywhere.
Why was the game released on Rainbird instead of Hewson?
There was trouble brewing. We didn't think the game was getting the backing it deserved, although I was actually pleased with the artwork for the game, and that was really the first game I could say that about. We wanted to get better backing, and Telecomsoft came along and offered us that. We had no written contract, so we walked. There was a court scuffle and a settlement. Morpheus got new artwork and was packaged under the Rainbird label. I was pleased with the presentation. It had one of the biggest manuals I've ever written. I did enjoy writing the back stories, sometimes to explain the strange things that happen in the games.
Your last outing on the C64 was Intensity. What do you think about the game when you look back at it now?
I had decided to do a puzzle game. The sprite multiplexor came out again, doing shadows. I chose a name with nine letters in order to prove that the multiplexor was working, and it actually needs 18 sprites to do that. It's the most complex C64 program I ever wrote, because it maps altitudes over the screen layout to define flight heights. If I had had even more sprites and a second joystick button, I might even have put some firing in there.
The game is different from your earlier outings as there's no scrolling or shooting. Was it nice to do something without scrolling for a change? I can imagine you might have been starting to wonder how many scrolling games can you actually do!
I needed the CPU time to do the sprite multiplexing again, so I couldn't afford to scroll fast as well. You can scroll slowly, especially if you know it's going to be a fixed direction and speed, but I didn't want to do that kind of game, there were enough of them out there already.
At this point, did you already have one eye on the Amiga with a view to doing your next game on that machine? If yes, did Intensity suffer as a result?
I had wanted to get started on the Amiga as early as 1987. Intensity didn't suffer as a result, though. Starting on the 16-bit machines actually meant me giving up doing the graphics, though, which has always pained me. I did do some 16-bit graphics, but not all that much.
Were there any C64 games you worked on which never saw the light of day?
I actually started another C64 game after Intensity, but I ended up finding it hard going. I had a title page and a game screen, but not really any game idea yet. Then Rainbow Islands came along, and I'm jolly glad it did.
Of the C64 games you programmed, which one are you most pleased with?
Uridium. There was nothing in there I was unhappy about, it runs at the full 50 frames per second and looks like a proper arcade game.
Of all the C64 games you did, which one was the hardest to work on, and why?
The longer a game goes on, the trickier it becomes. You're packing more in, or dealing with more problems. The easiest games are the ones that just gel together quickly. That makes Intensity the trickiest game. I was still happy with the presentation on it, though – lots of neat tricks in there.
You had to come up with some quite innovative techniques, such as for instance multiplexing sprites and hires scrolling, to be able to create the impressive games that you created. Did it ever feel like a daunting task, to figure out ways of creating these impossible effects, or was it just a fun challenge?
I always started with the solutions! If something had already been done by someone else, then it was just a question of figuring out how and then coding it. I would always start with some ideas about how the screen was or wasn't going to move and then see what came of it. It was always a fun challenge. When we got onto 16-bit, I had more experienced 16-bit programmers around me who also had great ideas.
Did any of your work cause any particular headaches, or even lead to disagreements with anyone?
Not really. Steve chipped in with music and sounds as and when I needed them. I helped him test-play his games, so we worked together when required and otherwise separately, which was most of the time. The 16-bit era was a slightly different story, because you needed a team of four or five to put a title together. That can lead to disagreements and even fireworks. I learned that you have to be diplomatic, which is tricky when someone won't do what you want them to!
Did you ever find the limitations of the C64 frustrating, or were you always up for the challenge of making that hires scroller even smoother and tweaking that sprite multiplexor so you could put more sprites on the screen?
We usually hit one or more of those limitations in every game we wrote. I am hoping to put together some "Jeux Sans Frontières" on the 32-bit environment, to see where I could have gone. I'll always be retro, so there's no need to take on Destiny. How many man-hours were spent on that?!
Do you consider the C64 just a step in your programming career, or was it a major inspiration?
It was a fabulous time, because Steve and I had both taken a risk to do something we were passionate about and loved doing. It never seemed like a real job, although we still worked nine-to-five because that's what we were used to. Every day was different, and we were in control of it. What's not to love? I even made enough money out of it to put a deposit on my first house.
Have you ever thought of programming something on the C64 again? I mean, there's plenty of nice tools you can use on your PC, and there will always be another arcade conversion just waiting for you...
Tell me about the nice tools, do. I think I could emulate my idea of a super C64 on a PC.
Do you still own a C64?
I have a C128 in the loft, somewhere, with a 1541 disk brickette.
Can you talk about something you invented that was revolutionary at the time, maybe something you don't directly see in the game but which was more a part of the game engine or such like?
Dominic and John always credited me with the Alien Manoeuvre Program system that started with Uridium. It controlled the enemy spaceships and their flight patterns. They took it further with Soldier of Fortune, and then I re-implemented it for Rainbow Islands. There was some sort of symbiotic relationship going on there. I think they were being kind of generous.
Early on, cracked games and disseminated copies became a problem for publishers. Did it bother you when a cracked version of a game you'd spent months on started circulating two weeks after the official release?
Don't get me started. The cartridges started this off. We had to buy one to figure out how to stop it. Paul Hughes sent me a method for stopping it, and it worked. I never saw a cracked version of Intensity, but I kind of get the impression that no-one was that bothered about it. Sometimes, a cracked version got out before release when we left full copies of the game at magazines for review. We secretly encoded them all, so we knew which magazine it was. It bugged me more that these people even put their name on the title screens. Very troublesome.
Was Graftgold much affected by software piracy?
I expect we were affected by piracy, more in the 16-bit days than on the 8-bit. Has anyone ever done any calculations? I remember someone saying that for every properly bought version, there were ten copies.
Why did Graftgold fold?
We had the whole team working on one product, which left us vulnerable. The consoles had taken hold, and they had big, well-funded teams writing for them. Also, the PC was changing from DOS to Windows to Hardware accelerated. We spent more time re-writing or duplicating code than we did finishing the product off.
What did you move on to?
I got a job locally as a C programmer. They were recruiting, and I needed security. Other people in that company knew the value of a games programmer, so they made it easy for me to get in. I got Steve Turner into the place too, and we worked together for another 14 years.
Do you miss games programming?
Yes, being creative is the best job in the world. Not everyone gets an opportunity to do a job they love. Even if I only get to produce something for my own amusement, I'll be happy coding.
» Head
back to the list of available interviews
|
