Fixing Amiga Final Fight

Finalfight_amiga

In 1991, US Gold released what was the UK’s first available home version of Capcom’s monster hit Final Fight. The game was ported to all the home computer systems (even the 8-Bits), but the one which garnered the most attention was the Amiga conversion.

Many felt that it fell short of what the system could do, but was it an accurate assumption? Or did Amiga fans overestimate the computer’s capabilities?

Let’s find out!

The Beginning

Before we start, let me first express my complete and total realisation that this piece will undoubtedly win the top award in the “Most pointless topic for an article ever!” category, and with that we shall move on…..

There have been few games so absolutely and uniquely genre defining as Capcom’s amazing 1989 beat ’em up Final Fight. Indeed, it is the yardstick to which all scrolling beat ’em ups are judged even to this day, and it’s impact on modern gaming society can’t easily be overlooked. The fact that it is set in the same universe as the Street Fighter series (almost being a Street Fighter game itself before a name change) only adds to it’s appeal.

The game was a smash hit in the arcades, and at the dawn of the 1990’s, hungry players like myself were desperate for a home version. At that time the only home conversion in existence was for the brand new Super Famicom system (later re-branded as Super Nintendo in the West) which was then only available in Japan. Unless you were very rich or very stupid and could afford (or were willing to pay for) an expensive grey imported Super Famicom and equally expensive cartridge, you were figuratively humped if you wanted a shot at Final Fight in your bedroom. Make no mistake, at one time I nearly saved up enough to get one but chickened out as it was just silly money for a teenager to be expected to pay (my will wasn’t as strong when Streetfighter II was released for the SNES though).

Enter U.S. Gold, a dubious games publishing house who were famous for snapping up arcade licences and producing poorly made ports for the home computers. They had the task of bringing Final Fight to what was arguably the most popular home computer of that time – the Commodore Amiga.

My History

I first came across the Final Fight arcade game in 1990 whilst trawling the Golden Mile in Blackpool when I was on the annual pilgrimage with the family. I was a big beat ’em up fan anyway, but going from games like Double Dragon, Vigilante, and Gang Wars to this, well…it blew my socks off! Plus it guzzled at least £30 of my saved up holiday money (I’m serious!). In those days that was about half a year’s worth of hard car washing, but the game was totally worth it. I can still recall seeing Guy’s attack combo for the first time and the subsequent sound of my jaw hitting the floor. Nothing since has had the same ‘first play’ impact on me as Final Fight, and so it has a very special place in my gaming heart.

hqdefaultWhile on a day trip some months later, the Final Fight arcade game was still heavily on my mind. After a bit of wandering I stumbled across a small games store with a guy behind the till who looked like Mario’s granddad. On the counter there was a Super Famicom all set up with *Gasp* Final Fight plugged in!

It was beautiful! It looked perfect, and I wanted it so badly but I just couldn’t afford it, nor was I even prepared for even seeing it at that time. Bear in mind that the official Super Nintendo and it’s Final Fight conversion would not be released in the UK until 1992, so the Amiga version was the first port to hit this island of ours. Seeing the Super Famicom version felt like Indiana Jones discovering treasure, and even with the conversion’s shortcomings, anything that looked even remotely like an arcade game of that magnitude on a home system at the time was absolute witchery!

Later in 1991, I was reading a new copy of one of my favourite games magazines at the time – Computer and Video Games (C+VG). After getting a little excited reading the Streets Of Rage review, I flicked towards the back of the mag and *GASP*, there it was a review of Final Fight on the Amiga!

The screenshots looked AMAZING! Plus, the review itself was very warm, and awarded the game a respectable 80% overall. The EMAP games magazines at that time had a strange rating system, where 90-99% was phenomenal, 85-90% was really really good, 80-85% was a solid game, and anything below 65-70% was bullshit.

80% was decent, and already I had an image in my mind of how the conversion was to be, and was prepared for the perceived sacrifices.

FullSizeRender
My original copy of the Computer and Video Games Amiga Final Fight review.

Sunken

Some time later I was in and around the game shops of my local city and I picked up a copy of Final Fight for the Amiga for a fairly weighty price of £24.99. When I got home I couldn’t wait, so I ran upstairs, popped in the first disk, and was greeted by the amazing intro with that absolute beast of a title song. I watched it all the way through, and it really got me excited. Things changed when I started playing though…..

a8dc22-intro The first thing that I did was walk up and try to punch a bad guy and…holy shit! Where was the attack combo? Where was the grab move? Where was the stun move?  Where was the music? Where was the between level transitions and score roundup? Where was the end sequence after beating the game?

