Double Dragon - Arcade port in C

[skyzoo73]

Update 15th September 2020

"SETTING UP FOR 2 PLAYERS

Something I forgot to mention in the last update was that we have set up the game to work for 2 players. These players now live in our gameWorld environment and we can can use the same PlayerState code for each player."


http://www.electriccafe.xyz/double-dragon

[skyzoo73]

Update 16th September 2020

"JUMPING AND BOUNDARY COLLISION

Something I was excited to see working was the code I had previously written for jumping. It works by taking note of the starting Y pos. We then calculate how much positive or negative speed to add to the Y pos each frame:
yvector = yvector + gravity;
The Y vector is our jump speed in the above code, we add gravity to it each frame to reduce it. This means after a certain point the Y vector will be come negative and this will bring the player back down again.
The following code updates the Y pos each frame by add the Y vector it, initially this is positive taking the player up, as it turns negative the Y pos starts to return to it’s original position.
ypos+=yvector;
When the Y pos returns to the starting position we then change the player state to idle and the jump it finished.
Boundary collision is fairly simple, after we have calculated all the movement we do a final check to see if we have gone beyond our set boundaries. I call a function to do this, checking both the left and right side of the screen:
if (xpos>277) {xpos=277;}
if (xpos<1) {xpos=1;}
So if the player had moved to X pos 280 on the right side of the screen, the code moves it back to 277. Doing the check after all the movement is calculated ensures we don’t get any weird jerky movement."




http://www.electriccafe.xyz/double-dragon

[skyzoo73]

Update 17th September 2020

"BASIC MOVESET & LINKING COMBOS

The following clip shows we can now trigger all the standing moves, and we can link punches and kicks together. I.e. We can go from Punch2 to a Roundhouse or from a Kick to an Uppercut.

We do this by assign a combo value to each move. So Punch1 is 1, Punch2 is 2, Uppercut is 3, Kick is 2 and Roundhouse is 3.

We use a combo timer to keep track of the linking, if the player is still within time they can go from Punch 1 to a stronger move, if the time runs out the combo value is reset to 0 and they start with the basic punch and kick again.

In the future I will probably allow finishing moves to be performed on stunned opponents, aswell as part of a combo. But we will see.

Watch the Player State at the top to see the moves being linked. Tomorrow we will draw some hit boxes to really show off the moves."




http://www.electriccafe.xyz/double-dragon

[skyzoo73]

UPDATE 26th September 2020

"Quick Catchup

Just a quick one to say we’ve making loads of progress on a variety of things which I will detail more closely in future updates.

The default moveset is now complete, we added the back elbow and headbutt last night. It works brilliantly, even with one joystick button it all feels good.

We are also prepping for how we are going to bring in the graphics, bearing in mind we will be switching the palette between levels. What I have discovered is that with some very careful planning I have been able to retain all the depth of the arcade sprites and most of the background details, just by being economical and artistic with the palette choice. This improves upon the initial mockup at the top of this page.

I was never a fan of the woods graphics, and noticed they changed this in the GBA version, so I have done a rework myself providing a far moodier setting over the garish original.




In a future update I’ll do some proper sprite and background comparisons.

In addition we are setting up hitboxes, animation systems and enemy AI and I’ve completed pretty much all the music."



http://www.electriccafe.xyz/double-dragon

[skyzoo73]

Update 3rd October 2020

"Tilesheets & Tilemaps

As is standard with old games a tilesheet and a tilemap are necessary for building the levels. I have been working hard to create a dedicated palette with 10 swappable colours per level. Using this I have been able to create an indexed colour tilesheet. The tiles are 16x16 pixels.

To create the tilemap I am using Tiled, a great piece of software by Thorbjørn Lindeijer. A great feature is that the tilesheet can be updated live, so I can have Photoshop open and tweak bits and see it update live in Tiled. Very cool! I have used this to tidy up a few bits that looked a bit off.



