PROJECT STATUS 2023

With news that the Scorpion Engine now supports loading assets in and out of memory this opens up new possibilities for the continuation of this project..

As previously posted I was struggling with memory constraints to support even some of the basic stuff like weapons and throwing objects.

I’m yet to test out the new version, but the signs are promising.

Regarding time working on the project, yes I started this when I had lots of free time, since then I now have multiple game projects on the go for mobile/PS5 and 2 young children to bring up. So time is tight, but this news has given me incentive to try and find some time to see if I can get it moving again.

HOLDS AND AI PROGRESS

I’m working on 2 integral systems at the moment. Holds and AI part 3.

The holds mechanic is tricky as within Scorpion the player doesn’t have direct reference to a particular enemy, so we have do some some magic to make a link happen when the enemy goes into a stunned position. You can see a test below for the actual throwing mechanic:

So this is very much a work in progress but eventually it will allow for the punch, punch, throw combo and also those iconic knees to the head after kicking an enemy.

I’m also developing AI part 3 which will see the enemies start to choose sides instead of bunching together, currently I’m over complicating this but I’ve had some ideas over the weekend that will simplify this!

Lastly I now have the player hit, fall and death in place - this also work with lives and credits.

And.. the Z layering is fixed as part of Earok’s Scorpion updates, so now the players and enemies will appear in the correct order when moving back and forth.

BATTLE ZONES

One of the features of most beat’em ups is the camera stopping at certain points to allow for a battle before it will let the player move on.

In Scorpion we can achieve this using “Blocks”.

In the video you will see the blocks are placed along the floor and when the player collides the camera is stopped (they will be invisible in the final game).

At this point we also generate collision blocks either side of the screen (to stop the player walking out of the zone)

To control the battle zone I keep an enemy count (a debug display can be seen next to the player 1 health bar).

Once this count reaches 0, the collision blocks are removed, the camera is told to follow the player again and we pop up a little “Go” hand to tell the player they can continue.

GAMEPLAY FOOTAGE

Here’s some extended gameplay footage from a recent build, it has a few bugs and is obviously missing moves but it's really coming together fast!

A few new things it shows off are the Top and Bottom panels, so we now have functioning health bars, scores and a countdown timer.

Also you can see the palette swapping working with the Roper enemy being recoloured just before the level loads in.

Note: This video shows Linda but as I previously mentioned we will need some clever memory swapping to achieve this on Amiga 500.

Coming up next will be throws, jumps and knees to the head, expanding the moveset.. and I need to sort out the Z layering.

ENEMY AI IN SCORPION ENGINE PART 2

In this iteration of the AI I have improved the enemies ability to approach and also change sides correctly.

In this video you will see the enemy now tries to position themselves correctly on the Y axis as a priority, if they are too close on the X but too far away on the Y then they make diagonal movements around the player before trying to position themselves for an attack.

Apart from a slight animation bug when moving diagonally this looks really nice and almost completes this part of the AI which I call the “Engage” state. The last thing to do for this state would be to ensure they consider if an enemy is already attacking from one side, so they would choose the other.

In addition to this “Engage” state, next we will compliment it with a “Patrol” state. In the “Patrol” state the enemy will be coded to keep a distance and make less movements, possibly changing sides.

It’s likely this “Patrol” state will only be used if 2 enemies are already engaged with a player.

We can track this by giving the Player “slots”, if front and back slots are filled then the enemy can remain in “Patrol”, if a slot becomes free then they will switch to “Engage”.

MEMORY CALCULATIONS AND PLANNING

In my quest to squeeze as much of the arcade Double Dragon into the Amiga 500 + 512kb slow ram, I am now carefully planning how much memory each little bit is taking up. To reiterate we have 512kb of chipram to load everythng we need at any one time (Slow ram is only useful for swapping things in and out without having to do any disk loading). So here is some info I have gathered along with help from Earok and EAB members:

Overheads

• Kickstart 1.3 takes up 40kb

• The Display (5 bitplanes x2 buffers) = 115,200kb

