An interview with John Croudy

John Croudy was one half of the formidable Random Access/Sales Curve programming team that worked on some of the Amiga's most fondly remembered games. His softography consists of the following games:

• Silkworm (1989) - ST code, some Amiga enemy code
• Ninja Warriors (1989) - ST code, some Amiga code
• St Dragon (1990) - Code and music
• SWIV (1991) - Code
• Rodland (1991) - A little code
• Indy Heat (1992) - Code

How did you end up working at The Sales Curve?

It was an amazing piece of luck. I had been working on some kind of sideways scrolling robot game which was actually total rubbish but it had one clever effect; multiple layers of horizontal parallax scrolling. It looked like I had done the impossible but in fact it was all based on multiple shifted versions and the parallaxed elements were heavily repeating. But it ran at 50fps and that was cool on the ST. Anyway, a mate coerced me into going to a computer show in London in the late summer of 1988. I didn't want to go, but he bugged me, so we went and I took a demo disk of this robot thing.

At the show there were screens connected to Amigas and kids were playing games. I did something I would never usually do, I put a disk in an idle machine, booted it up and walked away. I watched a couple of kids playing my half-written robot and had a giggle. Next thing I knew, I was being huddled into a small room by Dan Marchant, and inside there was Ned Langman, Matt Spall, and Simon Pick. Dan had seen my demo and they were looking for someone to do ST Silkworm, which of course was a sideways scroller. Dan had somehow found out that I put the disk in (I think through another mate of mine who was there by random chance). Anyway all of a sudden I had a job interview lined up! I couldn't believe it.

I quit my existing job of 9 years to join a motley band of geeks in a newly started company. It was the best thing I'd ever done up to that point, but my wife wasn't thrilled because I had to take a reduction in wages. By the end of Indy Heat she had walked out on me. I guess I just wasn't upwardly mobile enough for her ;-)

The 9 year job you left to work at Sales Curve - was that also computer-based or something far more boring?

It was a job in a computer room at an insurance company. It was somewhat boring and involved working with some very unpleasant/abusive people, but it was great to work with big metal mainframes.

Silkworm

You are credited with creating the Atari ST version, which your co-programmer Ronald was very impressed with. Did you do any code on the Amiga version?

Although I was the ST programmer on Silkworm you could say I was involved in the Amiga version too. This is because Ronald and I shared all the enemy programming. Both machines used the exact same enemy code because of Ronald's ingenious 'UFO system'. This was a cooperative multitasking system which enabled enemy code to be written without regard for the target platform as long as it was 68000-based and had an implementation of the UFO system on it. The yellow helicopters, for example, were written by myself on both the ST and the Amiga because it's the same code. By the same token, the Goose code is the same on both machines as well, written by Ronald. All of the enemies were done like that.

Can you explain a little more about how the UFO system worked? I can only imagine each object has a series of common routines in it such as update_me, draw_me, kill_me etc. And these routines would be easily customised to move an enemy while firing across the screen at certain points etc?

Something like that, I guess. First, there was a sprite table where each sprite was was referenced by names like goose001, goose002 or something like that. Here's an example of what the code for an enemy might have looked like (this is not precisely correct, call it pseudocode):

; After initialisation, a5 always points to this UFO's data block.

; Animation table has all kinds of codes for things like speed,
; start, end points, looping and so on.

.anitab dc.w    aniSpeed, 10, aniStart, goose001, goose002, goose003, aniRep

        lea     .anitab,a0
        jsr     UFOSetAni

; ----- This section is fuzzy in my memory but it was something like this

        moveq   #16,d0
        move.l  d0,ufo_HotspotX(a5)     ; Hotspot point of sprite.
        move.l  d0,ufo_HotspotY(a5)

        moveq   #32, d0
        move.l  d0,ufo_BoxW(a5)         ; Collision box around hotspot.
        move.l  d0,ufo_BoxH(a5)

        moveq   #100,d0                 ; This value will be depleted by bullet hits.
        move.l  d0,ufo_Power(a5)        ; When zero, blow up.

; -------------------------------------------------

        moveq   #0,d0
        move.l  d0,ufo_X(a5)

        move.l  #SCRH/2,d0              ; Y halfway down the screen.
        move.l  d0,ufo_Y(a5)

; Use DX, DY and Acceleration...

        move.l  #$08000,d0              ; Move half a pixel in X every loop.
        move.l  d0,ufo_DX(a5)

        move.l  #$10000,d0              ; Move one pixel in Y every loop.
        move.l  d0,ufo_DY(a5)

        move.l  #$2000,d0               ; Accelerate by this much every loop.
        move.l  d0,ufo_AX(a5)
        move.l  d0,ufo_AY(a5)

