Fire and Ice

Introduction

Fire and Ice was Graftgold`s first Amiga-led project. The Bitmap Brothers had set up their own publishing company: Renegade, and we had been in talks with them about publishing some games.

As usual I have culled some screen shots from the interweb, so thanks to the creators of those for producing images of our game. Nice that this gif runs through its animation.

 

 Smooth Scrolling

It was late 1990 when Paradroid 90 had shipped on Atari ST and Commodore Amiga. That game was using Dominic`s 16-bit "OOPS" kernel, which he had developed originally for Simulcra, and we had used for Rainbow Islands. This had allowed us to write a game predominantly on the Atari ST, and then port to the Amiga, running in 16-colour mode, in about 3 weeks. The kernel took care of common functionality such as keyboard, joystick and mouse input, interrupts, debugging, and displays. The up-side of this was that we could produce a game on 2 similar platforms quickly, but the downside was that we were working always to the lowest common denominators. This particularly exposed the weakness of the Atari ST: no sideways smooth scrolling in hardware. 

 

Meanwhile Turrican 2 had been released for the Amiga, showing what could be done on the platform. It had plenty of sprites, a great copper-listed backdrop of colours, smooth scrolling in all directions at 50 frames per second, and a great game with plenty of action.

 

We had some telephone conversations with Julian Eggebrecht, representing Factor 5, the team who wrote Turrican 2. They had written their own development system as well as the game. They were keen to tell us about their scrolling technique, which utilised the unique feature of the Amiga hardware: that the bit-planes for the display can start on any word address in memory. Most displays had fixed or boundary-limited addresses in RAM for the screen.

 

The issue for the Amiga was also that the CPU was not fast enough to rebuild an entire screen`s worth of data every 50th of a second, fast though it was. The magic of the Factor 5 scrolling system was realising that during smooth scrolling, quite a lot of the screen data stays the same. Only areas covered by software sprites, animated background characters, and the scroll leading edge(s) change, so if you can efficiently update those then you can get to the magic 50 frames per second arcade speed.

 

I`ve written a detailed description of our interpretation of the scrolling routine in an earlier blog article.

 