So before we even start to load any graphics that is 145,200kb of our 512kb chip ram used up.

I have also worked out the following from looking at the buld.log output from Scorpion and then adding a new tile and a new frame:

• 1 x 16x16 pixel tile is 160 bytes

• 1 x frame of animation for Player or enemy avg is 2.48kb

  • Bolo’s frames approx 3kb as he is bigger

  • Also 1 frame of Bolo punching is approx 4kb as it is wider

• 1 x 16x256 pixel panel image is 8kb

So we can start to plan how we use up the memory and also prioritise the things that are most important. For example I now know that the cat on the bin took up nearly 1kb as it was 6 tiles big. But let’s add up what I currently have:

• Kickstart = 40kb

• Display = 115.2kb

• Map tiles x297 = 47kb

• Top and bottom panels = 16kb

• Billy frames x25 approx = 62kb

• Roper frames x13 approx = 32kb

• Bolo frames x13 approx = 41kb

• Music 12kb

• Sfx 30kb

In addition the following is loaded into slow ram:

• Code 8kb

• Metadata 40kb

So the current total being loaded into chip ram is 395kb, which you would think leaves enough room for at least another enemy? Not so..

Something I was not considering was that all the animation frames get X flipped and those versions are saved into chip ram separately!

In fact Billy’s frames total 124kb, Roper 64kb and Bolo 82kb. This explains why I’m running out of memory.

The actual total I am unsuccessfully loading in is 530kb - so we will need to do some more thinking about how we display the player and enemies without affecting performance but reducing the memory.

SPEED TESTS

I’ve been testing adding the barrel to the scene and it has revealed something I suspected - the more actors on screen (despite their image size) the slower the game will run.

I thought the game was running a bit quicker before I started to paste the legs onto the body, but couldn’t be completely sure as I had also added alot of code.

But it is quite obvious, that once the barrel is added that it is like adding another enemy to the scene, the player alone becomes 3 actors. See how the game really slows down as more and more actors are on screen at once:

So put simply, the game will run quicker if the legs are not seperate actors, as having 1 player and 2 enemies means 6 actors. When I did speed tests at the start I could do 4 - 5 enemies without any visible slowdown, so I will explore going back to using the full walking frames.

Weapons will still use the parent lock movement system that Earok implemented.

SQUEEZING THE MUSIC INTO MEMORY

In a previous post I mentioned my original 65kb mods would be too big to load into memory and this is still very much the case - I have budgeted about 12kb maximum for music.

So this had led me to explore different options - first using very low memory chip instrumentation - which as previously stated would give it a different feel - but would also require a major rewrite to adapt the tracks to those sounds.

So instead I tried working with the current instruments to see if I could reduce their size without losing the feel. This is what I came up with:

I worked out I can do all the original instruments for about 7kb (down from 53kb) by using a combination of upsampling and loops combined with tracker hex fades. Each protracker pattern takes up about 1kb so I have also reduced these to 5kb (down from 12kb).

I have also explored a no percussion version which works just as well in game and saves another 4-5kb, so I could end up doing it this way.

How I load / unload tracks will also need looking at but it’s encouraging to know we can achieve very close to the original sound for much less memory!

KNOCKING DOWN ENEMIES

In Double Dragon, the players and enemies walk around on a pseudo 3D map, so there isn’t really a floor or platform they walk on.

So to get them to fall down was alot trickier than it first looked. I mean this engine is designed for platformers so has jumping and falling built in but on our pseudo 3D map we don’t really have a floor so we need to do something else.

Change Actor Type

When the enemy receives a hit in the stunned position I switch to new actor that just has the fall animations. This actor has to be set up in a certain way otherwise we won’t be able to move it freely.

We have to ensure there is no collision detection on the Y axis, set the movement type to CPU and then most importantly set the speed to 0. This now overrides the Scorpions inbuilt movement code.

Initiate Fall

We then start the movement code, first setting Var1 to the current Y position, then Var5 to 6, we will use Var5 as a Y vector to move the actor up and down, decreasing it from 6 until it becomes minus.

