Sorry your browser is not supported!

I am trying to make a 2D fighter and I have my sprites moving and animated got fighting moves and ect. But i don't have a clue about how to make collision detection for my 2D fighter could some one steer me in the right direction or help me some how. I would greatly appreciated if some one would.

You have a couple of choices here. It all really depends on how accurate you really need those collisions to be. And this is one case where 2D can be harder to determine than 3D games.

choice 1) perfect pixel to pixel collisions
choice 2) bounding rectangle/sphere collisions
choice 3) a combination of the two

My first guess at this is to say that bounding rectangal collisions will satisfy for the what I am envisioning your game to be; perhaps a little more detail will help me here. Going on this notion you only let the fighters get to a certain point of closeness. At this point strikes are possible. Perhaps they get into a predertimined grappling like position. and then depending on the executuion of a move the animation takes place. I hope I am making sense here. It's harder to describe in words than I thought it would be. In other words under this type of system you don't have to actually determine whether a punch actually hit the other player. You would set it up so that:

If the payer is within a certain range of the other player is true.
and then throws a punch is true.
and the other player has a proper defense(say crouching or, blocking) is false
then punch is successfull.

You can do the same for say weapons like a whip.

Again under this system, the player move towards eacother. They enter within range to perform a strike or move. whichever player pulls of the move first gets precedent. Then perhaps you set up the animation of slighly moving the players closer together and run the combo animation sequence. Again I hope this makes sense.

For projectiles you can either use a bounding rectangle around the spriter to determine if their is a collision. This is usually acceptable in a 2d Fighter.

======

A more complex method would be to actually treat limbs and such as individual objects, and then perform either bounding rectangle collisions or pixel perfect collision detection. I doubt that this is what you will want to do, if your aim is a Street Fighter style game.
This is much more commonly used in 3D style fighters. If you notice in a Streetfighter game after you get in a certain range and pull off a move the animation is predetermined and runs as long as the player was within range and pulled off the move against an oppponent that doesn't defend properly to the attack. In other words, it's more about who gains precedent pulls and pulls of the move against an improper defense first that determines whether a hit is successful or not. the collision is not tested at the actual limb, but earlier. If you are close enough to punch strike and you punch, and the other player doesn't defend the punch animation scores a hit

I am sorry if my explanation is confusing. It was harder to write the idea then to conceptualize it in my head. I hope what I am saying gets across. Let me know if I should clarify more.

~zen

Thank you for your input i think the bounding rectangal collisions
would work well but im am not very skilled at dark basic and wouldent know how to make it work my code might be a little confusing but if you can do somthing with it i would really appreciated it alot. (the code isnt finished and i have some pretty random things in it and player two is not done)I will post it agine when i have every thing done except collsion.

Somone plz help me

Long Striker,

I will have to take some time to look at your code. But let's see if we are on the same page first. I re-read my first response and noticed it can be confusing. Let me offer this sugggestion and then let me know if it will work for what you are trying to accomplish. If so, I can help you with the code.

Basically I am assuming and old-School 2d fighter like Street Fighter, the early King of Fighters, early Mortal Kombat type game. If so...

I think the best (simplest with acceptable results) for collision detection would be the following. There are a couple of different categories of collsion you will need to detect for.

I. Character to Character Collision:
Here I am referring to a fighter on the left and another fighter on the right. You want them to be able to move towards eachother "Up to a certain point". You wouldn't want fighter 1 to move right through fighter 2. So there is an invisible boundary where the fighers cannot move any closer to eachother (except for special circumstances ie. they grab a hold of eachother; which will leave out for now). There are a few ways to keep track of this.

