Games Double Dragon Game?

[ilan]

hi

for a while i wanted to try to make a game like double dragon where the player can move up and down and right left (jump,etc..) i just wanted to ask you guys how would you solve the collision issue. like when the player punch when is there a hit and when not?

in such a game i would not use box2d to solve the collision detection since it wont fill the same as in the 90s and also i would like to get a hit also if the player is not 100% alligned with the opponent. in my opinion it is a perfect game for libgdx and own collision classes. i can remember that i have seen here a very similar game by some one that i really enjoy playing but i dont remember whos game it was.

anyway, so how would you solve the collision part? i dont need any code just the logic.

thanx, b4x gamers

 

[Erel]

You can use box2d for this and set the hitting fixtures be sensors.

 

[ilan]

You can use box2d for this and set the hitting fixtures be sensors.

using box2d for such a game is possible although there are a lot of scenarios u need to take into account. to set the bodies to sensor is for sure the way i would do it but there will be a lot of challenges.

(i am trying to count all issues that can happen and the list get bigger and bigger so i won't write it down)
anyway it is possible but i was thinking that i will not have any advantage from box2d in such a game because you will have to implement lots of rules when a hit happens and in such game there is no gravity and you will need to draw everything by yourself like a jump or if player is hit and fall down so box2d, in my opinion, is not the way to go in such a game.

why not use box2d:

- no gravity (player can move up and down) so no use of box2d when jumping
- collision will be anyway a big problem with or without box2d (lots of rules) so box2d is not saving anything of it
- will need to handle 2 coordinates system


why use:

?


from my experience and after making lots of games with box2d I think in such a game you will not have any advantages from box2d its a classic game for libgdx and its unlimited possibilities

what do you think guys?

 

[ilan]

btw i played yesterday with my 6 years old son Ninja Turtles on our SNES Mini and it brought me some motivation for making such a game



EDIT: there was a guy here that made a post where he showed a game he made that is the same logic as double dragon but i cannot find it. of course @wonder street fight game is also the same logic but that guy did a really nice job i think he also uploaded a video about his game. i wonder if he finished it or not

 

[sorex]

for non jump actions your first rule is checking the difference between Y positions. if it is for example < 2 pixels you continue with the rest.

then you check action state (type of action, frame count...) and based on that you check for 'hitpoints' based on the X positions ranges.

for jumping actions you combine the X position ranges with Y position ranges as some hits only may occur at the last frames of the upgoing jump movement.

the 'easiest' would be to create an editor for this in B4J as it would require less testing than doing it all manual if your animations have a lot of frames.

I don't know if Box2D would be a real help here as it would probably require to create all hit points for current player states realtime or pre-create and enable/disable and you'll need to check Y positions anyway as collision rectangles may overlap when no hit is possible as you walk in 4 directions.
Maybe it has some 2D specific method for this, I dunno.

 

[ilan]

for non jump actions your first rule is checking the difference between Y positions. if it is for example < 2 pixels you continue with the rest.

then you check action state (type of action, frame count...) and based on that you check for 'hitpoints' based on the X positions ranges.

for jumping actions you combine the X position ranges with Y position ranges as some hits only may occur at the last frames of the upgoing jump movement.

the 'easiest' would be to create an editor for this in B4J as it would require less testing than doing it all manual if your animations have a lot of frames.

I don't know if Box2D would be a real help here as it would probably require to create all hit points for current player states realtime or pre-create and enable/disable and you'll need to check Y positions anyway as collision rectangles may overlap when no hit is possible as you walk in 4 directions.
Maybe it has some 2D specific method for this, I dunno.

another way to deal with it could be such a solution: split the field to lots of lines on the Y axis. the center of the field is 0 when you go to the top it will be 10+ on on the bottom 10-. so you map the field on the y axisin 0.02 steps. now this will be your scale factor.

what you will win with in this way?

1. you scale the player size with the value so the player shrinks when he goup and get bigger when he go down so a nice effect like he comes near to you or go far from you

2. you can check the scale value of the player and opponent to know if they re on the same line (+/1 x lines) then hit will register.

3. like this you can now also perform a jump but keep the scale factor so if player jump on line -1.2 bassicaly what you do in a jump you move him up but because the scale of the player stays the same you only change his y position then the you get another visual filling of the player and a difference if he go up or jump and the other think you can know is even if the y axis change but scale value is the same you wont register any hits by player on wrong y axis.

like player jump on line (scale value) -1.2 and perform a hit while he is jumping and he reaches line2.2 because of his scale value you wont register a hit to an opponent that also is in that line (2.2).

i was thinking about that solution right now so i think that could work.

 

[sorex]

the problem is that you will need to scale everything.

movement speeds
positions of hitpoints
hitpoint sizes

just to name a few.

you'll end up making things quite complex while the visual experience won't be that great due to detail loss or pixel doubling.

 

[ilan]

the problem is that you will need to scale everything.

movement speeds
positions of hitpoints
hitpoint sizes

just to name a few.

you'll end up making things quite complex while the visual experience won't be that great due to detail loss or pixel doubling.

you dont need to scale everything. you just hold a value to know where all players are and the scaling of the sprite is not that big maybe from 90% to 110% where 0 is 100% or even less. the numbers are not important, whats important is that you can like this perform jumps and move up down but still know where you are.
there are for sure a lot of ways to solve those issues. what is for sure is that this is a very interesting project