In a nutshell, all of those features had been left out of this conversion, so after over a year of waiting for the first UK release of the game on any system, Final Fight on the Amiga was a bit of a letdown when it arrived.

In the arcade game, you had the multi-move attack combo, grab moves, jump attacks, a splash/stun move, and the panic/special move. All of these could be combined and used in tandem with each other for some very varied assaults. On the Amiga conversion, each character was left with a single punch, a jump attack, and a variation of the special move. Needless to say, the review in Computer and Video Games seemed generous to say the least, and I actually wondered if they had even played the same game?.

The Good

After a while, I started to analyse the game properly and went through it about nine or ten times (not a hard thing to do really). I came to realise that the reason I had such a problem with this conversion is that it had a really solid foundation and had so much potential to be good, but some odd choices prevented it.

To start with, the graphics are great! The intro uses 32 colours to get a near arcade perfect recreation – even more accurate than the SNES version as it uses the original arcade text fonts.

55629-final-fight-amiga-screenshot-in-a-warehouses
The Graphics were pretty spot on.

In game, the energy bars have been placed outside and above the playing view area using a split screen method, which presumably makes scrolling easier, and that’s absolutely fine. Apart from that, any sort of screenshot was going to look brilliant, and at a glance you’d be hard pressed to tell it apart from the coin-op.

The sprites were ripped directly from the arcade machine using a home made ROM reader built by Programmer Richard Aplin, and they are MASSIVE! Furthermore, they move quite smoothly too. The backgrounds however, weren’t from the arcade, and were drawn by some graphics artists employed by U.S. Gold (one of whom is presumably named Ralph as his name appears a few times in the background tiles). Aside from a few blocky and bare looking sections, they are great too, with the Westside and Industrial Area backgrounds being my favourites. The game also has some really nice graphical touches, like how the player will bounce off the ground when they fall down, and the way weapons fall when you change them. Other things look nice too, like car bits flying around in the bonus stage, and it seems like a nice little gravity routine was made. There’s also some subtle background animation now and again like the swinging of the train handles, and water drips from pipes on walls. It’s just a few simple touches like that which you appreciate.

final-fight_17
The game had 16 colours overall. Doesn’t seem like it does it?

There have been compromises made in order to get the game running fast enough, but they’re hardly noticeable. The in game colour palette has been reduced to just 16 (4-bitplanes for you techy folk). This makes it all look a little drabber, with more muted colour choices and some greens standing in for blues in the shadings. That’s ok though as I always felt that it gave the game a gritty ‘Amigaish’ feel and injected a bit of home computer personality into everything. In a good way of course.

Honestly, back in the day, and without a direct comparison to the arcade game, you couldn’t really tell the difference. In fact, I actually think some parts look better than the Mega CD version which I felt was very grubby in the visual department, so kudos on that front. The palette reduction was NOT caused by being ported from the Atari ST, which is a common misconception. The Amiga game was made first, as was confirmed by Richard Aplin himself. The colour choice was all to do with speed, because less colours equalled a faster game due to having less strain on the DMA (Direct Memory Access). The parallax scrolling in the backgrounds has gone as well, but that’s ok as it’s not really missed at all.

There have also obviously been some frames of animation dropped for every character in the game which is to be expected, and that’s totally fine. I mean let’s face it, you don’t need the arcade’s twelve separate frames of animation just to make the player walk, or any more than three to do a move – player or otherwise. The choices made in regard to which frames were to be omitted are on the whole very sensible ones, and even some very clever ones too.  A few don’t seem so sensible though, and there are even one or two frames that only appear once and are never even re-used anywhere else in the moveset, even though they could be.

The basic mechanics of the game are all fine. The sprites move smoothly, the controls are responsive, and the collision detection is good with a decent margin and range. The other thing that grabs you is actually how fast the game plays. When there’s about two or three baddies on screen (plus your player) it’s actually quite speedy and it does nearly match the arcade game. This is especially so, given the tech it was made on (not even a 1MB expanded RAM Amiga, just plain old 512k with a 7MHz CPU). The slowdown when the screen gets crowded is a bit iffy but we’ll get into that later.

The sound effects are all meaty and have been taken from the arcade game, although they are a bit more ‘clicky’ and a little misplaced (E.G. Guy’s arcade spin kick woosh is now the bonus stage glass smash sound effect). However, they do the job well. There’s a pitch shift effect on them when you hit more than one enemy at once, and this is presumably to prevent sample stacking whereby if two sound wave forms which are identical play at the same time they will double the volume.

