Interview with Jose Doran

It was around the end of 1989 that I started dabbling with programming on the A500. I was always a big fan of arcade shoot em up's so did a few simple code tests around that theme to get used to the hardware and see what the machine was capable of. A lot of the early Amiga games at the time had what I classed as the 'Amiga look' to them. They always had these odd colour palettes that would be used all the time, it was like all people did was to load up dpaint then pick 4 rather ghastly colours and make a 8 intensity spread for each of them.

So despite having 4096 colours to choose from (same as a lot of arcade machines) you would have never known it. To me the early console games (PC Engine, Megadrive and SNES) of the time looked like arcade games. A lot of the Amiga stuff was really hit and miss, I was coming from the C64 so things where supposed to be better. It certainly wasn't that the Amiga's hardware was not capable in fact it was quite the opposite and there where certainly some nice looking games early on, but it was very mixed bag, however this is pretty normal with early games.

As a lot of the PC Engine, Megadrive and SNES games where made by the same companies that also did arcade games they had the benefit having artists all used to dealing with higher quality graphics compared to the 8bit days so the Amiga was making do with Atari ST ports and odd coloured games as people got used to the new hardware. From a programming point of the view the graphics where just a block of data but until there started to be more than just the odd game with nice looking blocks of data I had no real interest in programming an Amiga game, so I just used to used it to play a few games here and there and do the odd bit of hobby coding, thankfully in those days you could go get the Amiga hardware manual from a local bookstore so anyone could play around.

At around the end of 1992 one of my friends who had spent the best part of the year twisting my arm to do something on the Amiga was reading an article in the one magazine about project x, and it mentioned that if there had been one more object on screen it would have slowed down. Now I liked project x and it did look nice, like most Amiga games it was running at 25hz so was already slow to a 50hz purist like me, this was just the bait my friend needed, using an action replay we yanked out the graphics I dusted off the routines I'd written nearly two years previous and knocked up a demo using the same graphics with a few more objects on screen running at 50hz, plus a few of other simple demos. I showed these to team17 and they were impressed so at that point I was going to be doing a game with them.

The Team17 plan unfortunately fell through, Graftgold where up the road from me so my friend got me to go around and show the same stuff to Graftgold. I showed Steve the demos, at the time Andrew was busy with Uridium 2 so I didn't think they would need anyone else who doing an arcade shooter. Still the demo's showed I could at least code.

A few weeks later I got a call from Steve, they needed someone to do an Amiga version of football game, the complete opposite to the sort of games I liked, but another of my friends loved football games so I wouldn't have been able to have show my face if I'd said no. So I started work a few weeks after that. Up until that point I had done a few bits n bobs for people on the C64 with my Amiga code just gathering dust.

By the time I started most of the development was done, mainly by Rod and Martin who left a few months after I started to go work on another football game, I wouldn't be surprised to find them still doing football games now. As to who did what on the Amiga I did the bulk of the code with the other coders chipping in various other bits. By today's standards Graftgold was a small company so everyone really did help out on everything so the credits in the games always had everyone's name as it was a company effort. The themed names were just a fun way of presenting them.

Very good, like most publishers at the time they were very hands off leaving the developers to get on with the job at hand. They would visit at regular intervals to see how things were progressing; we also sent them regular builds of the game. Towards the end of the project they were there to help with final play testing to make sure the code was bug free.

The SNES version was the original. I don't know why it was never published as the game was finished. However we are talking about what many publishers class as the bad old days of cartridges. As the SNES version used a 8meg cartridge thus costing more to purchase than a 4meg onem it could well have been that Empire calculated they would have got little return in the crowed SNES market so chose only to publish the Amiga and PC versions of the game. Ultimately you would need to ask Empire to find the real reason as anything I put forward would be pure conjecture.

One of the design ideas was for it to be the speedball of football, also as it was originally intended for the SNES where arcade style games where the norm this to some extent dictated the direction the game would go, the Amiga did however help lend the name to one of the games special abilities the 'power drive', this name came from when looking at the Amiga where you had the two status LEDS with the words power and drive next to them.

As the A500 was a conversion of the existing SNES version most of the art assets had been done so it really was just a case of getting them to work in 32 colours and make everything look as close as possible, large player sprites where standard fare on the SNES so using small sprites would have probably seemed rather odd. On the Amiga where larger objects would take more time to blit it would be a case of the more you wanted on screen the smaller everything became, on the SNES with its hardware sprites this really wasn't so much of an issue you just had to contend with the fixed number per line limitation.

It wasn't really used much for the main game, it was mainly used for the front end and various menu screens. For the various menu screens it was used for various colour changes and for the scrolling background this was simply done with the paired sprites for 16 colours, the copper was used to keep updating the x-coordinates so they filled the whole screen.

The main menu had a logo based around the stripes on the US flag (World Cup 1994 being in the USA) this logo would never fit into 32 colours and look good. By using the copper you could write into any one of the colour palette entries if you did this repeatedly to the same entry on a line you would get a different colour every 8 horizontal pixels, so the stripes where interleaved to have 16 true colours with the copper block colours, this gave a strip that changed colour every 4 pixels. Of course this trick only worked if you used 4 or less bit-planes when you went to 5 the timings all changed, as the main logo needed more than 16 colours part of the screen was 5 bit planes, then it swapped to 4 for the stripes. In both these cases the copperlist was quite large 30-40k but they were pretty simple so procedurally generated before use each time.

