2D fighting game collition
Author
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.
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.
Author
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.
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 ImpossibleHi, sorry for grabbing up souch an old thread, but I couldn''t find anyting newer to this.
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.
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!
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.
Too bad but thank you.
I was just thinking about how to do it by hand. I thought about struct CollisionRect. And every character (resp. sprite) has a std::vector<CollisionRect>. Resp. every animation has on the other hand a std::vector of this lists with as many elements as the animations frames has (or I put animation and collision in one class and storage).
I was hoping to find a solution thats saves me a lot of time. On the other hand i have no idea how to assign the hitboxes to every animationframe (like with an editor-tool), store them in any way and at last of course import them to the level.
any idea how to do it? Or is there any (part-)solution that i could use or that could help me?
I was just thinking about how to do it by hand. I thought about struct CollisionRect. And every character (resp. sprite) has a std::vector<CollisionRect>. Resp. every animation has on the other hand a std::vector of this lists with as many elements as the animations frames has (or I put animation and collision in one class and storage).
I was hoping to find a solution thats saves me a lot of time. On the other hand i have no idea how to assign the hitboxes to every animationframe (like with an editor-tool), store them in any way and at last of course import them to the level.
any idea how to do it? Or is there any (part-)solution that i could use or that could help me?
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:
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.
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.
Just another thought, this is using SF as an example.
You could just use collision boxes one for the body, one for the attacking kick, one for attacking punch.
Know that you know what has hit with what, you don''t need to worry about pixel perfect because the move will deligate what happens. Say one does a high punch, and the other does a low kick. depending upon you game rules, the low kick will hit and the punch will miss due to the fact you move RPS tree dictates that. Most games these days have a RPS system, so it no longer matters that is be pixel-perfect just see if things collide and do the pp stuff be the move design.
You could just use collision boxes one for the body, one for the attacking kick, one for attacking punch.
Know that you know what has hit with what, you don''t need to worry about pixel perfect because the move will deligate what happens. Say one does a high punch, and the other does a low kick. depending upon you game rules, the low kick will hit and the punch will miss due to the fact you move RPS tree dictates that. Most games these days have a RPS system, so it no longer matters that is be pixel-perfect just see if things collide and do the pp stuff be the move design.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