Interestingly, the game has a few sound effect samples from the arcade machine which are on the disks but aren’t used within the game at all. These can be listened to by opening the disks in a music/sample program like Octamed, Protracker, or something similar. The unused effects include:

– Cody’s uppercut sound effect
– Haggar’s combo finisher sound effect/grunt
– Haggar’s Piledriver yell
– Guy’s flying Kick “HI-YA!” yell
– The hit sound effect for the pipe weapon
– The crowd noise for the end of Level 2 Boss fight in the boxing ring

final-fight_12
Both bonus rounds were included.

The same is true for some graphics, as the disks contain the backgrounds for the missing elevator level and Andore cage fight, plus the sprite sheets for the two missing knife enemies Holly Wood and El Gado.

Icons for missing items such as the sword and all the breakable objects are on the disks too. These include the drum can, the telephone box, the crate, the barrel, and the bin.

It’s odd to have so much missing in the actual game yet have all this stuff taking up space on the disks which isn’t even being used. One can only assume that more was planned for the game, but development time simply ran out.

The Bad

Ok, let’s get this out the way – this article isn’t just some excuse to slag off Richard Aplin, nor is it an attack on his programming skills. I have a huge amount of respect for the man, and he is a ridiculously talented programmer whose other Amiga and Amstrad games I have enjoyed immensely. 

Nevertheless, the conversion does fall short on a number of features and that is what is being discussed here, not anyone’s reputation. The game is very cleverly coded and it’s a smooth ride, but I just think there were some odd choices made with the gameplay. To me it feels like everything else got priority over the actual player characters, as the game has all the levels, almost of the weapons and just about all of the bad guys, yet SO many of the player moves were missed out.

Coming down to potential reasons for this it could be that:

1. U.S. Gold gave a measly 4-6 months for the game (on Amiga AND Atari ST) to be fully completed in, and there just simply wasn’t enough time for a one man team to get anything bar the most basic game skeleton done.

2. Richard Aplin has stated that he simply wasn’t into these types of games. That’s fine though. There are games that are insanely popular which I find quite dull, and it’s all a matter of taste. However, if you don’t “get it” then it’s going to be hard to try and replicate whatever “it” is. In fact, Amiga Final Fight is a classic example of ticking all the boxes but almost completely missing the point, becasue something got lost in the translation (that and actually having no time to fine tune the gameplay). Don’t get me wrong, if someone asked me to port something like Command & Conquer then I’d probably leave out a lot of what made those games tick too, because I find them insanely boring.

The enemy placement is very random when compared to the arcade machine, and due to the complete absence of any breakable objects, there’s items just lying about in clumps all over the levels. This makes the whole thing feel sort of like an early build which was released before the development time ended. The game starts by just dumping you in what seems like a random position somewhere near the start of the first level, and right in amongst a huge gang of bad guys too. In fact, every level starts pretty much this way, yet there are massive sections of each stage where you are just walking from left to right with nothing happening. The Boss Abigail appears a few times as regular enemy Andore Jr. and nothing really seems spread out any more. For example, Andore first appears on Level 1 when he is a level 2 and onward enemy

There’s zero in game music too, and this isn’t the fault of Richard Aplin either, as apparently U.S. Gold didn’t even hire a composer to do any tunes. In fact, I recall reading that Mr Aplin bugged his bosses again and again to get someone in to do a few tracks, but they were just too cheap to hire anyone.

Another thing is the enemies AI. They  all seem to have the same basic AI pattern, like it’s been copied and pasted for each instance.

final_fight_one_amiga_07
Crowd round and batter in!

The routine goes something like this:

– Always move towards the player
– If far away then move fast (run for some)
– When closer slow down and walk
– When close enough then attack

That’s it! Every single enemy bar maybe Belger (who is just called “Boss” here) or Roxy follows this routine. Belger actually has an interesting pattern which makes him back off and hover, and if that code were put in one or two of the lesser enemies such as Axl or Two P, would have made the game much more varied.

Another issue is that the enemies tend to corner you, and when that happens, it’s curtains! Most beat ’em ups will have what’s known as a breather or ‘ground’ routine for enemies, and this basically means that when your player has been knocked down and is on the ground, the enemies back off or stay still. This allows you to get up without being slaughtered or knocked down again right away.