The other odd use for it was the bouncing ball next to the busy text that appears between matches. To get everything to fit in memory there was a lot of decompressing of graphics and remapping of the player graphics to fit within the 32 colours and copying data around the place. This took time so rather than just have a black screen I wanted some sort of on screen indication of something happening, flashing the border may have been fine for a demo but not in a game and having a black screen even with music playing for 5+ seconds may have made people think the game had crashed. The copper list could be made branch off to another copper list so the bouncing ball was done this way branching off to a different copper lists each time, with the final one pointing back to the start, it was nice and simple and as it was done with sprites so the maximum amount of cycles could be given to the cpu, but it did catch me out a couple of times.

Development of the game was done using an Amiga connected to a PC (the same as consoles today) when debugging you would set a breakpoint play the game then when it would hit that breakpoint everything on the Amiga's screen would stop moving. Obviously the breakpoint didn't stop the Amiga's hardware so the screen display was still active it just stopped the cpu. I used this behaviour to save me having to constantly look back n forth between the Amiga's screen and the pc monitor; you'd watch the Amiga's screen wait till it all paused then look back to the pc screen and start debugging. Of course in the case of this bouncing ball it was never going to stop bouncing, when you're sitting there 2am you can be a bit slow to realize this.

It was written afterwards but used a lot of original code and unused code from the original A500 version. A key feature of the AGA version was initially prototyped on the A500 apart from some of the obvious graphical changes it ran on the A500 but was just a bit slow. The A500 version of the game ran at 50hz but the large player graphics placed limits on the amount cpu time I had for AI as you needed a large portion of the frame devoted to the blitter, with the increased speed of the A1200 cpu it was possible to reuse some of the older code that had to be cut for performance reasons.

The A500 version of the code did contain different routines if it detected it was running on the A1200 as with the faster cpu some of the code optimizations that where for the A500 wouldn't work, the A1200 cpu would be able to do a few more instructions after kicking of the blitter when the blitter was running in non asynchronous mode compared to the A500, on the A500 you didn't need to wait for the blitter saving you precious cpu cycles on the A1200 you did otherwise you would get graphical corruption.

It really was a night and day difference, I would class the AGA version as the true version. The main challenge for the A500 was to get it to be a single load game, with it having large player graphics compared to other games it used up a lot more memory than other football games, this placed limitations of what I could / couldn't do. Even though the game used 1meg in reality you only had .5meg for graphics and sound, while later Amiga 500's had the fatter agnus chips most didn't so you where limited to .5 chip and .5 fake fast memory. This meant there was a lot of copying data back n forth in and out of chip and fake fast.

The game didn't need to be a single load but in the case of a football game I just felt it wouldn't have worked very well if at the end of each half it would load in some stats screen, or if part way through a match you decided change formation forcing another screen to be loaded in, then after making any changes you load the pitch and players back in. In most games you would play level 1, followed by 2 etc so there was a natural break so the loading wasn't really much of an issue. At the time most football games on the Amiga where really not going to be winning any best graphics awards so while making it a single load certainly imposed limits on how good the game was going to look, it wouldn't look any worse than any of the other football games out there.

When it came to the AGA version this memory limit was not going to be a problem so it could look a lot better than the A500 version. There were a couple of ways to go, one was to increase the vertical resolution of the screen, due to the memory limits on the A500 rather than using a 256 pixels high screen it used a bit less, for the AGA version it would have been simple to just up the resolution and the colours and be done with it.

However I thought the original A500 version suffered a bit from the cursed 'Amiga look' compared to the SNES version so giving it 256 colour's worth of Amiga look wouldn't have been much better. One thing that the SNES version had was this perspective shear, that is when you where in the middle of the pitch, the verticals lines where straight when you got to the edge there where diagonal. To do this on the Amiga wasn't a problem it was a pretty trivial thing for the copper, the problem was on the SNES the players are hardware sprites so these were not affected by the shear, on the Amiga they would be which would look stupid, one way to solve this on the amiga by using dual playfield but there was no way on the A500 you could get the large player sprites to work with 8 colours and even though AGA dual playfield was now 16 colours that wasn't enough either.

I'd played around with ideas of how to do this effect on the original A500 but the only way to do it and make everything look good was to not bother with dual playfields and discard some of my other more interesting ideas but instead draw the players counter to the shear. In other words rather than blit the full player you would do them in chunks that where in the opposite direction to the shear, this way when the shear effect was applied the pitch would be sheared but the players would appear normal, this worked fine however on the A500 but it would have been very hard to maintain 50hz as you had to draw the players a couple of lines at a time on the A1200 with the extra speed this was the first thing that came back. From a graphical point of view it was the best feature, it also had the advantage of improving the amount of pitch that you could see making it seem a lot bigger than it really was.