; OR use speed and direction (automatically updates DX and DY)...

        move.l  #$4000,d0               ; Quarter of a pixel per loop.
        move.l  d0,ufo_Speed(a5)

        moveq   #$20,d0                 ; 45 degree angle.
        move.l  d0,ufo_Dir(a5)

 ... do something else

; Call all other UFOs 100 times with a5 pointing to each one
; and return with a5 pointing to this one again.

        moveq   #100,d0
        jsr     LoopUFONext

 ... do something else

        moveq   #100,d0                 ; Keep updating for 100 loops (usually frames).
        jsr     LoopUFONext

There was UFONext, LoopUFONext (call UFONext d0 times) and LoopForeverUFONext (call UFONext in an infinite loop).

Inside UFONext it would do some stack-based magic and call all the other UFOs and then return to this one with a5 pointing to this one's data (kind of like a 'this' pointer in C++ I suppose, although I didn't know that at the time). This is difficult to explain; you have to think of it as being inside-out in that every time a UFO calls UFONext, all the other UFOs execute for one cycle; they each get a turn until they hit another UFONext. If a UFO failed to call UFONext the system would lock up because it was cooperative multitasking, not true preemptive multitasking.

UFOs had the information about sprite animation, movement and so on, and it was all based on a low-level 'NTT' (entity) system which was the actual context-swapping system. Raw NTTs were used for stuff that didn't have graphics such as timers, sound and so on. The NTTs were in a statically linked list of 'slots' which could be added and deleted in-place as they were needed.

I think everything used this system, including the title screen and high-score tables.

The craziest routine name we ever had in Silkworm was:

        GooseBitSubForeverUFONext

which was a loop that called UFONext forever and did something else like rotating a bit of the goose. One of the shield pieces I think.

Inside UFONext I believe it automatically did collision detection based on the hit-box and position. I think that when a UFO had to be deleted, a flag was set in its data block and UFONext (via [ntt] Next) automatically removed the whole NTT from the linked list. There was no 'cleanup', it was just gone. The automatic hit-test code set an animation table for the explosion and I think there was an aniDie or something that ended the table. So it would explode and then go away, all automatically. This would happen for example inside the UFO's call to LoopForeverUFONext. So a simple enemy could just set its animation, speed, direction, etc, and jump to LoopForeverUFONext. It would stay on the screen animating and explode and go away when hit enough times by a bullet. An enemy like that could be fully implemented in 10 lines of code. UFOs were created by doing something like this:

        lea     BadRobot,a0
        jsr     GenUFO

and the UFO's data block would be created and linked into a free slot in the UFO table. When the last existing UFO called UFONext, this one would get its first execution, being expected to call UFONext itself at some point and so yielding control to the next one. After GenUFO returned, I think a0 pointed to the new data block. It was common to call GenUFO in a loop and initialise positions and directions of a swarm of bullets:

MakeBadRobotFire

        moveq   #16,d0
        move.l  d0,temp

.loop   lea     Bullet,a0               ; Address of bullet routine.
        jsr     GenUFO

; Initialise bullet data that is different for each bullet.

        move.l  ufo_X(a5),ufo_X(a0)     ; Copy my position to bullet.
        move.l  ufo_Y(a5),ufo_Y(a0)

        move.l  temp,d0                 ; 1 to 16
        subq    #1,d0                   ; 0 to 15
        asl.l   #4,d0                   ; 00 to F0 -- angle.
        move.l  d0,ufo_Dir(a0)

; Sometime during the next call this bullet will start executing and it will do
; the rest of the initialisation of values that are the same for all the bullets.

        moveq   #4,d0
        jsr     LoopUFONext             ; Delay 4 frames; bullets will spray out in a spiral.

        dec     temp
        jnz     .loop
        rts

I'm amazed I can still make this stuff up. I think some of this is not 68000 code but you get the idea, right? :-)

The UFO system had all kinds of maths support for things like Sine and Cosine tables; Ronald basically made it very easy indeed to write enemies. All the common stuff was abstracted away into reusable routines, so we could just concentrate on the enemy behaviour rather than the actual programming. It was like a construction kit, but very very efficiently coded. This also helped to eliminate bugs because the UFO system was tested and reused by everything.

UFOSetDir was really clever. It set a direction for movement on a circle with 256 possible directions, so for example, hex 40 would be 90 degrees, hex 80 was 180 degrees, hex C0 was 270 and so on. There was an automatic sine/cosine lookup which adjusted the position of the UFO according to its direction. So you could just set a direction and a speed and off it went, all by itself. With acceleration, it would also get gradually faster, slower etc.