Amiga Final Fight doesn’t have this feature, nor does it have any sort of hit count whereby you get knocked down after a certain amount of enemy punches. Due to this, you just stand there being pummelled until your energy runs out, and becasue your punches are so slow, the fire button doesn’t even register the input as you’re constantly being hit. With this, you regularly find yourself in a situation where enemies just crowd round and batter you like a fish – even if you are on the ground. Haggar can usually escape from crowd maulings, but most of the time Guy and Cody have no chance, as their panic moves are pretty much useless.

Enemy “clumping” happens too. This is when multiple instances of the same object follow the same code routines for moving around the screen, and two objects can appear as one if the animation speed and X/Y-Coordinates are the same. Without some variety in the AI to maybe recognise this and get one to randomly stand still for a few seconds or break off to the other side of the player, it happens quite a lot.

Fixes?

Now we get to the nitty-gritty, and if you’ve made it this far into the article then congratulations on being the only other person on the planet that gives a shit about this!

Over the years, the conversion has usually been blamed on hardware limitations or poor coding, but it’s not that. It was a case of not having enough time to refine the gameplay, and with just a few compromises in favour of the player thing could have been different.

Now we’re talking bare minimum changes with what is in the game already, so playing it smart is the key. If you make a few small changes to the existing game then add them all up, you can make some really big ones that would drastically improve the play.

Remember, this is an Amiga 500 with 512k of RAM, so it’s all about shifting things around to improve what’s already there rather than adding loads of stuff and aiming for a 100% accurate port.

– The Attack Combo.
In the arcade, Final Fight’s meat and potatoes – and arguably the thing that made it great – was it’s phenomenal attack combos. These were done by mashing the one attack button (a redefining feature from the old Double Dragon style separate punch and kick buttons). If you are just punching the air, then your character will just keep doing a jab type attack. However, when you make contact with an enemy, the player scrolls through a sequence of badass martial arts moves.

The characters combos in the arcade game are as such:

Guy – Jab, Jab, mid-punch, elbow, spin kick
Guy Full Combo

Cody – Jab, Jab, mid-punch, uppercutcody2

Haggar –  Jab, Jab, Hammer punch

haggar2

Now, the Amiga game changes this. Instead of doing a combo when you hit an enemy, you just keep on jabbing them until their energy is down to it’s last point which then triggers a finishing move. In this case, it is the end move of the arcade attack combos for each character (bar Guy who’s spin kick is replaced with his jump kick animation)

Not only does this make the gameplay hugely monotonous if your enemy has a large energy bar, but it leaves you open to attack from behind too. You can’t turn around either as the enemy you were hitting previously is still standing.

With just a small edit in the code there could have been a cut down version of the combo implemented, whereby you do two jabs and then a knockdown move like so –

Guy – Jab, Jab, Jumpkick
Guy New Combo

Cody – Jab, Jab, Uppercut

Cody new

Haggar’s combo would now be identical to the arcade, with a *Jab, Jab, Hammer Punch* being in place.

haggar21

Implementing this system wouldn’t require anything new. The enemies all have a *knock down and get up* routine from when the player hits them with a flying kick, so all it would take is placing a jump to the knockdown routine at the end of the combo.

Strangely enough, this *Jab, Jab, Knockdown* combo trick was used in the Amiga Port of Double Dragon II which was also programmed by Richard Aplin and Creative Materials (then Binary Design). It is considered to be one of the best arcade conversions on the system, and one of my own personal favourite Amiga games. Why they didn’t stick with that attack pattern for Final Fight I do not know.

– Attack speed & states

This part is a little geeky but bear with me…..

Amiga Final Fight is a smooth but pretty plodding affair. Haggar is really the only enjoyable character to play as becasue his pile driver move is sort of fun, and it’s effective too, plus his jabs/punches have a good reach. Playing as either Guy, or especially Cody is a death sentence, as their jabs are just so slow that the enemies can actually nip in an attack between them. There’s a reason for this. When you press fire to punch, like the arcade game, your player goes through his jab animation. However, in the Amiga port, if you press fire WHILE your player is doing their jab, then nothing happens. In other words you need to wait until the jab animation has finished it’s cycle before you can punch again. Add to the fact that the animation speed for the jab is set puzzlingly slow, and it make the game feel incredibly sluggish.

This is (I’m guessing) most probably due to something programmers use called states. Most programmers use versions of states, or player modes, or some sort of system which tells the computer what the character is meant to be doing, and it was no different back then. What this means is there is a state that your player is in for each action, and that state holds code for whatever the action is, plus extra code for what you can do within that state in order to branch off and go to other states.

There’s a state for standing still, there’s a state for walking, there’s a state for punching, and there’s states for jumping and everything else.

