2D fighting game collition

I don''t know specifically, but I would assume that the either do some sort of per pixel collision check, based on the animation masks... or they have a bound rectangle defined around "collision regions" ie arms, legs, head... and simply check if an attacking region of one intersects a non attacking, or defending region of the other. Just an idea, I don''t actually know :S.

The method a lot of 2d fighting games use is collision boxes.

You have a collision box in the area a fighter can be hit. When the figher moves, ducks, etc, the box is moved/adjusted to again be where the figher is at.

If the two boxes try to overlap each other the fighters are walking into each other and shouldn''t be allowed to move further.

If the opponents attack (a collision box/circle is used for this as well) tries to overlap with the collision box, the attack has hit the fighter and appropriate actions for damage should be taken.

It isn''t ''pixel-perfect'' but if done right it''s easily ''good enough''.

i was also thinking that it might work well to simple logically divide the stage in small squares (2d array) and make each animation fill the positions it fills on the array, each frame, so that collition can be logically check againt the array, rather than the character itself. (just another idea that recently ocurred to me) Ej.

in a stage piece this big:

00000000000000
00000000000000
00000000000000
00000000000000
00000000000000
00000000000000
00000000000000

a character punching animation might look like this:

00000110000000
00000111000000
00011111111110
00001111000000
00000111000000
00000111000000
00000111100000 (can you see the character, heh)

btw, just wondering, how expensive is it to do pixel perfect collition in a typical 2d fighter?

per-pixel collision will be slow as hell if you check every pixel of every object (even with just two big characters) every frame. but, you can use the bounding boxes mentioned earlier, and then if that results in a collision you can run the per-pixel on the overlapping part of the two boxes, which will be much faster than doing the whole thing each time.

quote:

---

Original post by krez
per-pixel collision will be slow as hell if you check every pixel of every object (even with just two big characters) every frame. but, you can use the bounding boxes mentioned earlier, and then if that results in a collision you can run the per-pixel on the overlapping part of the two boxes, which will be much faster than doing the whole thing each time.

---

If you do this the trick would be making the box as small as possible while still having the entire character contained...

The real question is whether or not pixel perfect is really worth it. If you want to see what the commercial games did, one of the MK games had a ''cheat'' that lets you see... (hint: it draws the boxes on the screen )

If you look at Mugen they have a tool for creating hit boxes over sprites. Multiple hit boxes (or circles) would be the way to go. You could do per pixel collision pretty quickly, and if you need this kind of accuracy you could do it at a decent speed, but I think it''s overkill.

does developer defined bounding boxes need to be generated for every frame of animation? (if so i guess a nice way to do it, is to have each frame of animation have a pointer to a list of its boxes, since most animations will share boxes anyway)

another thing, have any of you tried coding a 2d fighter before?

That''s exactly what I''ve done. I have a "hitrect" for every frame where an attack is present. So, for collisions, I check the attackers hit rect and see where it overlaps the defender''s main rect (entire area). Then, using the corresponding rectangle, I do some more checks, some of it is pixel perfect, but there are some optimizations. Bounding rectangles is the way to go.

-----------------------------
kevin@mayday-anime.com
http://www.mayday-anime.com

After carefull thought on your ideas, i believe i''ll go with having each character have to lists (1) a pointer to a bounding box list for each frame, (2) a pointer to an attack box list, thanks for your ideas!

Using multiple hit boxes defined for each animation frame, with maybe a per-pixel check only whting the box intersection, is the best way to go because it''s much more flexible.

You can define different damages for different animation frames, as example, or multiple attack boxes with different damages, so a certain special moves can be more effective if you hit the enemy in certain positions.

Also, it''s a good idea to have offensive, hitable and defensive boxes. Offensive boxes cause damage when hit the opponent''s hitable boxes (the hittable boxes can also be assigned defensive values, so hitting the opponent in the head could deal more damage than hitting him/her in the arm), and defensive boxes could simple repel attacks. This concept of multiple boxes can also be applied to action games, like beat ''em up games, so you can have a more interesting gameplay. Depending on what you want, you could have hit boxes with extra parameters, like "fire", "ice", "electricity", "posion" and so on.

i like your idea of using fighting games techniques on other types of games, i had the same thought a while ago, i wonder why arent many games like shooter for example using new elements like this

One of my favourite games of all time, Guardian Heroes, is a 2D mixture of beatemup with some RPG level elements, uses a very complex and intricate collision/fake physics system that is onf of the reason I love the game: it creates a very interesting and fun envronment that make the game enjoyable and nearly infinitely replayable.

As example, in Guardian Heroes there is a trick that turns the bounding boxes visible. Their types are color-coded, so you can see which ones are hitable, invincible, offensive, fire, electrical, etc.

Also, the game uses a decent physics simulation: the players and enemies all have different weights, and they affect how much they jump and how far they can be thrown. When the player hits an enemy, the hit produces a force, that then produces an acceleration based on the mass. So the enemy is pushed back a little by a weak attack, and can be thrown across the screen by a overpowered attack.

And moving objects (aka: enemies you knock away) with velocicities higher than a certain limit have their hitboxes turned indo attack boxes, and if they hit another enemy or player while being thrown across the screen, they''ll cause damage and knock them all. The system is also used for heavy enemies in free fall: anyone below them will get a decent damage from the hit, and the ground will shake when receiving a big impact.

On another example, in Guardian Heroes many characters can cast spells, like fireballs and lighting. The spells hitboxes are tagged to the character that cast them, so they''ll only hit enemies. But once the enemy is set on fire, all of his ihtboxes becomes fiery hitboxes, and anyone that touches the burning enemy will be set of fire too. It''s VERY fun, and this can create lots of havoc when 20 or so enemies are charging at you.

quote:

---

Original post by Anonymous Poster
I''ve a similar problem with an action game and I think this could be a good solution - if it works.

The way I see it, every sprite (even every frame of the animations) of a character needs definded boxes and I like the idea of giving boxes a specific name and values. So the different collision types stay distinguishable. Is there any help or tools I can use (I didn''t find anything concerning the "Mugen tool"?

I have many objects, many animations and I want to keep it fast an manageable.

If someone could help me - that it''ll be great!

---

Mugen was here, but it looks like the site is down. Mugen and Fighter Maker both have similar tools to create hit boxes for fighters. The problem is these programs are game makers and as far as I know there is no way to easily export the hit box data from them.

I suggest that you write your own tool for drawing hit boxes over your sprites and exporting the data. It shouldn''t be too difficult to do.

Creating the tool isn''t hard if you know how to use a graphics API and get mouse input. All you need to do is write an application that lets someone load images and draw hit boxes over them. So basically you would fill up your CollisionRect struct with the start and end points the users enters with the mouse.

You also need to write code to save the data to a file from the tool and have your game load that file. You can just loop through all of your CollisionRect vectors (or arrays, lists, etc.) and write them to a file. This is easy if you know file I\O, and if you don''t I suggest you read about it as soon as possible. An example file format would be something like this:


version 1.0
frames 2

frame 1
boxes 2
box 0,0,10,10,damage
box 10,10,100,100,hit

frame 2
boxes 3
box 0,0,10,10,damage
box 30,100,100,200,hit
box 10,10,100,100,hit


In this case it would be a text based format, but it may be easier to write and read a binary format. If it''s binary you can basically write and read your structs directly without having to parse a text file.