The X, Y position, speed and acceleration were stored in longs with the high word being the pixel position and the low word being the fraction. So you could use a value like hex 00018000 to get 1.5 pixel movement per frame. Before I met Ronald I had no idea you could do this. It's amazing that I programmed computers for 9 years without understanding this kind of basic stuff. I always say that Ronald taught me how to program properly. Before I met him, everything I did was hacky and not-so-smart. Although I was able to get results good enough to land me a proper job, it was only after meeting Ronald that I discovered programming didn't have to be quite so difficult. His elegant solutions made it much easier to think about the gameplay rather than the underlying machine instructions.

Variations of the UFO system were used for all our projects after Silkworm, including Saint Dragon and I think also Indy Heat. After remembering how it worked, I must say that it is the most elegant system I have ever worked with anywhere in my computing life. Ronald was a total genius; he developed the whole thing himself with no one to ask for help. I still wonder how he did it.

Many of the enemies in Silkworm appear to be somewhat random. They don't follow the exact same path every game. For that they must be able to track the player a little bit, as I think the yellow helicopters slow down when they get near to you, and fly a bit faster when they're further away. Does that sound correct?

That's right. The yellow helis track you and move at a speed that depends on how far away they are. I remember that much. The heli and jeep, I think, store their positions in a couple of global variables. I think there is a HeliUFONext which stores the position before jumping to UFONext. Any enemies can then examine those positions.

In that case case, the UFO code must be adjusting to the position of the helicopter, so did they just ignore where the jeep was? Or in a single player jeep game were they smart enough to only track the jeep? Or were they even smarter and tracked the nearest player? Or can't remember? ;-)

I think that a particular enemy, say a flying thing, would prefer to attack the heli if present, otherwise it would attack the jeep or not attack at all if there was no jeep. In other words, different enemies preferred to attack one or the other or both or neither. Possibly some tracked the nearest player. I'm sure it was different for different enemies, and the above sounds like what both Ron and myself would have decided to do. Even if it's not exactly correct it should be close to reality.

How difficult was the ST version to write? I imagine it was reduced to 16 static colours, everything had to be drawn every frame update due to no hardware sprites or hardware scrolling etc?)

ST Silkworm was much easier to write with Ron's NTT/UFO system than it would have been without it. The stuff that the UFO system couldn't help me with was the scrolling and sprite drawing, as you mentioned. I had a technique for doing scrolling which I'm sure many others used; I stored (I think 16) shifted versions of each block so that I could whack it onto the screen as quickly as possible. I just had to choose the right version depending on the scroll position anded with 15. This is not rocket science but made it possible to scroll the ground quickly. I believe sprites also had shifted versions because that made it lots faster. At the start of the program, it took each block/sprite, created the shifted versions and stored them in memory.

Are there any things you are particularly proud of in your Silkworm code?

One cool thing I'm quite proud of was that on the level with lightning, the lightning was created using a fractal subdivision algorithm which meant that it was really like proper lightning. Every lightning bolt was unique and random.

Ninja Warriors

Please tell me a little of your memories of Ninja Warriors.

I was the ST guy on this too, but again, we shared code. This time we used Ronald's UFO system running on a true multitasking micro-OS written by myself. In retrospect I now see that we tried to be too clever and had a lot of problems caused by the multitasking. But we got around them with one or two clever hacks ;-)

Can you remember any specifics with regards to the problems you encountered?

Yes, well at the time we didn't fully understand it, but now I believe the problems were race conditions caused by a lack of synchronisation between 'threads'. On MS Windows we have critical sections and mutexes which solve these problems, but we had been too 'clever' and wrote a system that exceeded our understanding of the problem we were trying to solve.

You worked closely with Ned Langman on the game. Do you have any interesting memories of this?

Ned actually had to do the first part of the Ninja limbs-joining more than once because I made some mistakes in the editor program and lost his work. This happened several times. Seems like he's forgiven me for that or at least forgotten about it. It wouldn't have happened if we had used XML back then but I don't think it had been invented yet!

Saint Dragon

Can you tell me a little about St Dragon?

This was my first Amiga game, and it shows. Most of the hard stuff was actually figured out by Ronald (I keep calling him Ronald because that's what we called him back then, although now he goes by the name Ron). Anyway, the player bullet sprite multiplexing system was Ronald's design. I bugged him endlessly for advice while writing it.

Did you get any choice about converting St Dragon or Jane Cavanagh just allocated you to convert the game?

I think Jane said "How would you like to do this?" and I said "Yes please" because I loved the little dragon guy and I wanted to have a go at programming the curly tail.

How long did the game take to write?

Let's see. I started in early 1990 and by 1991 I was on Indy Heat, so it must have been a year or less. I really don't remember, but it was probably a lot less than a year. Something like 6-8 months? I had to play the whole machine through to learn the alien patterns and it was really difficult. What a job! Playing arcade games for half the day, no coins required :-)