Now, in order to switch from state to state you have to put in a condition that will allow you to do so if an certain action is performed. Think of it as rooms that the player is in, and doors which lead to other rooms.

For example, if the player is in a “standing still” state (room) there will be a condition code in that standing state which says that when a fire button is pressed then it will go to a “punch” state (there will be a door to a punch room).

Punching state
No “Re-punch” trigger would be available while the punch state is active.

Now the problem is that while the player is IN his punch state (room) there is no condition that says if fire is pressed again then punch again. The animation cycle has to complete before the “standing still” state is returned to and activated – hence the press fire to punch code becomes available again. In other words, there are no doors in that room.

This makes the already sluggish gameplay feel even more swamp like, and it could have easily been avoided by putting the condition for activating a punch WITHIN the punch state itself. So, if fire is pressed while the punch is happening it will loop back round and make the punches faster. This of course would only be for the initial punch and not the combo moves themselves, plus a breathing room of a frame or so would be needed, but that’s just a simple piece of code involving a countdown timer or some similar form of delay.

The arcade game has this feature in it. You can tell this by rapidly pressing the attack button and the punches will match the speed.

If this was implemented PLUS the previously mentioned cut down attack combos, then it would have accelerated the gameplay mechanics a good deal just with those small code tweaks alone. The actual speed of the game though would not have changed, but it would FEEL faster.

– Jumping & jump attacks

One of the more strange features of Amiga Final Fight’s game mechanics is the jump system. If you push fire while standing still you punch, but if you tug the joystick left or right and to walk and THEN press the fire button, you do a combined jump and flying kick. Same if you push up and fire you get a jump kick.

This is ok, but the move is coded so that you don’t actually reach your kick until the decent of your jump arc which opens you up to attack on the ascent (although you can still hit an enemy on the up). It would have been better to just make sure the flying kick activated on the ascent of the jump and hold it.

To be fair, the jump attack actually isn’t that bad, but the special moves certainly need an overhaul. In the arcade game, the spinning special moves for Guy and Cody would span the length of the ascent and descent of the stationary attack jump, and basically floored everything on the screen. In the Amiga version it only fires off once you reach the peak of your jump and you spin down which, you guessed it, leaves you open to attack on the way up. It doesn’t even knock some enemies down as they just go into a “hit” state rather than a “fall” state (this happens with the pipe weapon too), and the collision range for the special moves is quite narrow. Poor old Mike Haggar has had his spinning special move removed completely in favour of a makeshift piledriver which uses the jump animation frames. Ironically, it’s one of the more practical and fun moves in the game, but an effective crowd control move would probably have been better.

Pile
Makeshift vs. real piledriver. Nice shadow on the upside down baddie’s feet on the left.

– Enemy Clones, missing moves, unused data and memory space

Final Fight features a variety of enemies, and those enemies have what are called clones or palette/head swaps. This just means it’s a slightly different graphical version of an enemy to add some visual variety, but they are all based on the same model and do exactly the same thing.

The basic low level goon is Bred, and his clones are Dug, Simons, and Jake.

Clones
An example of enemy clones. Bred, Dug and Jake.

Higher goon clones of other characters appear too, and usually come in pairs, such as Axl and Slash who are based on the same model. Other palette swaps include Poison & Roxy, J & Two P, and the three fat men: Bill Bull, G.Oriber, and Wong Who.

The thing that strikes you about Amiga Final Fight is the massive number of player moves and animation frames that are missing from the game. At first I suspected this was most likely down to storage memory restrictions of the floppy disks as all the frames of animation probably couldn’t be included, but it wasn’t (see later in the article).

It’s face squintingly baffling then that the game includes nearly every enemy clone that was in the arcade machine, and each clone does exactly the same thing, yet the sprites take up valuable memory. It may very well of course be the case that only the heads of the enemy clones are stored and the bodies are simply recoloured in a palette swap by the game’s code. However, I’ve looked at the graphics in a data reader, and all the clones seem to have their own full sprite sheets, plus the palette seems to be static, so it’s unclear how any colours could be changed without affecting other sprites and backgrounds.

Being the saddo that I am, I sat and worked out that each player just needed about an additional and generously estimated ten or so select frames of animation to reinstate the missing moves to some degree with maybe a frame or two missing.

13281769_10153566878447314_1231430582_n
The unused “Holly Wood” sprite sheet which is still on the disks.

Bearing in mind that there is stuff on the disks that isn’t even being used (the aforementioned sprite sheets for Hollywood and El Gado), and so if that was binned, plus the clones, and maybe the glass breaking bonus round, then there would have been room for most of the animation frames for the player’s missing moves to be reinstated to some degree.