You are sort of already keeping track of the players x,y positions when you are moving the sprite. Those values for x,y is actually the corner of where the sprite image is being blitted. So from those values (x,y) you can have another x,y variable that is the exact center of your sprite image. Now, you just make sure that the distance between player 1's center X vallue and player 2's center X value is not less then a certain amount of pixels. you do this by subtracting the two and taking the abosulute value of the result. (because you don't care whether they are -20 pixels apart or +20 pixels apart - either way they are 20 pixels apart from eachother. You can do the same thing with the Y values so that you can detect the vertical distance. It's not too far of a jumpt to see that if you have to points you can use some basic point slope formulas to figure out the distance.

You could also use the idea of bounding rectangles to detect the collsion. Using this method you keep track of a rectangle the size of your sprite images. You then just code some quick checks to make sure the right side of fighter 1's rectangle doesn't collide with the left side of fighter 2's rectangle. (assuming fighter 1 is on the left and fighter 2 is on the right, and they are facing eachother). You would have other checks deoending on the position of the fighters.

II. Collision with the edge of the screen:
Using either or both of these methods you can also prevent the character from moving off the edges of the screen


III. Detecting Striking Collisions?:
Here I am refering to detecting whehter Fighter 1's punch hits fighter 2, for instance. This is the part that I might have confused you in my earlier post. What I was trying to say was, that you as the programmer "aren't" really going to detect whether sprite 1's fist hit's sprite 2's head. There really isn't any need to. That is the illusion that the player will believe, but what's actually going on is very different.

Whether or not a strike will be detected as a hit will be decided before the actual striking animation is rendered. SO...

You will basically have a Finite State Machine. And if certain logical conditions are true then the strike is successful and you will then render the strike animation followed by the resulting being hit animation. You will have to decide the conditions but it will be something along these lines.

1.Does player 1 attempt to strike? Yes or NO
2.Is player 1 is close enough to strike player 2? Yes or NO (some strikes might require to be closer than others)
3.Is player 2 vulnerable to said strike (ie not blocking, crouching) yes or no

so lets logically follow through the scenario above
1. Yes go onto 2.
1. No (the player is not attempting to strike)
2. Yes go onto 3.
2. No (play the animation of the attempted strike but it will not damge or actually hit the opponent)
3. Yes play the striking animation and the resulting animation of player to being hit, calculate damage etc....
3. No Play the striking animation but indicate that the strike has been blocked, and no damage takes place.

Let me know if this is the type of game you are doing. If so, I can better help you with the code and the logic engine. I will also look at your code in depth tonight.

~zen

i am working on a 2d-sidescroller-thingy game myself at the moment.
though i am still far from implementing actual combat (i want to set up a robust level-engine and leveleditor first),im gonna describe what i am planing for the fighting part, and as far as i understood zen,it's pretty much what he proposed as well. although, as i said earlier, i have not actually reached that stage of programming and *i do not have any code yet(!)*, ill try to describe how i want my game to handle combat:
when you hit the attack-button the following happens:
-the game checks the distance between the player and the enemy
-the game checks what kind of attack you used (eg. aiming up/down)
-the game checks what the enemy is doing right now

the following might happen:

A.
the distance is too great, so the other things are practically unimportant, because your attack wont reach the target

B.
B.1
the distance is ok so the following happens:
say you used an attack that is defined as "aiming at the top part of the enemy". then the next step:
B.2
the enemy ducks or dodges or blocks/attacks "up" himself, so the attack will not have any effect, but for example the program knows what happens in the fight (eg: player1 attacks up with sword; player2 attacks up with sword) and knowing this, the program can for example do certain things such as triggering a certain animation, which is for example not "player1-attack-up-anim" and "player2-attack-up-anim" played simultaneously (which might look a little boring) but rather "cross-swords-up" animation for both players.

though this will require more animations, it will probably enhance the atmosphere alot, because, although you still have the same amount of 'combat-moves' as before, it 'looks' as if you have a lot more variety in combat AND it makes "collision"-control nolonger needed.

now i know this might not be entirely clearly described, so ill try to give you another example:

-you and one of your pals each take toy-plastic-sword.
-then, instead of 'actually sparring' (your swords physically crossing) you take a measuring-tape, check the distance between the two of you
-you each take a piece of paper and write down the kind of attack you want to make (though in game this must not necessarily be turn-based, but rather you keep 'writing down your attacks' all the time which leads to the 'who-is-quicker-effect')
-then each shows his opponent what he has decided on (see above remark about non-turn-basedness)
-then you 'consult the manual' and see what effect the current situation (eg you hit up and he ducks) makes
-then you act the situationout (you slash your sword up and he ducks)

suppose there was another situation (eg you hit up and he does nothing because he was too slow) you see how much damage this does to each player and deduct that number from his hitpoint-pool
so you see in this system you never actually get to see who actually hits opponent with a sword but it's much easier to implement. atleast in a computer game

You are right I am trying to make a mortal kombat like game. Thanks alot for letting me see the logic of 2d collision dection. I understand better than I have ever had about it you made it simpler to me then i thought before it could be. I’m still not to sure how to write the code for it but you got me on the right track. So how would I tell the program
(If sprite A is this close to sprite B then attack 1 = true) how would I write code for that?
I am looking forward to your next post thanks agene.