There are no credits in St Dragon for the musician. Can you remember who did the music and sound effects?

I'm embarrassed to say that it was actually me who did the music for Amiga St. Dragon. Embarrased because, as one review rightly said, it's terrible.

Ron had developed an FM synthesis routine for Ninja Warriors. The Ninja Warriors music was so excellent that I wanted to use Ron's algorithm. I didn't realise that you actually need to be good at creating computer music as well as having clever maths. Ron helped me write the sound driver (I remember we called it Spongeware for some reason) - and I essentially typed the music into some tables by listening to it playing on the arcade machine. So I did it by ear without sheet music and there were not enough instruments so it came out horrible, but we didn't have time to do it again.

The main problem was that the driver did some kind of multiplexing using a priority-based system, but sometimes when there were a lot of other bullet sounds, a musical note would be dropped and the music would be ruined. I think I ran out of time before I could solve it, so the music is pretty bad. Also, the bass sounds were not very 'meaty' and overall the music is just sort of thin sounding and unsatisfying.

As for the sound effects, I seem to remember sampling the sound effects directly from the arcade cabinet by plugging it into some special hardware.

Was the game designed to be 25 frames per second from the start?

I guess so. The arcade machine featured massive sprites (one so large that it was the entire gameplay of a level and we had to leave the whole level out) - and there was so much mayhem on the screen that I knew I wasn't going to be able to make it run at 50fps. I guess I tried, but I am not known for my optimising skills - not even today ;-)

There seems to be an awful lot of bullets on screen when you have powered up weapons. Did you devise any special tricks to reduce the amount of collision tests you would have to perform?

I think that was part of the reason there was so much slowdown. Too many collision checks. If there was any optimisation on that it would have been Ron's idea. He developed a very clever way of optimizing SWIV's collisions.

Can you remember the optimisations?

All I can remember is that it involved sorting the bullets into ascending y-order. By doing that, as soon as he discovered one was out of y-range, he knew that all the rest in the list were out of range and he could stop checking. It resulted in such a speed improvement that the time taken to do the sorting was negligable by comparison.

How did you handle the bullet collision? Are the bullets a single point or a series of points, a pre-defined rectangle or something else?

In Ron's UFO system, every 'ufo' had a 'hit-box'. This is a pixel range measured around a hot-spot position relative to the sprite top-left. So we checked collisions by seeing if the box of the bullet intersected the box of the target. A simple rectangle check, but it made sure things couldn't pass through other things, and it was possible to make some things easier to hit to aid gameplay. It's possible that for the green bullets I only checked a single bullet point, but I don't remember.

The game seems to be running in 16 colour mode and it looks like only 4 sprites multiplexed to create the green player bullets (colours 16-31 have some repetition). Is that correct? How did you decide on that screen setup?

16 colours, was that really all we had to work with? Yes, I guess that's right. As Ron said, too many colours slows the CPU down and I think we did all our games in a similar way, so it would have worked the same way as SWIV. The hardware sprite system was figured out by Ron. There was definitely some very clever multiplexing going on. I found Ron's algorithm very difficult to wrap my brain around. He was a total genius.

Here's the Saint Dragon copperlist to bring back some memories!

Wow, I can't read this. I'm amazed I ever could.

With a horizontally scrolling game on the Amiga you lose the 8th sprite due to lack of DMA time in the horizontal sweep. That should leave 7 sprites available for bullets - but it appears to only use 4. Is there a reason for that?

I remember only using hardware sprites for the green player bullets but I don't remember why. It may be due to DMA time problems. I remember having a discussion (argument?) with Ron about this because I couldn't understand the problem and he was losing patience trying to explain it. Ron's the guy to ask about this :-)

Player bullets seem to be stored in memory multiple times with a series of control word, positions and then the sprite graphic data. Was that because the bullet graphics are static and therefore you can put them in memory once and not have to worry about anything other than storing new control word/pos data to move them? (The common alternative system being a copperlist that repositions them).

Sorry, I have no idea! Ron's the guy again here. I think he mentions this stuff in his interview (how can he remember?!) - and it sounds like I must have used exactly the same system. I think I just implemented Ron's thoughts.