Move Actor Position

Here we use a “While” statement to move the actor up from a starting point (Var1) into the air and back down again to the same point.

Each frame we decrease the Var5 value by 1, eventually it becomes a minus number so the actor will come back down again.

When the actor reaches the starting point (Var1) we then end the “While” statement.

Change Actor Type Back Again

Now the actor has reached the “floor” I change the type back to the main type and then change it’s animation to the Floor/Get Up animation.

Death

If the enemies health is 0 or below I play the Death animation instead.

And this is what it looks like…

FROM SCORPION TO FLOPPY DISK

One of the great joys of using the Scorpion Engine so far has been the ability to quickly create a working disk image (ADF) that I can copy to floppy disk (using a Gotek) and load up on my Amiga 500. For those not so technically minded on the hardware side (like me) this is just fantastic.

Double Dragon looking glorious on skyzoo73’s Amiga 500

In fact when it comes to physcial media I am very romantic in that I love everything about the whole ritual of looking at the box artwork, putting the disk in the drive and the sound of the floppy drive booting up. Then there is the anticipation of waiting for the music and Title Screen, and sometimes we were even treated to some insanely good demo music. Every element feeds into creating a much greater experience.

You cannot get this feeling from a digital file being loaded into WinUAE, so what I’m saying is I like to take the time to appreciate the craftmanship from the artists involved.

This is also why I insist on my physical disks displaying the original artwork. I hope my version of Double Dragon will join these very soon.

And on a final point about being romantic, I know there have been discussions on EAB regarding making the game for higher spec Amigas, but this is not what the project is about.

The main reason I started this project was as a tribute to my late father who bought me and my brothers the Amiga 500 (that still sits next to me everyday). So I have very fond memories waking up that Christmas morning, opening the wrapping paper on the Batman pack and then spending all day playing Xenon 2, Super Hang-on, Altered Beast and many others. Easily the best Christmas ever!

So the game is being made for this legendary machine.

ENEMY AI IN SCORPION ENGINE PART 1

Over the weekend I completed a first iteration of the enemy movement and attacks. Coding this in the Scorpion Engine is very different from doing it in C, but many of the concepts remain the same.

The whole thing works as one big code loop, so the enemy is always thinking about their next move.

Initilaise

First I initialise the enemy, in here I simply spawn their legs (see previous post about this) and then run the “Idle” code block.

Idle

This is where we return the enemy back to their default settings, in our case we set their Var1 (which controls whether they are attacking, on a ladder, being hit etc..) We set this back to normal which is 0.

And then we trigger the AI codeblock.

AI

In here we first check that we are in a state to make an AI move (eg. if the enemy is being hit they do not need to run this code)

We then check the distance on the X axis to the target (the player).

Check Distance X

First we check if the enemy is standing too close and should reposition.

If not, then we check if the enemy is outside of the attack range, if so we move the enemy using “Approach”.

And if they are in the perfect attack range we then “Check Distance Y”

Check Distance Y

If they are too far away we let the enemy “Approach”.

Else the enemy is within range on both X and Y axis, meaning they have a chance to attack.

Attack Chance

We now grab a random value, in Scorpion it’s called rolling the dice. If it lands on 1 I say we can “Attack”, otherwise the enemy is told to wait 10 frames (0.2 seconds) before being sent back to the “AI” codeblock above.

Attack

Here we can tell the enemy to select an attack type, again we can do a probablity roll of the dice to determine whether they should prefer one attack over another.

Approach

As mentioned above sometimes the enemy is asked to “Approach”, we can use the Scorpions inbuilt “move_atplayer” which looks really good.

We then ask the enemy to go back to “AI” after 5 frames (0.1 seconds).

To Conclude

So by returning to “AI” the enemy is constantly reassessing it’s choices, which makes for some nice AI. This iteration is not perfect, but it gets us pretty close to an enjoyable game fairly quickly.

Things to do next will be to get the enemies to consider which side they want to attack as right now they choose the nearest side. And if approaching from below they always place themselves ontop before moving to the attack range, so this will need fixing too.