Tiled can export a .csv tilemap file which basically gives you a bunch of number in rows that correlate to the 16x16 tiles in the tilesheet. We can import this data along with the tilesheet and rebuild it in our code. So you get something like this:



Once all the elements come together, the mock up below shows the exact assets we will be drawing to the Amiga screen (best viewed on a CRT!)

This mockup uses 32 colours and a 256x240 resolution (same as the arcade)."



http://www.electriccafe.xyz/double-dragon

[redblade]

Amazing work, what number out of the 32 colours are then 10 changable colours? Are they in the sprites? or are they mixed, 5 sprites, 5 lower 16 colours.

Once again, it looks amazing. Will the final game be 256x240 for speed or are you going to try to push for 320x240?

[lmimmfn]

Looks fantastic, keep up the great work!!!

[kriz]

Damn, tasty !!

[skyzoo73]

Update 4th October 2020

Palette

"As talked about in the last post we have 22 essential colours (including transparency). These are loaded into memory at the start and do not change.

We then have 10 more colours loaded into memory that we can change when loading the next level.


The Amiga uses 12 bit colour, and you state each colour using a 3 digit Hex value. The arcade also used 12 bit colour so we have access to the same colours that it used. The arcade however displayed upto 384 colours on screen, we have only 32 colours to work with.

What usually happens when reducing the amount of colours is you lose all the depth out of your graphics. With the dark colours often being overlooked in favour of a variety of palette. What follows is usually a bit of a garish mess with no shading and a flat feel.

I have paid particular attention to retaining the depth of the original graphics, so although the colours may be different the level of grading is the same. Take the car for example.


The arcade version on the left uses 7 reds in total, with it being the only place on the level reds are used that much it would be a waste to dedicate that many colour slots just to the car. That said, the car is very iconic so it has a priority. In this case I have dedicated 2 colours to it, 623 and 823.

The darker shades come from skin tones and Jimmy’s reds in the essential list. So by grading between the pink tones of Jimmy and the brown tones of the skin we are able to create very smooth grading over 6 colours for the car. Hence we retain almost all the depth of the original graphics (we lose 1 grade). Colours 623 and 823 are not needed for level 2 so they are swapped out.

Check out the sprites comparison below, the arcade versions are on the left again. I gave priority to skin tones, as these are the colours you see the most throughout the game. By reducing the saturation of certain browns we can then reuse those colours for background colours. The output is almost identical.

Another example of colour choice, Billy uses 3 blues in the arcade version. My version uses 2 and then a dark grey for the other. The mid blue is then desaturated a bit so the it is less jarring when combined with the dark grey. Your eye doesn’t notice the difference unless it’s side by side with the original

By desaturating certain colours we then achieve a palette where combinations are more achievable, and by keeping the very light shades vibrant we retain the vibrancy. Overall the palette may be a bit more grey we still get that pop from the sprites, and we have gone from 384 colours to 32.

Regarding the resolution, we have chosen 256x240 to remain faithful to the arcade. Resolution has an impact on the feel, and seeing as we would gain a performance increase, this feels the right decision."



http://www.electriccafe.xyz/double-dragon

[redblade]

Thanks for that information. The billy and the enemy sprites look great . 256x240 is going to be great .

I can't wait to play it.

[skyzoo73]

6th November 2020

AI Part 1

"The AI for this game will be iterated upon in stages. The first thing we need to achieve is for an enemy to first follow a player.

As mentioned previously our players and enemies are now belong to our GameWorld in code. This essentially means that the player code and the enemy code can access each other’s variables such as position & health. These 2 variables are important, because the enemy will need to know the player’s X & Y position to be able to move towards them and they will need to access the player’s health to pass damage to them (when they attack).

As the game is in pseudo 3D, we will use a Z coordinate for the player (and enemy), this for the most part will be the same as the Y position except when the player jumps, in which case Y will go up and down, while Z will remain the same. The reason we need this is so the enemy does not follow the player’s actual Y position on screen when they jump. The player is simply jumping up and down from a Y position, hence Z can be used.