One thing I remember was that we made a great team because his main strength was design and optimisation, whereas my strength was implementation. I would be amazed by his ideas and he would be amazed by my implementations (and sometimes appalled at my lack of formal programming technique) :-)

There are an insane number of cheats in St Dragon. Were they all added for debugging?

No, they were all easter eggs which were supposed to be leaked to magazines over time to renew interest in the game. I think one magazine published the whole lot in one go so that didn't work out.

Were they all your idea?

They were a mixed bag of ideas by the team, but a lot of them were personal to me. For example, the word 'Puntettay' is mine and it refers to the Pink Mice you may have encountered. In fact my email address and web site also refer to the same thing. Kirstie and Jemma were my sister's babies; they are now adults!

Do any of the ones we have marked listed as unknown ring a bell with you as to what they do? (Cheats such as STAMP are listed as "strange effect display/leave a trail")

Many of them were done because it was easy. STAMP was indeed just not redrawing the background behind the sprites.

KYLIE was a reference to rumours at the time that Kylie Minogue was using pitch-correction on her songs so that she could sing in tune. When KYLIE is active, the music plays very out-of-tune. At least that's what I remember.

Good old autotune eh - saved many a singer!

Was it really autotune that early? As an aside, I HATE autotune. It is an abomination which, along with dynamic volume compression is destroying music. Just my opinion ;-)

SWIV

Can you tell me what parts of SWIV you worked on?

I worked on two things for SWIV.

I wrote a tool for creating the floppy discs which used a system we called DLS (Dynamic Loader System). Ronald desiged a special low-level disk format which helped to reduce piracy. I implemented the writer. I don't remember if I helped to implement the reader that SWIV actually used. Probably not.

I also wrote the end-of-game nuclear reactor explosion sequence and possibly the high-score table etc, but I'm not sure about that part.

You were interviewed for a feature The Making of SWIV in Retro Gamer issue 58. Unlike most of the Retro Gamer interviews, it contains some really nice technical information!

Wow, thanks. I had forgotten all about that. I remember writing my part but I don't remember when it was done.

In the Making of SWIV article it says "Ronald designed an entirely new low-level disk format which could not be read by just any Amiga. The idea behind this was to prevent piracy. It didn't. The game was cracked in just two days. It usually only took a few hours for a cracked version to be released, so our disk format slowed them down, but they still managed it. We couldn't believe these guys managed to copy our special disks because you needed our software to read them. They must have figured out how DLS worked and ripped out the disk-format reader. Pretty impressive."

The comment about figuring out the DLS system is not entirely correct. The only part of the game that needed to be hacked was the the tiny bit that loads some data from the disk. The original code would have been replaced by a routine that loads an AmigaDOS standard track. A search for the dsklen ($dff024) hardware register usually yields the routine that reads a track into memory and then the hacker is well on their way!

True, but they would have had to figure out our low-level format. Ronald invented some replacement for the MFM bit-encoding that is on the surface of the disk. The idea was that the crackers wouldn't even be able to read the thing at all. Your $dff024 thing must have worked for them. They must have used it to find our reading code and then copied the method to their own loader. Or something. It was really only designed to slow them down a bit, which it did.

Indeed. The weak spot with custom disk formats is the fact that there are only a few ways you can load data. Basically the MFM buffer address goes to $dff020, sync at $dff07e, read length (written twice) to $dff024 kicks it off. Once the buffer has the data, there's always a routine that converts the MFM words back to real data. So crackers usually just lifted that bit of the routine out and plonked their own standard loader down in it's place. Most of the elite crackers had written their own incredibly small loaders which were almost always smaller than the original loader - it had to be otherwise they'd have to find some spare memory in the game which is sometimes very difficult!

I think that none of us really understood just what those guys were capable of. We knew they had special hardware as well and could do the 'impossible' using it.

Ned Langman seemed to think Ron Pieket did the specification screens for the helicopter and jeep used in the attract mode of SWIV, but other sources suggest you did them. Which is correct?

I remember doing it, so at least part of it must have been done by me. We probably shared the work somehow. I was involved in making up the silly text too ('twin overhanging undulating suspension'... etc).

Rodland

In a preview of Rodland from The One magazine, you are credited as doing "additional programming" on the game. What parts of Rodland did you write?

If I did anything on this, it would have been the high-score table or something.

I don't remember being much involved in it.

In that case, we will move right along!

Indy Heat

Can you tell me a little about your 1992 game Indy Heat?

This was one of my Amiga conversions. It was actually done in 1991 probably at the same time Ronald was doing Rodland. After that I moved onto the Nintendo SNES and didn't write any more Amiga games.