I spent about a fortnight implementing the scrolling routine. I drew up a test set of graphic blocks, just some numbered squares, really. The first screen is initially built by starting the display a whole screen to the side of where you really want to display, and then letting it slide all the way across to where it needs to be, building up the leading side edge of the screen. Whatever garbage happened to be on screen to start with is discarded off the trailing side. The scroll routine is set to loop round building the edges for as many times as it needs, but once the game is running; it is controlling the scrolling and limiting the speed usually to about a maximum of 4 pixels a frame, so a leading edge will only be needed every 4 frames (blocks are 16 pixels wide to match the smooth-scrolling span and the hardware pickup of 16-pixels in a word. 

 

To start with, I just used the mouse movement to drive the scroll position. This allowed me to check the edges where scrolling needs to stop, and I could move the screen slowly or quickly. Since there's no game to run then there`s plenty of CPU time available.

 

Animated Background Blocks

The display system needed animated background blocks. These allow squares of the screen to be efficiently updated to create areas of movement. I therefore needed to set up some simple lists of animations. This goes back to the old days of C64 animated characters where each 8x8 pixel graphic was defined by 8 bytes of graphic data. In those days it was necessary to shuffle the actual graphics data between 3 or 4 consecutive characters, whereas it would not be efficient to shuffle the 128 bytes per character of the 16x16 blocks. Since the characters are done by software, there were no character modes on the Amiga, we could get to the graphic data through a list of pointers to the characters, so animation was a simple case of shuffling some of the pointers so that the character renderer just gets redirected to different graphics.

 

Animated graphics in Fire and Ice include the underground waterfalls under the jungle, the high score initials entry screen, and the rising bubbles underwater, but for an extreme example, John Lilley went for some psychedelic party effects all over the level completion screen. 

 

 

Software Sprite Plotting

When we plot software sprites into the display bitmap, we need to restore the background when those sprites move, which is every frame. The sprite plot routines have to calculate the position on the screen where they`re going to plot the graphics, so at the right moment they just note the offset into the screen, the width, and the height of the plot into a restoration list. 2 frames later than the plots, for a double-buffered system, the restoration list is parsed and the pristine graphics are copied, nay blitted, from the restoration buffer to the display buffer. A restoration buffer is a third copy of the character background that never gets any sprite graphics plotted to it. It also has to scroll in synchronisation with the game objects in order to have the correct graphics available to be copied for restoration. 

 

First demo

The first demo that we submitted to Renegade featured a furry, flappy-eared bouncy creature than may have been descended from Gribbly. The background graphics were quite mountainous, and the creature merrily bounced around the place. This must still exist on a floppy disk somewhere... For now we have a magazine snippet from an unknown contributor in the comments. Seemed natural to me that a fluffy bouncing dog with flying ambitions should live in a nest at the top of a tree. 

Some of the lower pictured sprites made it into the final game. At this time they were all single-character prototypes by Phillip Williams, to see what he could do.
 

Renegade reported back that the character was a bit too "unconventional", shall we say, and wanted something more traditional in its movement.

 

We gave our lead graphics artist on the project, Phillip Williams, free reign to animate a character of his choosing. At this point, the full palette for the game, levels, and sprites has not been decided, but the colours chosen for the main character, what they are and how many are used, has a great bearing on the yet-to-be-drawn levels. We had decided on using 16-colour mode still, I wasn`t confident that we could manage 32-colour mode. You lose CPU cycles if the code is in video RAM as the graphics chip has to steal cycles to pick up data from any more than 4 bit-planes. Whilst we couldn`t really quantify that, we also had in mind that we still would like to produce an Atari ST version of the game. We split the palette into 4 groups of 4 colours, making the last 4 the blue to white range, so that we could map the other sprite colours just into those last 4 for the ice effect. Arranging one's palette colours is always important. 

 

Phillip came up with the smaller Coyote character. We had Renegade visit to see the new graphics. They were pleased by the more conventional walk of the Coyote. The suggestion came up that they wanted something to rival Sonic, plus they liked the Sonic colour scheme, so we adjusted our palette again.

 

I had my ideas of what I wanted to use the hardware sprites for, and that was the score overlays on the screen. Firstly they only needed to be 3-colour sprites, I could use the copper list to get more colours, and secondly they would then not need to be plotted on the background, they would ride over the top in their own layer. Many people might think that the main character is the best subject for the hardware sprites, but there are cases where you might want to have it interact with the background and pass behind or in front of other graphics, which the hardware sprites can only do one of at a time. In our software since the 16-bit days we always implemented layers for our software sprites so that we could control which graphics got plotted first to last. That allowed us to add foreground objects that the other objects would go behind, including Mr. Coyote.

  

A Real Sunset

I really liked the Turrican 2 colour-fade. I noted that they had interleaved colours to expand out the fade over a wider distance. This is because the resolution of colour change on the chip was 4 bits of each of red, green and blue, which doesn`t give that many changes, only 16 different values of each. The AGA graphics chip had 8 bits of red, green and blue, giving 16 times as many colours. More on that later.

 

I did some research on what is happening with sunlight to produce the reds, oranges and yellows of spectacular sunsets. I then rigged up a routine to simulate those colours and drop the results into a copper-list to display the colours on the screen for every raster line. Unfortunately the resolution of the resultant colours being only 4 bits meant that my sunsets were rather... "lumpy". I therefore chose not to use them and went for the more simple "curtain" effect which just mixed in two lists of hand-picked colours, one for daylight and one for sunset. It looks rather mechanical, but the quality of the colours is better. I wish I`d kept the original routine, because it would have looked really nice on the AGA chipset, which expanded the colour resolution to 256 levels.

 

When we did the A1200 and CD32 versions of Fire and Ice, as well as adding an extra background layer, I also revisited the colour lists and put in the extra resolution to get really smooth colour fades. Those colour lists were all typed into the assembler by hand in hex, not done in an art package.
 

Lower Screen Banner

We had limited the scroll screen area to 192 pixels high to be ready for an NTSC version, should we need it. You only get 525 scan lines on NTSC TVs, which translates to 262 pixel lines, and there are certain processes that need to get done during the screen "off" VBlank time, such as getting any copper list changes done. Nevertheless I enlarged the screen with the land panel at the bottom. I decided to get self-indulgent with wiggling the smooth-scroll registers to make the water shimmer.

 

The first thing that I found out then is that time is very limited and you can`t get the copper to do an infinite number of things in the limited time it has in the horizontal blank time. Firstly you need to get the 4 bit-plane pointers switched over, then set the smooth scroll register, and start to switch the colours. There ended up needing to be one pixel row of sky colour with no other colours as getting 16 colour registers set up takes a while and the colours aren`t all ready by the time the display starts. So get the sky colour done first as it`s the first one to be seen, and don`t use any of the others until the next line. The next issue occurs at the waterline, we change the bit-plane skip factor so the same data gets re-displayed upside-down. Then we start altering the colours to darker ones, and on each raster line we alter the smooth scroll register, which is centred on the middle position, 8 pixels, and run a sine-wave through the subsequent lines so the water wiggles. This all added about another 48 pixels to the overall screen height. There were certain rules in the hardware manual about where you could start and end your display, which you had to stick to. 

 

First Levels

One of my initial game features was going to be some fire creatures that lived in pots, and then come out and fly off to various points around the level and, if un-stopped, start fires. I was using the Paradroid 90 patrol-route system, and had added a routine to analyse the network so that when a fire creature emerges, it chooses a target point on the network and finds the shortest route round the network to the target. Once it starts the fire, it then returns to a different pot for the night. It`s actually a feature I had initially used in a COBOL game called "Navigate".

 

The upshot of the initial tests was that since the fire creatures fly, they are difficult to follow on foot, or paw. They are also mostly off-screen and difficult to monitor, so the whole concept was somewhat flawed. 

 

We developed the pesky little Incas that fire darts at the player. Being quite small, we could have quite a few of them on screen at once, doing different things. We created a curly-haired king Inca who could generate new Incas too.

 

Slopes

I wanted to do a more complex ground surface system than just simple horizontal surfaces to walk on. This would include slopes and walls that could deflect bouncing objects, as well as provide surfaces to slide on.

 

I devised a two-part system to record the slope or surface of each character. Firstly I would define the angle of the surface using 4 bits, and then the other 4 bits was the offset of the surface down into the character for walking on. I then created graphics for all of the valid combinations that just showed the surface definitions. During testing I rigged up a keypress to tell the graphics plotter to use the surface definition to access the surface graphics instead of the real ones so that I could check that the surfaces were all cohesive. You mustn't leave holes for objects to fall through or escape.

 

We had decided that the Coyote should fire, spit, or bark ice-balls, rather than carry a weapon, which then got me to calculating bounce angles and sliding accelerations for the ice. This led to all sorts of physics fun when an ice ball rolls into a valley and needs to stop. Getting them to stop when resting between two opposing slopes took a few weeks to pick the bones from.

 

I had accepted that we wouldn`t be running at 50 frames per second due to the amount of plotting and physics calculations that were going on. I believe that Turrican 2 was using a lot of hardware sprites rather than software ones, giving it an edge. Running Fire and Ice with what I regarded as a reasonable number of objects was regularly over-running, causing stutters that looked and felt horrible. I reluctantly limited it to 25, knowing that it should never over-run that. I never saw Turrican 2 over-running, that was irritating!

 

Julian, Thomas and Holger came over from Germany to see us, on the pretext that they could tell us where we were going wrong and get the game running at 50 frames per second. After I had explained what we were doing and how, they agreed that the workload was too much for 50 frames per second. We explained to them the virtues of a triple-buffered system, then watched them retreat into a corner for a brief discussion before coming back and just saying "No". For the record, while your joystick input and display can suffer an additional lag of a 50th of a second, a third buffer can get you over short busy peaks as it buys you up to an additional 50th of a second of processing time to spread over a few frames.  

 

I had a set of control mode parameters for the Coyote that were tied to the level data. This was so that I could make the ice levels slippery, and the underwater levels more treacly. The other meanies also tapped into some of the values so everything got intertwined.

 

We didn`t feel that the control mode was quite right, it seemed a bit slow to some people. Renegade set up a meet with one Julian Rignall for me to show him the progress so far and see what he thought of the control mode in general. The upshot of the meet was that I needed to speed up the movement, jumping acceleration and gravity, everything really. Once I had done that, the coyote was moving a lot better. Unfortunately... changing those variables caused all sorts of upsets amongst the various meanies that I'd tuned up. Whilst gravity is shared across all the game objects, the initial jumping speeds, for example, of meanies are individually set. Jumps that used to cross gaps no longer did. I had to re-tune all of the meanies so far.

 

My tip of the day then is to get the physics set in concrete early on. Just to riff on that a bit: when designing a game and its software you need to keep on top of dependencies: which parts depend on which others. Altering something with no dependencies won`t have any unexpected consequences. Altering something with a myriad of dependencies can topple an empire. This is why I hate it if my code calls external code, you have a dependency on something that you can`t control, nor change, but someone else can... in the future. I`m now using SFML, a set of external libraries. I`m pleased to report that the recent upgrade to 2.5.0 didn`t even cause a ripple, all my code still compiled and no behaviour degradation has been noticed.

Weapons Systems

Weapons upgrades were the norm by 1992. They`re always a double-edged sword because you mustn`t require a player to have them to progress. If none are available then the player still has to have a chance, the extra weapons should only make things a little easier.

 

We could plant green disks around the level marked with the weapon that they give. The extra weapons were typically shot-limited. There are also question-mark ice-cubes that deliver multiple disks, so you can choose which to pick up. These can be hidden until you fire at them. Ice crystal balls also contain a limited number of disks. My favourite weapon was the super-bark. There`s also an ice shield, multi-fire, and big ice-bomb. Since we can`t depend on them being available, they don`t have massive effects.

The Clouds

The snow bombs are accumulated by collecting snow-flakes. Snow-flakes are produced when you fire ice into white clouds. Firstly they start to rain, then hail, and if you keep firing then they go into a cycle of snowing snow-flakes, which you should collect by standing under the cloud. When the cloud turns black, get out, there will be no more snow-flakes but there will be lightning. This can kill the coyote, any unfortunate nearby puppy, or any meanies for that matter.

 

Don`t confuse the white clouds with the permanently dangerous dark clouds in the Scottish levels.

 

Snow-Bombs

Snow-Bombs are shown as snow-flakes at screen top-right, under the lives count, marked with Ls. You can hold up to 8. This is by sheer coincidence the number I could display in the hardware sprites available.

 

To fire a snow-bomb, the coyote has to crouch on the ground, then hold the fire button.

 

Snow-bombs are excellent for bringing down flying meanies, and of course they freeze every meanie on screen at once. It`s worth saving a stock of them for big meanies.

 

Thawing Time

Meanies are deadly to the Coyote unless they are frozen by hitting them with ice first, sometimes multiple times. When frozen, they turn blue. There is only a limited time to smash frozen meanies before they come back to life. This thawing time shortens as the  game goes on, since the lands become warmer. That's about the only reason why the lands are in the sequence that they are!

 

Level Time

The sky fades swap over from day to night and back to day 7 times before the coyote gets a hurry up. The snowflake in the top left loses an arm after each day. The day and night lengths shorten as the lands progress. Mostly this doesn`t come into play, there`s plenty of time, but it focuses the player on getting the job done.

   

Development

We actually developed the later levels first, unwittingly, just because we had some graphics ideas for the hotter levels first. When we developed the game scenario of the coyote having to travel from his igloo in the Arctic to near the equator, we were obliged to put the colder levels first, and the Arctic level is the trickiest to play. Just watching new players slide about uncontrollably was something of a concern. I wonder to this day whether I should have just not had the coyote slide about, it doesn`t seem totally necessary. The skiers and the walruses do skate about, but that`s about it. Well it`s a bit late now!

 

Arctic Levels

Having decided that Cool Coyote lives in the Arctic, we built him an igloo. I requested lots of slippery slopes to launch the skiers. We also had the magic of the ice ladders and bridges. I had intended those to propagate through the other levels too, with the idea that as the lands got hotter, the ice would melt more rapidly. They make a reappearance in the Inca levels.

 

We also developed the puppies here. They are keen to stay with the coyote and will follow him obediently. You can also instil bravery into them by firing/barking. This makes them go ahead of the coyote, and since they can smash frozen meanies and not be hurt by non-frozen meanies, they can be very useful. Barking to make them go ahead of the player is the safest way of getting them to go through the doorways ahead of the coyote.





The intention was to locate the puppies on the levels and herd them to the exit door, while collecting the 6 key parts. Each species holds one key part. This provides a motivation to explore and deal with the meanies. Since any member of the species could hold the key part, you get a different game every time. To herd the puppies, you tend to be getting them to move ahead of you, and you do that by firing. That also tends to protect you from rapidly arriving skiers.

The rope bridges which sink under the weight of the player are a nod to Turrican. I would have preferred rope bridges that sank down a little more but I didn`t come up with a nice way of doing that.

 Scottish Levels

There's a lot of wacky stuff that comes from Scotland. I remember an old episode of The Goodies that featured the bagpipe spider, so I definitely wanted some of those. I also wanted the wild haggis, porridge, the Loch Ness monster and a castle. We also had some permanently moody storm clouds, hares, eagles, and bears with shields.

 

The ground is no longer slippery, like on the ice levels, controlling the coyote is much easier. I was finding that the meanies were a little too easy to freeze, so we gave the bears a shield. There`s an extra collision area in front of the bears that if it sees an ice pellet arriving tells the bear to raise his shield. It works well, they`re infuriating. You either have to jump over them and hit them from behind or use a special weapon that can hit them from behind.

 

The first wild haggis that you find live in the trees. They jump out one by one and run for it. If they hit the edge of the screen, they go splat. The solidity of the side of the screen (aka the edge of the world) has an important significance in that it absolutely has to stop anything from escaping, or the program will potentially pick up duff data and may crash. To embody that edge of the world as a real wall that you can run into tickled me. All of the other meanies just turn around.

 

Actually, to prevent any escape I had two columns of wall characters and each side, two rows of ceiling pieces at the top, and two ground pieces at the bottom of the maps and I had to stop the scrolling 2 characters inside the map edges to not show them. Nothing was getting out of my screen! I did that because since the meanies have to check the characters around them anyway then having unseen blockages can be done for free. At no point did I also have to say: "turn around if X < 2 or X > 4072 or Y < 2 or Y > 1076", all of which takes valuable time.

 

Inside the castle we had some naughty platforms in the wall blocks that only come out and can be stood on when you fire at them. They're sitting over the top of the porridge pool. We relied on the player trying stuff out and revealing the trick. Once they`ve figured that out it`s a case of getting an ice pellet to the next ones as you jump from platform to platform avoiding a bath in the boiling porridge.

 

The second-generation haggises live in the castle and can ooze off the end of walkways. When they get close to the player they can jump at him. Also in the castle are the pesky archers, These are best tackled from behind after they reveal themselves, but beware of others firing at the same time.

 

All games are enhanced by crocodiles, I`ve always said that. As we know, they can`t open their mouths if you`re standing on them, so wait until they close their mouths and then jump on them.

 

The Loch Ness Monster is sort of the end-of level meanie that`s nearly at the end, but mostly it`s the fish that leap out of the water. Those fish can also have a key piece, you do need to freeze them as you jump along Nessie`s back. 

Underwater Levels

These levels game me an opportunity to re-tune all of the movement speeds and accelerations to get some slower movements, especially gravity. I realised that we couldn`t use the ice bridges and ladders underwater, they wouldn`t look right, what with the dripping melt-water, underwater. I had a couple of different mechanisms to get upwards: there were big air bubbles released by sea anemones, and then there were the clams. I spent a long time trying to tune those, almost as much time as many people took to master them. The trick with the clams is built into the coyote control mode. He has a gravity-altering downwards pull when jumping. I put that in as you have less control while jumping, but it might be useful to dodge stuff to increase the downwards speed a bit, in the same way that the jump height can be extended with extra up joystick. The Rainbow Islands control mode had some interesting attitudes towards gravity and there's not a lot you can do with a switched joystick to indicate your intentions to jump a little or a lot, so we have to improvise. So, back to the clams: the spring you can get off the clams is proportional to how hard you land on them. This in turn is connected to how high you jump off them in the first place, and if you then pull down at the right time you can get some extra speed. Then it's a case of applying up stick as the right moment to maximise the jump as the clam springs open. A very slow speed landing on the clam just causes it to close.

I had always intended that the coyote would have accessories, and the scuba mask was one such. We realised that the landscape was more severe and there were many lifts, and the puppies were not smart enough to use sprite-based platforms. We also didn`t have any small enough scuba masks for them. The coyote control mode was able to handle the character ground pieces and single flat sprite surfaces, so we could do moving platforms, that was it. I play Ray-Man Legends and can only admire the variety of moving and static surfaces that all the objects can traverse. 

Phillip was getting into his graphical stride by the time we got the undersea levels. He was also getting a feel for how many frames of animation he was allowed for the level. Every object in the game is custom coded, each with its own program, animations, and rules, nothing is table-driven, so if he could draw it, I could make it move. The meanies had fairly free movement in the levels, especially fish and birds. If they left the screen they would be purged, and recreated if their start position was on the leading edge of the scroll again, ensuring that nothing appears out of thin air in full view.

Phillip was working on a propeller-driven animated fish that was moving along nicely, and then he showed us some frames of the fish rotating round to face the other way, and it really looked like a solid 3D object. He'd done it all by eye, we had no 3D graphics tools to help. I remembered being so impressed that he had managed to create this object with limited colours. I was more than happy to spare the animation frame space for the turnaround. He did something similar for the squid. We had lots of bubbles coming from objects. Some of the rising bubble streams were animated characters, others are software sprites.

It was when we got to these levels that we realised they were big and difficult to remember where you were going. That`s when we came up with the mini-map. This has to scan the character blocks and pick out 1 pixel per 4 x 4 pixels in each character for display.

 

We also created the helpful hint arrows to appear in many places if there is little movement, to give the players a hint. I was a bit naughty with secret jumps in some caves that give shortcuts to secret levels, or just advancement. There's no such thing as a pointless cave in the game. There might be treasure, or a meanie that you need to find, or an exit, albeit largely invisible. I think I might have a small sprite that appears every now and again where there's a secret jump spot if I was doing the game again, especially since I can no longer remember the routes!

 

There are also "The Eyes" in various dark places. These have no real bearing on the game but they do look towards the player when he`s nearby.

The turtles in the game are moving platforms to jump on and reach places that you might otherwise be unable to do. Most people notice that the turtles can`t be frozen, but don`t realise that you can jump on their backs and take a ride.

 

 

I`m also responsible for draining all of the red out of the colour palette for these levels. I don`t know if that was quite the right thing to do, but no-one stopped me. Makes little difference to someone who is red-green colour-blind because our issue is that we don`t have the full quota of red cones in our eyes and so red gets swamped by green and we can`t tell brown from orange from green from red. And yes, that is infuriating!

 

Jungle Levels

I was keen to get the caterpillars in, as my nod to the old arcade game, which I spent a lot of time playing in the pub on a Friday night. I wanted to get them to split if you hit the middle of them, though that didn`t fit with the way the rest of the game worked, so I had to settle for freezing them. They are a multi-part object, and I could make them long or short.

I realise now that I made a mistake in the way the coyote restarts after losing a life. The game remembers the last piece of solid ground that he was standing on for a restart. For this level though we had a straw bridge above some fly-traps. The straw blocks can be destroyed by ice-balls and snow bombs, making the bridge much harder to cross. If you stand on the destructible blocks and then fire a snow bomb or otherwise destroy the block you're standing on, and then get shot by an arrow, it won't recreate the block but it will put you back to stand where it was. You then repeatedly fall into the fly-traps until all your lives are lost. If it had happened to me in testing I`d have sorted it, but it never did, rather embarrassing, really. It may well be fixed in the CD32 version, possibly the A1200 version too.

 

 

 

Phillip took a few attempts to do a multi-layer animation for the waterfalls in the secret level. He had to do 3 separate animations and then overlay them. They really do look impressive. Many people might not see them if they don`t jump down the rabbit hole on the second level. Another one for the little tempter sprite to hint that it's OK to go down. There are some tricky jumps to negotiate down there, mind. There are also points to collect, and a bone-us life.

We tried to get a 3D feel to the jungle scenes by having burning spears lobbed from over the other side of the water, along with lumps from the volcano that goes off periodically. Interestingly it`s not featured on the video I watched, so apparently it can be avoided! Maybe that's why it is a good idea to take the rabbit hole at the beginning of the level. 

 

The main tip for this level is to keep firing as there is danger coming from everywhere. The over-ground levels are flat, a consequence of me needing to colour the river with the copper colour-fade. Let the puppy go ahead and pick off the meanies that you have frozen. Just don`t use the snow-bombs near the straw bridge above the fly-traps, as in the picture above. 

Inca Levels

These levels were the ones we started with. At the time, the game plot had not been thought out. We had the Inca minions in various walking and jumping incarnations. I must have been thinking about Indiana Jones as I wanted to do a runaway mine-cart set piece, with a trackway that collapses behind the cart. Tuning that up to get the cart to behave correctly at the end at just the right speed was a nightmare. When we re-tuned the speeds it all fell short again and I had to re-work it. Jason Page and Phillip were suggesting ideas for more features. I suspect they had played a lot more platform games than I had. It`s definitely great to have more input, better to have too many ideas than too few.  

 

I was keen to have more smaller meanies rather than fewer big ones. When the game is only partly written then you don`t know how big it`s going to get. The number of character blocks used for the backgrounds is variable, but generally the more the better, and that space is shared with all of the sprite animations. There are lots of moving platforms, rotating pendulums in different ways, others that fall. There are also collapsing platforms, spikes, a nice big rolling ball, boulders carried by birds that just shouldn`t be that strong...

 

 

When you`re putting your first levels together, you get a feel for how difficult the level is to play, and therefore you can design some easier or harder levels around that. Never assume that the first level you create will be the first level in the game. In nearly all cases I have had to make easier opening levels for my games. Once I watch newcomers struggle with levels that I find easy because I know how they work and have played them a lot, I realise that experience is colouring my view of the difficulty. 

There are a couple of set pieces in the Inca temple that require you to be armed to the teeth. The above picture shows one place to stock up on snowflakes from multiple clouds. An aggressive special such as the super-bark is also recommended, or one of the multi-fire ice bombs, the shield isn`t going to help so much since you`re locked in with something, and it`s you or it.

 

 This is actually a photo of the PC version. We also finished a Sega Megadrive version, along with the ST version. I actually have no recollection of the ST version, not even how we would have achieved such a thing. Eldon Lewis did most of the Megadrive conversion but I`m not convinced that it got released.
 

Bonus Levels

The number of mechanisms needed on each level was high, each one requiring to be individually programmed in our Alien Manoeuvre Program (AMP) language. I fancied something a little simpler, and wanted to do a nod to my other platform game: Gribbly`s Day Out.

 

I also wanted something a little more wacky, so we set the scene in rock islands in the sky. It`s definitely a nod to the work of Roger Dean, which I suspect inspired Avatar too. Unobtainium, indeed!

 

There are many presents all over the levels, but they are being picked up by the meanies, so you need to get round as quickly as possible as each one scores more than the previous. Then you can decide whether to take out the meanies on the way to stop them from picking up the goodies. Since they`re arriving from the top then it makes sense to get up to the top of the level to stop the meanies. I had Gribblets in there too, just bouncing around, like they do.

 

We also left little meat pies lying around as food for the coyote, but they sprout legs and run off in a short time, behaving in a lemming-like way at the ends of the platforms. Get to them as quickly as you can.

 

Being bonus levels, even if you fall off the lower levels, you don`t lose a life, it`s just a bit of fun before the final level. There are a couple of "Bone-us" lives to be collected that should be useful.

 

Egypt Level

Having drawn the fire creatures and the pots within which they live, I was determined to at least use them, albeit in a more minor role. They were quite wide graphics with a number of frames, which meant they were taking up quite a lot of memory, and would have been expensive to have on every level. Without an editor for the patrol routes that the fire creatures follow, the co-ordinates of all of the points have to be put in by hand, and that gets laborious too. You have to balance the time spent entering and debugging the data against the time spent coding and debugging an editor, and then entering the data. To this day I`ve never written an in-game editor. John Cumming wrote our background editor in STOS on the Atari ST that we used for Rainbow Islands, Paradroid '90 and this project. I never had a level editor for any of my C64 games, everything was built up from smaller blocks. Some of the earlier ones were listed on paper.  

 

 

 

 

We also wanted quite a large end-of-level/game meanie. The rules generally are that the larger it is, the less frames of animation you can have. That's both because of the memory cost, and the time it takes to draw the graphics. The former is what stops you, of course. The end-of-level meanie is the end-of-game meanie and we wanted him to be pretty tough, but beatable. Of course when you know what you`re up against then you can pace yourself  bit, don`t use all your weapons at once. No spoilers here, move along.

 

 

Sounds

As usual I waited until development was nearly done before getting the sounds added. It`s best to get them done all at once, and by the same person. Also, the music needed to be created. We included a music on or off option, which creates additional issues. The sound effects compete with the music player for the 4 available sound channels, and for your attention. When the music is off there needs to be enough sounds to make the game sound full enough, but when the music is on you don`t want to lose half the instruments to the sounds, nor do you want the sounds to be covered by the music.

 

As usual, Jason Page did a great job, as there are a lot of sound effects. We ended up with 15 tunes, 26 resident effects for all levels, and then the levels each had their own set, making just over 50 more effects. We used to give every effect a priority, so one effect could only interrupt another on a particular channel if it had a higher priority. That can be used to ensure that important effects get heard, or that long effects get to complete properly.

 

For the title music we wanted the coyote playing the piano and barking in the music where Jason had included that sound. For that, the music has to let the coyote animation know when to bark. That was a slightly odd communication, since the music player is playing on the interrupts and might cut across the main cycle at any point. I expect that a fairly simple global variable just shouted "Now!" when a particular sample was played. Many years later I was playing Mario on my Wii U and we saw the meanies shimmy in time to the music and I thought: "That`s a good idea! Wish we`d thought of that."

 

A1200 AGA version

We had a short while to get set up for the Amiga A1200 at the end of the project, and to produce an enhanced version. The thing I wanted to do most was get the game running at 50 frames per second, which the hardware was easily capable of. Initial experiments showed that I could change the definition a Second from 50/2 to 50. I would then have to adjust the control mode accelerations and top speeds, and reduce gravity. Oh, the power.

As I alluded to above, meanies that jump had their own upwards accelerations since it ultimately determines how high they jump, and how quickly, likely related to their weight, which of course we weren't simulating. There was another bunch of game objects that I realised would need adjustment: there were quite a lot of different pendulum platforms that needed to be slowed down, and I remembered how long it had taken me to tune them all up. Whilst you can pretty much just halve the speeds at twice the frame-rate, the accelerations need a bit more thought. It would also have meant a full and length re-test of everything.

I also remembered the days I had spent tuning up the runaway mine cart to get it working just so, and when I revised the speeds I had to re-do just about everything. I reluctantly decided that it was too much work in too short a time. Similarly re-doing all of the graphics in more colours when the originals took about 30 man-months wasn't a go-er. Knowing that the A1200 could do 2 play-fields of 16 colours each, we set about producing some backdrops in 15 colours, plus upgrading the sky colour fades, and get that parallax scrolling. The title sequence also got its own back-drop. We had the Coyote playing the piano in a hall with lots of animals looking on.

We dished out the level pictures to the graphics artists. The backdrops were just pictures, not made of character blocks, as there was plenty of video RAM since the whole game fitted into a half meg A500. That made the pictures easier to produce, the guys could just pick their palette and draw away. I can't remember exactly who did which ones now, but I do remember John Kershaw being particularly impressed with his undersea shipwreck, and I liked how Colin Seaman`s Sphinx on the Egyptian level had apparently huge size in the distance, plus the cool camel chewing away. "It`s all about the perspective." he told me. Another "trick" is that distance causes the contrast to reduce, so the palette colours get compressed a little. Colin is an amazingly fast artist and worked to a very high standard, I have a feeling that he did some of the other backdrops too.

I put some extra foreground rocks into the first levels and rigged them to parallax scroll with a simple multiplier. This helped the cave areas where you couldn`t see the parallaxing background layer.

The snow-bomb got a giant snow-flake graphic, made out of smaller parts. Plotting lots of objects suddenly became not a problem. It was all about enhancing the picture without having to re-tune and re-test too much, time was very limited.
 

On the jungle level we split the original background into two layers so that we could parallax scroll the trees from the other side of the river. I had to deal with the change in co-ordinates of items launched from the other side of the river, including the lumps from the volcano.

 

The game completed sequence was a complete upgrade as we could do a new luxury inside-the-igloo background. The original one was a bunch of animated characters just to show what it could do when there aren't too many sprites to plot.

 

Christmas Demo Version

 

 

We had the opportunity to produce a cover disk for Amiga Power. Being Christmas time, we based a level on the original snow level, and let Phillip loose with the graphics sheets. The Coyote got himself a nice red Father Christmas coat, and the penguins have party hats. John Lilley added a Christmas raft of pick-up presents and we had to build in an end sequence for the completion. We also had to put in a new one-level banner at the bottom of the screen.

 

 

 

 

CD32Version

We were loaned a CD32 and a controller in order to produce a CD32 version of Fire & Ice. We also had a development budget to pay for 6 weeks` work. Our SNASM development kit connected the assembly on my PC to the Amiga via a card expansion device, it wasn`t going to interface into the CD32. Our 6 weeks was going to be spent getting the A1200 version booting and running on the CD32, hooking in the CD32 controller with multi-button support, for the first time ever, and playing CD tunes from the disc rather than using chip music.

 

We had to cut a CD, which took a while back then, and the state of the CD writing software was such that they hadn`t got any buffering so you had to make sure the PC didn`t try to do anything else while it was making a CD or it would mess up.  

 

Jason created a new set of music on CD. He had better equipment at home so he stayed at home for a week to use his gear, including a Korg M1, Akai S950, Roland JV880, and Cheetah MS6. We had been using samples on the Amiga, but nowhere near CD quality, and the music was orchestrated by our software, creating full CD tracks was new for us. Playing CD music freed up the sound chip to just do the sound effects. As Jason noted, he  included ambient sound effects around the CD music too. The only issue is that to loop the music there will be a pause while the CD laser finds the start again.

 

 

 

 

Finally

This game felt much more like a team effort than, say Paradroid '90, as the direction of the game was being set by more of us. It taught me that platform games need a lot more variety in them than I expected, It was nice to finally do an Amiga-led project, and I`m especially pleased with how nice the A1200 version looked, and then how the CD32 version sounded too.