Now, if you add all this to the previous attack speed and attack combo tweaks you are now looking at something which much more resembles the way the arcade game plays. However, nothing has really been added, it’s just shifting stuff around a bit and replacing one thing with another.

With all this being said, storage space wasn’t the problem. The two floppy disks are only at around 86% and 59% capacity respectively, which means that there IS room for more graphics and presumably music. The only real memory that matters in these games is the amount of accessible RAM that is available to hold all the graphics and audio for instant use within the game. 512k couldn’t have been much to work with, but I’m not sure the expanded 1MB RAM makes any difference when it’s detected. I certainly didn’t notice any new sound effects or graphics being used when the extra memory was available, and from what I gather, it just arranges a few sprite tables a different way.

– Sprite routines, on screen enemies, and slowdown

As mentioned previously in the article, the game actually zips along really fast, and once it gets going it can be good fun, despite the limited moves available. The problem here is that it suffers from slowdown. The game for some reason allows up to SIX different enemies on screen at the same time as well as your player(s).

It’s unclear whether the on board Blitter chip was used for drawing the character sprites (it was certainly used for background drawing and scrolling), but if one compares the Amiga and Atari ST ports, there’s really not that much difference in speed, and the Atari ST drew all graphics using the 68000 CPU as it did not have any hardware support. It wouldn’t surprise me if the same CPU driven sprite drawing routine was used on the Amiga as well as the ST, as that would make duel system development much faster (rather than writing two drawing routines for each system). This would account for the similarity in speed between the two systems, despite the obvious hardware advantage of the Amiga.

Regardless of what was drawing the graphics to the screen, the main issue was the single layer which was shared by the sprites and the background. Sprites and moving screen objects have to go through phases before they are drawn to a single layer screen. These are:

1. Copy a section of the background that is equal to the height and width of the sprite to be drawn, and where the sprite is to appear on screen, then save that background section in a buffer (a reserved piece of memory)
2. Paste the sprite (replacing the background pixels)
3. Mask out unwanted pixels from sprite via AND and OR bitwise operations
4. When the sprite is to move again, erase the previous frame by pasting the stored background from the buffer, recalculate the sprite’s new position, and go back to step 1

Below you can see a visual representation of what generally happens (this is heavily simplified, but it’s what the Amiga has to do for moving screen objects on a single layer which is shared with the background).

SpriteRoutine

Quite cumbersome, and lots of extra stuff for the hardware to do which would add to slowdown.

Even if the Blitter was used for sprites, it was a great piece of kit for 1985, but by the 90s it was a little creaky and slow, and Commodore never updated the technology for the later Amigas. Handling sprites of Final Fight’s size on an old 1987 Amiga 500 (via CPU or other hardware) was always going to be a task and a half. Even with clever tile replacing routines to save buffer space, it’s still an awful lot of extra checks and extra drawing per frame to be done just to clean up the background on the single layer, and so a bit of bottle-necking was inevitable.

A more sensible approach would be to take a leaf out of the SNES’ book and have a maximum of two or three enemies on screen at the same time and just give them a little more of a vicious AI. Maybe also include some stop points within the levels too so enemies can come at you in waves of three at a time, and the system wouldn’t need to deal with scrolling. Of course, in two player mode some slowdown would be expected, and that’s ok. It’s an Amiga port after all, so it’s unavoidable (Christ, the Double Dragon arcade game slowed down like hell, but it was still a smash hit). However, with this tiny change added on to our ever growing pile of small changes, it would just make it that mite zippier, and every little bit counts. This is all assuming you have the time to do so.

– Atmos

The final thing to do would be to put in some music. I know for a fact that Richard Aplin got the amazing intro music from the Amiga demo scene (you can listen to it here). The composer, Jolyon Myers (known as ‘The Judge’) went unpaid for his trouble, although Mr Aplin – ever the fighter for truth and justice – did try to get U.S. Gold to pay him, but again it didn’t happen. I think the notoriety that Jolyon Myers received from having his track included may have been payment enough, as his song has now become synonymous with the game (in a good way) as, and it is much loved by retro enthusiasts to this day.

protracker-3-15
Random image of Protracker, becasue you can’t see music.

All that would be needed is just maybe one or two more in game songs. It would have added a great deal of depth to the atmosphere of the game, and broke some of that nasty sterile feel. In saying that, a game like Final Fight would have been an audio head scratcher on the system. The Amiga had some great sound capabilities, but it only had four poxy channels which limits musical layering, plus it largely prevents having sound effects and music at the same time.