PREPARING SOUND EFFECTS FOR SCORPION ENGINE WAV TO 8SVX

One of the main reasons for this blog is to try to put up useful bits of info that will hopefully help any beginners or indeed intermediates to get things done without too much pain and suffering!

One of those not so obvious things is preparing sound effects so they will work in the Scorpion Engine.

You will need 2 things (which are also free):

• Sound Editor - https://www.ocenaudio.com/en/startpage

• Converter - https://convertio.co/wav-8svx/

If like me you are using samples from the arcade original, import these into your sound editor and trim if necessary (you want to reduce the file size as much as possible)

Then convert the sample rate down to 22khz. If you go below 22khz you will start to lose the clarity, but this is fine and actually recommended for low frequency sounds like a “hit the ground” sound. So 11khz is good for these types of sounds and will half the memory usage.

Save to WAV format.

Then drop into into the converter listed above, this will output an 8SVX file that you can then use in the Scorpion Editor.

REDUCING THE GFX FOOTPRINT PART 3

First off the idea of using the Billy legs for Roper and Linda did not go well, they are actually very differnt so that was not an option.

But, since the last update Earok has been able to implement some very useful features into the Scorpion Engine that have helped me to reduce the amount of GFX we are loading into chip ram.

Scorpion now supports the ability to have a child of an actor, so this allows us to split the torso and legs up. This helps to reduce the walking frames and means we can also do lifts and other things that reuse the legs.

Also since last update I have now been able to load all the frames I need for Roper, Bolo and Billy into memory along with background tiles, SFX and music.

Using a few tricks we have at least the following moves covered:

BIlly - Punch, Kick, Uppercut, Knees to Head, Headbutt, Elbow, Throw Enemy, Jump, Jumping Kick, Hit, Stunned, Falling, Floor, Getting Up, Lift Barrel, Throw Knife

Roper - Punch, Hit, Stunned, Falling, Floor, Getting Up, Lift Barrel, Throw Knife

Bolo - Punch, Hit, Stunned, Falling, Floor, Getting Up, Lift Barrel, Throw Player

We should also be able to fit a few more things like jump kicks for Roper too. So altogether there will be alot of the moveset from the arcade.

The big sacrifice is losing Linda from level 1, but she will appear Level 2 along with Williams and Jeff.

LISTEN TO THE ORIGINAL MOD CONCEPTS

For those interested here are the original MOD concepts I did based around the original soundtrack and featuring some exquisite solo work from Cody Carpenter.

These tracks transfer into MODs about 65kb in size. So too big to use in Scorpion Engine at the moment. But we can still use this Title Screen version as we can unload it before level 1 starts :)

Electric Cafe · Double Dragon Amiga (with Cody Carpenter)

REDUCING THE GFX FOOTPRINT PART 2 / MUSIC DIRECTION

Yesterday I explored reducing the walking animation to 2 frames, initially I thought it could be a solution but after living with it for a day it just feels horrible. So the original 4 frames is a must.

After posting the video many English Amiga Board members had some good suggestions regarding using 2 “actors” to join parts together. Thank you for the suggestions. It all made sense so I have tried it out today.

I’m happy to report that it does indeed work without any visible signs of a performance drop, but I will have to keep an eye on that.

Not only that but I realised it would be possible to use Billy’s legs for Roper, Williams and Linda as they are very similar. Roper admittedly would gain some boots as a consequence but this would save us about 6 frames of animation, which is alot.

This solution would of course require palette swapping the indexes of images used by the actors for it to look correct. This is not currently supported in Scorpion but could be in the future.

So moving onto music, it is very obvious that we are already struggling for chipram even before music is loaded in. But I have been exploring options with this too.

I think my mod’s could easily be modded (no pun intended) to use very low memory instrumentation giving it a more demoscene/chiptune feel but still remaining funky.

REDUCING THE GFX FOOTPRINT

As metioned previously the Amiga simply can’t load in the amount of animation frames we need for 4 characters at any one time.