As the AGA chip set had much better hardware sprites (64pixels wide, rather than 16) these where used for the stadium on the side this then scrolled past at a faster rate for a parallax scrolling effect the stadium also has the same perspective shear applied, the sprites where also used for various text overlays. Unlike the original A500 game this time the copper was getting a hefty work out during the actual game not just the menus.

There were some subtle things like using an extra bit plane to do an extra half bright style mode on some of the colours so that the players appeared darker in the shadows. The various menu screens also got a graphical upgrade to take advantage of what the AGA chip set offered.

Other new features, where an indoor pitch which had no corners / throw in's as the ball would just bounce back. A team editor that let you change the names of the players and a lot of other attributes for the players, plus not forgetting the book-o-meter, which was really me having a bit of fun and pushing the arcade nature of the game, when you were fouled by a player there were a few factors that would determine if you got booked.

In the AGA version rather than just getting booked the ref would appear and then the book-o-meter would be active, this being a bar that slowly filled up. By waggling the joystick you could argue with the ref and overturn the booking to a warning instead. It did cheat in single player in that each time you won it would get harder and harder till the point that all you could do was just stop the bar from moving but never get it to go down. In two player mode it was different in that the player that was fouled could waggle the bar to get the booking so who ever waggled the fastest would win. Depending on how serious the game thought the foul was would determine how much of the bar was full to start with.

There was also an auto replay after a goal in place of the goal celebration as this seemed more appropriate, you could always replay the goals in the original A500 version but the replay buffer was pretty small so by the time you had got to the replay menu most of the time you had missed the goal.

The player graphics also got a bit of an overhaul and had more polish applied to them, from some angles the originals looked good but from others there were a bit off. With Graftgold being a small company the artists would be working on a couple of projects at a time so there normally just wasn't the time to polish everything to the nth degree for fussy people like me, for the AGA version there was time to add that bit of polish.

We tried modeling the player in 3ds4 and rendering it out the theory being that this would give us good results in all 8 directions but at the time getting 3ds4 to render something out into a 32x32 tended to result in a large anti aliased blob, the same way that Mario was made short and fat with a big head so he would work within the limitations of what you could do with early hardware, the players would have been the same. Overall the changes really did make it look like a completely different game rather than being an A500 version with a few more colours.

Yes, like the original A500 it was still a single load game however on A1200 you had 2meg of chip ram so there was no need for copying data back n forth like on the A500 due to having to work with mixed chip, fake fast memory so all extra memory was used for the graphical and sonic improvements.

This extra memory really allowed me to use the hardware something that the original was never going to do. The A500 version was all about getting everything to fit in memory, so when it came to the A1200 it went the other way as I basically had an extra 1 meg so it was all about can I add all these graphical features and still run at 50hz, which is why in my mind I see it as the real version. However I've not seen it in over 14 years so maybe that's a good thing as unlike fine wine I doubt it's aged well, I'll have to make do with my rose tinted version.

100%

No market for it, publishers where far too late to do anything for the A1200, however you can't blame them as the A1200 was too late to the party IMO, it should have come out a lot earlier as the AGA chip set was certainly powerful and when used well was a match for the MegaDrive and the SNES (discounting Mode7) but with the Playstation on the horizon it was going to be quite dated.

It's a shame as the A1200 was a really good machine but it should have come out in 1991 instead of the A500+, the A600 just confused things more. It would have been nice if the AGA version was the only version of the game that came out in but with the Amiga being an expensive machine I would imagine it sort of fell into one of those catch 22 situations for most people, no point getting an A1200 as there are no A1200 only games for it, and from the publishers point of view why do an A1200 only game when an A500 version will work for it. Which is why I suspect most of the A1200/CD32 games were just more colourful versions of the original A500 version.

Still from a coding perspective unlike the PC, the game consoles are really like the Amiga in that they all have the same hardware, so while the Amiga is no longer around at least the games consoles offer a similar programming experience.

One of the things about Graftgold was that it was a small company so everyone helped out where possible on the current projects, the last things I worked on where the MotoX game and the Rainbow Islands conversion for the Playstation, it was supposed to be a 3 game pack with Bubble Bobble, Rainbow Islands and Liquid Kids with Probe doing Bubble Bobble and us doing Rainbow Islands and Liquid Kids, which was a shame as Bubble Bobble is one my all time favourite arcade games, it used to be one of those games I would play to see how fast I could get 9,999,990, I never managed to do it in Super Bubble Bobble mode could only manage just over 6,000,000.

Where as Rainbow Islands I never got on with, Bubble Bobble was like a shoot em up, Rainbow Islands wasn't I never had much joy attempting to get all the diamonds in order. Liquid Kids was fun we didn't do too much work on it, we were given all the arcade graphics and the levels map graphics but they were like a giant jigsaw puzzle, without knowing what the final image was supposed to look like. It took me ages to piece them all together of course arcade machines didn't have a pause mode and we didn't have any documentation on what any of the dip switches would do so there was no cheat modes for me. This was all pre Mame days, could have really done with it back then :).

1996

Spiderman, James Bond, Call of Duty. I primarily do graphics programming so mainly deal with low level engine work, shaders, postfx's, lighting etc