So for the code the first thing we will do is make the enemy check the position and distance of the player, we write this like so:

enemy->target_dist_x = distance(enemy->xpos,gameWorld->player1.xpos);

enemy->target_dist_z = distance(enemy->zpos,gameWorld->player1.zpos);

The enemy holds variables for the target distance for X and Z. We call a function I wrote called “distance” and pass 2 arguments, the enemy’s X position and the player’s X position. This is a very simple function that returns the difference between 2 values.

int distance(int a, int b)

{

int distance;
distance = (b-a);
return distance;

}

So now we have distance values for both X and Z we can start to do something with it. Another variable we will use for the enemy will be SIGHT_RANGE, this will be the distance the player will need to be to the enemy before the enemy thinks about doing something, otherwise they will Idle.

if (enemy->target_dist_x > -SIGHT_RANGE && enemy->target_dist_x < SIGHT_RANGE)

{

ChooseMovement(enemy, gameWorld);

SwitchEnemyState(PLAYER_STATE_WALK, enemy, gameWorld);

}

else

{

SwitchEnemyState(PLAYER_STATE_IDLE, enemy, gameWorld);

}

As you can see if the player is within range we then call a ChooseMovement function. This is basically the enemy deciding whether to move to the front or back of the player. In the future this will take in many other factors such as other enemies already being in those positions, but for now it is simple.

if (enemy->target_dist_x < 0)

{

PositionFront(enemy, gameWorld);

}

else

{

PositionBack(enemy, gameWorld);

}

So if the X target distance value is negative then they will move to the front of the player. If it is positive then they will move to the back.

PositionFront and PositionBack are 2 functions we use to start to control the movement of the enemy. ATTACK_RANGE is a variable we will use to set the distance an enemy should place themselves away from the player to attack. So we do the following for positioning in front of the player (to the right).

if (enemy->xpos > gameWorld->player1.xpos+ATTACK_RANGE)

{

enemy->xvector = enemy->xspd*sign(enemy->target_dist_x);

}

else if (enemy->xpos < gameWorld->player1.xpos+ATTACK_RANGE-10)

{

enemy->xvector = enemy->xspd*-sign(enemy->target_dist_x);

}

Walk(enemy);

Here we are saying if the enemy is not yet at in position then set their X vector (the variable we use to move the enemy) to their walk speed in the direction of the player.

Else if the enemy is too close (i.e. on top of the player) then move back a bit.

At the end we call the Walk function which uses the X vector to move the enemy’s X position like so:"

enemy->xpos += enemy->xvector;

We do the same for the Z position. This is what it looks like:

[rothers]

Looking really good, it's so cool to see people showing what the Amiga can do when it comes to arcade conversions.

[redblade]

Looks great. How are you going to change between the levels? Are they going to walk across like the arcade or will the screen go black and reload again on the next level?

[skyzoo73]

Originally Posted by redblade

Looks great. How are you going to change between the levels? Are they going to walk across like the arcade or will the screen go black and reload again on the next level?

ElectricCafe should be asked directly, however I continue to report here on EAB directly from its web page http://www.electriccafe.xyz/double-dragon

[skyzoo73]

UPDATE 11th November 2020

"THE ENTRANCE OF ABOBO THE GIANT


Written by Kazunaka Yamane, this is a minimal and effective composition that perfectly captures the brutal smackdown that awaits you at the end of each level.

Here is my version that I hope goes some way to doing it justice on the Amiga."

http://static1.squarespace.com/stati...al/v5_boss.mp3

[skyzoo73]

12th November 2020

AI PART 2

"It’s worth noting at this point that my approach to AI is inspired by this guide by David Silverman. When I wrote my first beat’em up engine in Gamemaker a few years ago, this was the guide I followed. In C the way it is coded is different but many of the concepts remain the same.