Any composer would likely need to limit the music to three channels and leave one free for sound effects. Any voice samples would preferably need their own channel to stop them clipping the sound effects, which would leave a very meagre two channels for music – and that would never do. The A600 and beyond should have had six or eight channels, but again Commodore never updated Paula (the audio chip) for any of the post 1990 Amigas.

With all these tweaks in place I think that the game could very well have earned that 80% it received in C+VG, and perhaps even a dash more. It wouldn’t be perfect, but let’s be honest – as Amiga owners we were never looking for nor expecting perfect. Just decent!

Remake?

20776_front
The Amiga box art featuring no-one from the game but Synthol-Man instead!

There was a gent from the English Amiga board forum who went by the name Leathered, and he did start to do a “from scratch” port of the game in Blitz Basic called Final Fight AGA for the Amiga 1200. You can check out an early video of it here. Unfortunately, Leathered sadly passed away from cancer in January of 2016, and the game, which was his passion, only reached somewhere around  v1.5. Some members of the community are, I think, trying to honour his memory by completing the conversion, but it just shows that the passion for a project of this sort is out there.

Reputation

Final Fight on the Amiga, from a technical point of view, is an extremely well programmed game. The code used some very clever dynamic-defragging memory management and background loading/decompression for the sprites. As such, the game actually runs very smoothly given the hardware it’s on, becasue the Amiga 500 wasn’t as powerful as some folk like to make out, and certainly nowhere near a Capcom CPS-1 board.

In fact – and it pains me to say this – Final Fight was simply too much of an advanced game for The OCS/ECS Amigas. The 7Mhz CPU just couldn’t keep up, and even 1MB of RAM was incredibly tight (let alone 512k). The Amiga’s technology was made in the early 80s when things like Pac-Man and Marble Madness ruled the roost, and Final Fight was made on state of the art arcade hardware almost a decade later. Had the game been made for the Amiga 1200 with its 14Mhz CPU and 2MB of Chip RAM then it may have stood a chance. Richard Aplin’s technical wizardry is the only thing that made it run as well as it did on the older Amigas, but the problem is that most regular game players don’t give a shit about the behind the scenes wizardry and only care about the gameplay, which obviously fell short.

To Richard Aplin’s credit, he managed to rip the graphics from a bare-arsed arcade PCB board using hardware he built by himself, and then wrote the whole game from scratch including tile mapping editors on his own in 68000 assembly code (Fuck!). All this with a time limit of a few months to do it in, and he was only about 21 at the time. If there is a real life Tony Stark out there then Richard is probably the closest thing to it.

In fact, the technical level of Amiga Final Fight is rather off the scale for the machine, as you can see by this quote from Richard:

“I dearly wish I’d managed to directly run the arcade PCB’s gameplay code on Amiga Final Fight for example (which I did look at for a good while, but it was just too risky a path to sink any more time into) because it’d have been great to just leave that exactly as it was – not that I personally was a huge fan of the arcade board – it’d have ultimately saved me a lot of work and left people less to be unhappy about…

Nowadays with IDA and MAME as tools to aid the process it’s probably just about manageable but it’s fair to say the Amiga spent maybe 85% of the cpu/bus/ram managing+drawing graphics pixels compared to the CPS board 68k spending at a guess maybe 10%.

I remember being most satisfied getting stuff like the realtime sprite loading+decompression working (it used cooperative multitasking for loading+decompression and was constantly moving everything around in memory to defrag it incrementally; as stuff was deallocated the ‘holes’ bubbled to the top of memory – everything happening in small chunks to not affect the frame rate).

If I recall correctly, when you play that game on a 1MB machine you actually get slightly different sequences of enemies because it decided on the fly whether to reuse an existing baddie in RAM or if there was enough memory reclaimable – and time for disk loading – to pull in the one it was intending to give you to fight… Oh and Codetapper reminded me it if you have 1MB RAM it generated a 128KByte lookup table to make the X-flipping of the sprites that much faster.”

~ Richard Aplin, Oct 1st. 2015

I think this well and truly disproves anyone who calls this port “Lazy”, as the level of innovation and effort really is quite something. From the look of things, Richard got a lot of what I would consider undeserved flak for Final Fight. However, he appears to have a good sense of humour about it and still seems to take an interest in the game and any potential amateur conversion attempts of it. What with the advent of the internet, I think he’s finally getting a chance to tell his side of the (now surprisingly infamous) story. This has undoubtedly made a lot of people change their opinions, and re-direct their venom solely at U.S. Gold. Even at that, I’m surprised he’s not just gone back and released an unofficial tweaked version of the game just to shut folk up.