I've attached some screenshots ripped from the disk image of Indy Heat. The game appears to be 32 colour mode, and a single bitplane mask for each track. Did you have to mask the cars against this before drawing them to create the pseudo 3D effect?

Yes, I believe there were two mask bitmaps which Ned made from the backgrounds in Deluxe Paint. One was a sprite mask which made it possible to have the sprites appear to go behind areas of the background. The other was a collision mask. See later.

How do the enemy cars get around the track? Are there a set of waypoints they constantly aim for?

I think that's right. It's gradually coming back to me now, and I think there were points - hang on, yes I think I wrote a very simple point-placer tool. You load up the background and click points onto it. It was very basic but it meant we could place waypoints (we didn't call them that) that guided the cars around the track. This could be a false memory but it seems very likely how I would have done it.

One common question that crops up regularly in car racing games is how to ensure the player has driven a valid lap. Some (naff) games allowed you to drive a short distance, turn around and drive back over the start area and that counted as a complete lap! (Or you could do laps backwards in some games!). What was your method to solve this problem?

I don't remember how I solved it, but I'm sure I did solve it. It rings a bell as being a somewhat difficult problem. There may be some waypoint counter and a check for waypoint order. Or did I just make it impossible to drive the wrong way? Perhaps you could do a test and see! :-)

I have retried to make the game count an invalid lap. I tried everything I could think of, including driving the entire race in the opposite direction and it never counted a valid lap! I suspected there were a few points that you had to cross in order to count a lap so if I did enough laps it would count, but no! Well done! Whatever you did was very clever!

Thanks. I knew I had somehow done it properly. It was a big deal and getting it wrong wasn't an option.

I've often considered adding extra tracks to this game! Would that be possible or a nightmare of a job? Is there actual code on each track that would need to be altered, or is it a case of changing the graphics and mask for a new track and some waypoint table and that's enough?

I think this game was very, very simple actually. All the tracks worked in exactly the same way. Just a picture, a couple of masks and some waypoints. The only problem with adding more tracks would be the actual hacking of it. There's no extra track plug-in stuff or anything. You would have to reverse engineer and hack it in, but it could be possible. But I won't be able to help you do it. You might as well ask some guy down the pub. I can answer questions, but that's about it :-)

Did you write any kind of track editor for creating the tracks or was there no need?

See above. You know, now I think I built the waypoint editor into the actual game. This would have allowed for instant testing. But don't go looking, it would have been a debug-only thing. Somehow or other, points were specified.

How did you ensure the cars stayed on the track? Was there any kind of edge of the road map?

Yes, there was a collision mask as mentioned above. I just checked if certain points around the car were inside the bitmap, and if so, applied some kind of simple adjustment. I seem to remember it involved a cosine table lookup and it was quite effective. The cars had a rotation value that chose the sprite and direction of movement. I checked the front of the car to see if it overlapped the bitmap and if so it tried to rotate the car so that the front moved back out of the bitmap. It was a bit hacky and a bit hit-and-miss (I suppose it was a heuristic rather than an algorithm) but it worked. Took a bit of tweaking to get right though.

How did you do the collision detection for cars hitting each other/bouncing/hitting walls etc? Especially things like 2 cars hitting on funny angles, working out which one should bounce/stop/get spun around etc.

That heuristic I mentioned above, I did a bit of simple maths based on stuff I'd learned in Physics lessons. I made it up; nothing was correct or done properly. I experimented with acceleration values and weightings until it looked and felt good enough. I do remember it was hard though. I'm not sure if I used the car sprite as a collision mask or if I used some kind of rotated vectors. Whatever it was, it was simple and not rigourous in any way. Sometimes very weird things happened at certain angles. I expect you saw some of them. But it came out as a bit of fun. I'm surprised I got away with such a lax solution.

How does the game know which areas of the map are slow-down parts (shortcuts through mud etc)?

I don't remember. Possibly there was a third mask which Ned made. That sounds like the most likely solution.

The Colorado track looks really different to the others used in the game. Did another artist (or dare I say it - a programmer!) work on that one as that track in particular has really weird shading or was the original like that?

No, just me and Ned. It works in the same way as the others. I may have put some special code in to handle any differences, but I don't know now. I think Ned got the graphics from the arcade company and reduced them to suit the Amiga.

Sometimes in the pits you can race through using it as a shortcut and other times it stops you (or sometimes fails to stop you properly!) Was that intentional (correct speed required, or you had to be close enough to your pit area to make it stop) or was it a bug?

Sorry, I don't remember for sure. I think it may have stopped you when you were damaged or low on fuel, or it could have been to do with speed.