So today we are showing off those hit boxes I keep talking about and using them to collide with the player, drain health and eventually end their green rectangular life.

First of all we are expanding our ChooseMove function:

We have added a check here to see if the Enemy is close enough to the player to think about attacking. We check this on the X and Z axis.

If close enough then we run the CheckAttackChance function, this is where the enemy will have some randomising AI that controls how aggressively they attack. Eg. the grunt enemies will not attack as frequently as the big boss enemies.

So currently each frame the enemy’s aggressiveness will increase by 1. It then checks to see if the aggressiveness value is higher than a randomly picked number between 0-100.

If so it will trigger the enemy’s Punch1 state (incorrectly labelled as PLAYER STATE PUNCH1 but I’ll clean that up later)

Eventually I will add more code here to choose from a variety of attacks.

So in the SwitchState function we do some one off things like setting the length of the attack and eventually triggering animation and SFX like so:

With the state now set to PUNCH1 the code then comes back into the UpdateEnemyState function where it will run the EnemyAttack function each frame until it is finished.

EnemyAttackTimer simply reduces the attack_timer value by 1 each frame.

We then trigger the hitbox and collision detection some time after the attack has started as we want it to sync with the frame of animation where the arm is extended. We use a hitboxTime argument to control which frame we want this to happen. So if attack_timer is less than say 3 it then triggers the hitbox and collision detection.

When the attack_timer is 0 we then turn of the hitbox, reset their aggressiveness and set the enemy’s state back to Idle (so they can start again).

All of this will be expanded in the future to allow for enemy combos and other things but for now we can do some simple attacking like this.

And what we get may look like a primitive sex game but it provides the basics of our beat’em up engine

The next AI update will include hitbox collision and passing variables between player and enemy."

[skyzoo73]

1st December 2020

PROGRESS UPDATE

"I’ve been meaning to post an update for a few weeks for the AI but haven’t got round to creating a video for it yet, but I will post that soon. What it will show is that the basic main engine is complete.

We now have a beat’em up engine that can handle multiple enemies in idling, patrolling and attacking states. They all know about each other and make intelligent choices based on the player’s position. It all works really well so I will look forward to showing that off.

I’ve also addressed an issue of responsiveness in that it felt a little sluggish previously, this was because when I am switching between states I am not actually running the code for that state until the next frame. So to solve the issue a state’s code is always run in conjunction with the state change, and this results in super responsive gameplay.

We also have great hitbox collision, this is very clear to see when performing a flying kick.

So to summerise we have completed the following so far:

Player controls and moveset

Enemy AI for multiple enemies

Hitbox collision

Take damage, reduce health and die

All music arrangements, many already converted to Mod format

SFX prepared at both 22Khz and 11Khz, with the 11Khz results more than acceptable due to EQ tweaks

Colour palettes for all levels

Tilesets ready for 3 levels

All sprites prepared

With all this work done so far it allows us to plan how we will use the memory available. See the next update."


http://www.electriccafe.xyz/double-dragon

[skyzoo73]

1st December 2020

MEMORY MANAGEMENT

"As we have previously stated we will be creating this game for the Amiga 500 with 1mb RAM. In my opinion this is the classic Amiga setup and see no point in creating AGA versions for A600/A1200 as no one I knew had one back in the day, but everyone had an Amiga 500 and indeed most had the 1mb upgrade. So the challenge is to create within the limitations.

The internal 512Kb RAM will have to contain everything we need at runtime to make the game happen, that is the display, audio and code. This is because the Amiga Blitter, Copper and Paula chips interact directly with this RAM chip (is the way I understand it anyway).

So we will use the additional 512Kb for stuff we want to swap in, this can be things like additional spritesheets and audio we don’t need all the time etc. an example would be Willy’s gun sound, we don’t need this until the end of Level 5 so we will make it available just before we need it.