It’s actually worse than I previously calculated, I said we could do about 110 frames but it’s actually gonna be closer to 30-40 as I wasn’t taking into account the duplicates within those frames.

Scorpion doesn’t currently support joining bits together, as this would be a solution that would increase our frame count.

As currently we wouldn’t be able to support lifting the barrel as it’s 4 frames. Which is now alot of our budget. But if we were able to join the walking legs with a static lift torso, that would then be easily doable.

So our budget comes down to about 20 frames for player and 10 per enemy, which is rather limited. But I have been able to reduce the amount of map tiles by a third with hardly any visual difference.

We can however be artistic with how we use the limited animation frames, to still get a good feel.

For example:

Walking is something that currently takes 8 frames (4 for nomral and another 4 when moving up), which x4 charcters at once is 32 frames. I think we can reduce this by 3/4. See below, walking right is the 2 frame version, walking left is 4 frames.

For the attacks, Billy has a total of 16 frames for his punch / kick combos, I have reduced this to 7, by removing the 2nd punch variation and instead of the 5 frame roundhouse finisher he will just uppercut instead.

MEMORY LIMITATIONS

An issue I have hit early in development is I am running out of memory. Completely expected as I was not watering down any of the arcade assets upto now, and to be fair I was wondering how I was getting away with it.

That said, this is where I have to start considering all of the graphics that are being loaded into chipram at any one point.

The current limit I’m hitting is once I go over about 110 frames of animation frames at this size, it can runs out of memory. Combine those animation frames with 512 tiles and it is understandable. And this is without loading any music in.

So it is inevitable that we are going to have to cut a fair few animations if we are to have a variety of enemies on screen but there are some options available.

Looking at the tiled map I can easily edit it down to 2/3 of the original memory size without much visual impact, and can probably go alot further.

We can also cut the walking up animation frames from each character.

Each character has left and right punches, this could be reduced to one.

Also there are many frames for being hit and falling that could be reduced without necessarily looking worse.

These are all things to consider but I will test out alot of things to ensure we get the best result possible.

ATTACKS / HITS

Further on from initial testing I’ve been able to add some attacks and hits, so it’s starting to feel more like a game.

This is rather basic right now but it proves the code system works.

I’ll do the enemy fall animation next, and then move onto some better enemy AI.

The Scorpion Engine is proving to be very flexible, and I’ve set up a great work flow for feeding in animation frames from photoshop so that they are automatically aligned.

PROJECT RESUMED - TESTING INTEGRATION WITH SCORPION ENGINE

After seeing many videos online, especially a recent Street Fighter 2 demo by Neeso Games (who are also working on a version of Jackal), it got me thinking that maybe we could speed up development by bringing our existing assets into the Scorpion Engine and do some tests.

The Scorpion Engine is a fast and flexible game creation kit for Amiga, offering a modern Windows IDE for development.

The editor is a fine piece of kit designed by Erik Hogan - it takes the hassle out of many graphic & tech related tasks and offers many clever speed optimisations.

So I spent a weekend setting it up, including the tiled level 1, a player and some enemies. After some intial tests at 50fps it was clear that with Amiga 500 + expansion settings it wasn’t going to be able to support it without slow down.

Luckily the Scorpion Engine has a 25fps option (this was the frame rate we were initially targetting anyway). Using this option the game runs solid and feels fantastic, being able to support many characters on screen at once without any obvious signs of slow down. This is important as if a framerate is established from the start, your eye gets used to it and it feels good.

Check the test footage…

And see that Street Fighter 2 tech demo below:

PROJECT ON HOLD

As with all passion projects real work can get in the way sometimes!

But it’s not all bad I have been finishing music work on Tikipod’s Astro Aqua Kitty, which will be seeing a release soon on various platforms.

It’s actually my main job running Hyperlite which has been taking up the majority of my time, as we have just partnered with Homa Games to produce mobile apps. So this is completely full on for the time being.

Double Dragon work will resume when things settle down again, as I love working on it and can’t wait to get the time to do so.