Did you find any bugs in the original arcade machine version and do things deliberately differently/better?

I don't think so. The arcade machine had five cars but I reduced it to four for performance reasons.

Were there any problems implementing the music from Allister Brimble (in KRIS/Chiptracker format)?

I don't remember any. I think he provided a drop-in routine that just worked. I seem to remember thinking "Wow, it just works!" or something like that.

Who did the sound effects for the game and particularly the speech such as "Red, pit!" when your car is damaged? Was that someone at Sales Curve?

No, the arcade company sent us some sound files which had the original voices.

Most reviews at the time thought the game was very well done, but too easy. Was it possible to tweak the difficulty level easily or it was a case of no time?

I don't really remember. I think it was a bit easy on the arcade machine too. It was a very simple game and the other cars didn't try to be hostile; they were just following waypoints. I think the part where they veered off to the pit-stop could be tricky because stuff would just run other stuff over. I seem to remember it all being a bit reckless. It was just supposed to be fun. Stuff crashed. I think bits fell off. I realise this is not answering your question. The answer is, no, it wasn't really possible to tweak it.

Are the "CPU choices" for upgrades actually the best? Can you remember what order is the optimal one for upgrades? (MPG or Engine?)

I had totally forgotton about this, so I can't really answer. I remember I had the feeling while I was writing this game that it was a kind of fluke; a cheat on my part. I think what I'm trying to say is that I took some short cuts hoping that no one would notice the difference. Didn't expect anyone to ask 20 years later ;-)

Did you implement the copy protection on Indy Heat? (Calling the Rob Northen copylock presumably?)

I don't think I had anything to do with that. I don't know how that stuff worked but if it needed to be in the program, I would have done something. Probably, as you say, just had to call someone else's routine.

General

Do you have the source code for any of the games you worked on?

Afraid not. We never took copies home and even if we had... obsolete hardware :-(

What was your average day like when you worked at Sales Curve? Standard 9am-5pm, an hour for lunch so down to the pub or gym?

Gym? Heh heh not likely. The time was flexible, 7 working hours (one hour for lunch if you wanted it) and you could start pretty much any time you liked. I tested this big-time in 1992 when I had a personal (relationship) problem. I was getting in at 1 o'clock sometimes, and then I worked until 9. Usually I worked something like 10 to 6 with an hour for lunch. At one point a couple of us would just go over to the park for an hour and eat sandwiches. I never did the late nights/living under the desk thing. Perhaps others did but I don't remember it. We didn't have any formal meetings. We would sometimes just gather around someone's screen and discuss stuff.

Were there any teams or programmers you greatly admired?

I personally liked stuff by the Bitmap Brothers (although it was usually too difficult; I never got past the first level of Xenon). Also, Geoff Crammond, the guy who wrote The Sentinel. He was a genius; he could make a game look and feel exactly the same on every platform and he could make a computer do the 'impossible'. The Sentinel is one of the best games I've ever seen.

I also liked a game called Necromancer (Atari 400) by a guy called Bill Williams who I think has since passed away. I like elegance and consistency and both of those games had that. In addition, finely-tuned adaptive difficulty which Necromancer had. It even had adaptive music which randomly varied according to the gameplay.

For elegance and consistency, today my favourite is Minecraft. I hadn't been addicted to (or even interested in) a game since Lemmings - until I discovered Minecraft.

Speaking of Geoff Crammond, did you know that an Amiga programmer (AmiGer) disassembled Stunt Car Racer, worked out the track format, created his own track editor in Delphi and released a new version of the game called Stunt Car Racer TNT (The New Tracks) featuring 8 new tracks?

I remember Stunt Car Racer; Crammond was one of my programming gods. It's amazing how even today people are still reverse-engineering this stuff.

Did the team have access to lots of the software others were producing to see what was state of the art at the time?

No special access, just what anyone else would have. One of the guys in the office was a member of a 'group' that could 'acquire' software and he would occasionally bring in demos but they were usually the useless demos that showed how a 'coder' could write fast stuff and do copper tricks. We just used to buy any games we liked, for example, I had my own copy of Lemmings and some stuff by the Bitmap Brothers.

Did you have any kind of support team or people that you could call if you were stuck on a problem?

No, nothing like that. We were pretty much on our own as I remember. And there was no Google to help us either :-)

After the success of your games, I would think other companies would be keen to lure the team to work for them. Do you have any idea if any of the team were approached or poached?