This approach frees up the internal RAM somewhat in the hope we can have all the music and graphics from the arcade game without having to sacrifice anything due to RAM limitations.

With that said and the work done so far, we can start to do some super rough calculations:

Internal 512Kb RAM

Music 70Kb (will contain the level, boss and cutscene music in the same file)

SFX 70Kb (these will be the core most used sounds)

Display 40Kb (the screen is 256 x 240 x 5bitplanes)

Code 30Kb

This leaves 300Kb currently

Expansion 512Kb RAM

Background Tileset 50Kb

Player Sprite 70Kb

Enemy Sprites 200Kb (ish..)

Additional GFX such as weapons, fonts 70Kb

Additional Audio 50Kb

Cutscene GFX 20Kb

This will all be loaded per level, so when you complete we will cut to the preloaded cutscene GFX and music and then start dumping the old stuff out and loading the next level’s assets in.

Having the game on 2 disks is expected but may not be necessary, we will see on that one If it is, then disk swapping will happen during the cutscene so will not interrupt gameplay.

This is all of course based on what we know so far, I expect all of that free memory to be used by one thing or another at some point but it’s all very encouraging."


http://www.electriccafe.xyz/double-dragon

[agermose]

Originally Posted by skyzoo73

1st December 2020

MEMORY MANAGEMENT

"As we have previously stated we will be creating this game for the Amiga 500 with 1mb RAM. In my opinion this is the classic Amiga setup and see no point in creating AGA versions for A600/A1200 as no one I knew had one back in the day, but everyone had an Amiga 500 and indeed most had the 1mb upgrade. So the challenge is to create within the limitations.

The internal 512Kb RAM will have to contain everything we need at runtime to make the game happen, that is the display, audio and code. This is because the Amiga Blitter, Copper and Paula chips interact directly with this RAM chip (is the way I understand it anyway).

So we will use the additional 512Kb for stuff we want to swap in, this can be things like additional spritesheets and audio we don’t need all the time etc. an example would be Willy’s gun sound, we don’t need this until the end of Level 5 so we will make it available just before we need it.

This approach frees up the internal RAM somewhat in the hope we can have all the music and graphics from the arcade game without having to sacrifice anything due to RAM limitations.

With that said and the work done so far, we can start to do some super rough calculations:

Internal 512Kb RAM

Music 70Kb (will contain the level, boss and cutscene music in the same file)

SFX 70Kb (these will be the core most used sounds)

Display 40Kb (the screen is 256 x 240 x 5bitplanes)

Code 30Kb

This leaves 300Kb currently

Expansion 512Kb RAM

Background Tileset 50Kb

Player Sprite 70Kb

Enemy Sprites 200Kb (ish..)

Additional GFX such as weapons, fonts 70Kb

Additional Audio 50Kb

Cutscene GFX 20Kb

This will all be loaded per level, so when you complete we will cut to the preloaded cutscene GFX and music and then start dumping the old stuff out and loading the next level’s assets in.

Having the game on 2 disks is expected but may not be necessary, we will see on that one If it is, then disk swapping will happen during the cutscene so will not interrupt gameplay.

This is all of course based on what we know so far, I expect all of that free memory to be used by one thing or another at some point but it’s all very encouraging."


http://www.electriccafe.xyz/double-dragon

Great project. Your mem calculations for the screen seem a bit off. You need an extra 16 pixels horizontally for the scrolling. And unless you want choppy gfx you need at least dual screen buffers. Have you added mem for the blitmasks for the sprites? Assuming they are software sprites.

[DamienD]

Originally Posted by agermose

Great project. Your mem calculations for the screen seem a bit off. You need an extra 16 pixels horizontally for the scrolling. And unless you want choppy gfx you need at least dual screen buffers. Have you added mem for the blitmasks for the sprites? Assuming they are software sprites.

It's not skyzoo73's project; he just posts the news from the external project webpage here in this thread...

It's ElectricCafe's project