Either way, from what I gather he now works on technical non-game projects with no user facing front end (ie, nothing for tech-ignorant plebs to complain about). Whether this is a result (even partially) of the insane poison he got for Final Fight is unclear, but for a 21 year old I’d imagine that taking such a huge amount of shit would be a bit of a downer. On the other hand, maybe his true strengths lie in the technical side of things rather than the artistic, as he does seem to be more proud of the coding tricks in the game rather than the game itself. “Fair play” one might say.

As for the game, bar a slightly limited palette, the graphics are great, and the game does tick all the boxes for a scrolling beat ’em up. However, due to the limitations of a lowest spec Amiga system, there was just too much stuff left out to make a decent facsimile of the arcade machine.

As much as I have a very strong technical admiration for the conversion, I still always felt that it was a bit of a waste of some perfectly good graphics and a really strong foundation. Indeed, the very title of this article is somewhat of a misnomer, as there’s really nothing to “fix” about Amiga Final Fight. Rather, I feel it’s more a case of “finishing” rather than “fixing”.

At the end of the day, I’m perfectly aware of what an obsessive old weirdo I am for going into this much detail about an ancient game conversion that no-one really cares about. This is especially true since MAME has been able to give you the arcade game in your home for a number of years now, but I attribute the interest to the lasting power and appeal of Final Fight itself. The Coin-Op was the number one arcade game of 1989, and is widely regarded as not only a bonafide classic, but a milestone in the gaming world, and a landmark in the beat ’em up genre.

The question is, why does a grizzled old wizard like me even care? I guess it all comes down to the fact that the lasting impression of that first arcade play experience really lingered, and when the Amiga game was so close to being on the money, it was just frustrating to see that it missed the mark by a hair’s width.

But, why attempt even a theoretical fix of it?

As George Mallory once famously said when asked why on Earth he would want to climb Mount Everest, he replied…..

“Because it’s there!”

15 thoughts on “Fixing Amiga Final Fight

  1. Ha that was great 🙂 Very fair; yeah the gameplay didn’t get tweaked as much as it could have. It probably isn’t incredibly hard (using modern tools, i.e. an Amiga emulator) to rewire the gameplay that you dislike (e.g. player character fighting move sequencing) but leave the rest of the engine intact. If I recall correctly (i.e. possibly not) that with enemies that used recolored sprites the recoloring was done when they were loaded as opposed to them being stored on disk. I do remember that if you had 1MB ram it ran a bit faster (it put a 128k sprite flipping table in the top ram) plus you’d see a greater variation of baddies (I think) because it cached them in the extra memory (could be wrong about that). Anyway thanks for your detailed look at the game; I was really pleased with the technology parts (background loading and decompression, incremental defragging of ram, etc), but I agree it wasn’t super fun. I played the original on MAME recently just for amusement and wasn’t dazzled by it, although I know it has a lot of (very hardcore and vocal) fans.
    Cheers!
    Rich Aplin

    Like

    1. Thanks for the comment Rich. Glad you thought it was fair as it was meant to be more of a “what if” rather than a moan about the development. I do appreciate the “under the hood” tech a lot more these days so the game is actually quite layered in that respect. At the very least, people are still talking about it 26 years later and there’s not many out there who can say that.

      Like

      1. I seriously doubt that Richard has kept the source code all these years. A homebrew version is the most likely chance today.

        Like

      2. I’m sitting here, at the end of 2018 (in front of my sweet 5-monitor rig, typing away using modern debuggers and coding in python and enjoying every iota of joy that modern technology brings), LOLing – alas, no, that source code is long long long long gone. 😉

        Like

  2. I really enjoyed this, thanks for taking the time to write it 🙂 I wish there where more detailed in depth articles about Amiga games! Cheers!

    Like

    1. Thanks for the kind words. I may do some more game related articles in the future as the Amiga was a huge love of mine back in the day.

      Like

  3. Oh…My english is not so good but I could detect a very nice prose.
    A pleasant read. Please catch your courage using your hands, a pen with your foot and write about Double Dragon 2. I promise I’ll be back to read it.

    PS : I’m not drunk.

    Like

    1. Yeah the arcade ports on the Amiga were usually dreadful. The curse of being Third party licences I suppose.

      I saw that Final Fight video a while ago and I’m pretty sure I know the guy who made the game. He used to live across town from me and he was always talking about doing something like this. No disrespect to Richard Aplin, but I wish the official version was like that.

      Like

Leave a comment