Yes, me! The guy who hired me initially, Simon Pick had left a while ago and gone to work for Probe Entertainment. In the summer of 1994 Simon phoned me and invited me to an interview at Probe. I was offered more money than I was earning at the Sales Curve, but more importantly, Probe wanted me to work on the Sega Saturn. The Sales Curve was moving towards CD-based games, the kind with lots of stored video sequences and hardly any gameplay. I was horrified by this and jumped at the chance to go and work on a new console. It turned out that I couldn't get my head around the Saturn (because I was trying to program a console whose hardware wasn't fully implemented yet!) - so I moved into writing mapping tools and so on. I learned to program in C and that was where I left games programming forever.

Your website has a page dedicated to Puntettay, the pink mice that you made popular at The Sales Curve. Many of your games feature them on the credits screens as 'Programmer Psychotherapists'. Were they toys you threw around against walls when you encountered problems?

The pink mice just used to sit on our desks. Some guys may have thrown theirs, but I didn't. Ned destroyed his by removing the stuffing and sellotaping the skin to the wall. I still have all but one of mine and a few extra ones that I got later. No one hated them; there was range of feeling -- I loved them to death and Jane basically ignored them. Everyone else was in between. As the company grew, we started to get 'ordinary' people, secretaries, accountants and other non-artistic (non-crazy?) people who probably didn't even notice the things.

When we worked at Jane's flat in 1989, I used to come in every morning with 5 mice in a bag and then line them up on my desk, in order. In the evening I would take them home again. One morning the C64 guy, Warren Mills, had a bit of a meltdown because he finally couldn't take it anymore. It was actually a little bit 'Rain Man' of me, I think. I do have that kind of personality. Definitely falafels on a Friday, definitely 5 falafels. That kind of thing. I still get made fun of for it, but I can't help it :-)

Do you have any photos from those days?

I actually have some Video 8 recordings of us working on Silkworm in 1988 -- BUT -- they are somewhere in my sister's house in England (which may mean lost, but she says she will try to find all my tapes). Of course, who can play Video 8 today? If she sends the tapes over, I'm planning to try and find a player on eBay. If I ever manage to retrieve that footage, I'll make it available to you. But don't hold your breath :-)

In the first picture, I'm guessing you were far left above Ron, beside Warren Mills?

Yep, that's me.

The guy with the tie, surely some accountant type?

Precisely!

Did you work with most of the people in the photo?

I really only worked with the game manager/producer and Ned and Ron. I did help C64 guys with questions about their version of the game I was working on, and there was a fair bit of chat and socialising. The accounts people pretty much kept to themselves (it's difficult for geeks to talk to people like that ;-)

Later on there was this really nice secretary girl (I won't say who though) that many of the guys fell in love with. We used to almost fight over her to have lunch, and she dated a few of the artists over the years. We became quite close friends.

Magazine Articles and Photos

Amiga Computing magazine published an article in issue 14 (Vol 2 No 2) from July 1989 shortly after Sales Curve released Silkworm. The original article featured a photo that had been flipped horizontally so the people did not match the descriptions! (The image has been flipped back to how it should have appeared).

Your Amiga (August 1990) featured a 2 page article called "Storm Warning" and included 8 photos of the Storm offices.

Zero issue 11 (September 1990) featured a 2 page feature called "Going Down a Storm" that included a group photo and previewed St Dragon and SWIV:

ST Action issue 31 (November 1990) featured a demo of John's game St Dragon, but John was not so happy about this:

This was the worst article ever written about our games. Firstly, they spelt my name wrong. Second, they "quoted" me without ever interviewing me. I never said any of the stuff they wrote here, and I wouldn't have because most of it is not true and complete rubbish. They had no idea what they were talking about. Still, I got my picture in the magazine. That was back when I had a skinhead haircut, in 1990.

Into the Sales Curve

In January 1992, Click (the magazine-on-videotape) visited The Sales Curve/Storm and interviewed several of the developers. Ron Pieket is visible for about 2 seconds at 0:42, Ned Langman's interview is at 1:36, and John Croudy's interview starts at 2:18.

It's very faded now, but I think we had a few days notice that they were coming in. The whole thing was set up; there was one guy coming out of the toilet at the right moment, and Ron had to deny entry to the 'secret room' which of course was just the main office with nothing secret in it at all. When something went wrong they had to start again from the beginning, because it was all one long take. They explained how they would do it and we had to sit in chairs in the right positions. I didn't actually sit next to Ned at that time. Anyway, because I was near the end of the sequence, I was really nervous because I knew that if I made a mistake it would mean they had to start all over again. You can actually hear my voice shaking, which is a shame because I'm not usually camera or mike shy at all.

Thank you very much for your time and for all the enjoyment your games brought to the Amiga community!

Links

John Croudy's YouTube channel