Hit boxes in beat em ups.

Grit

Well-known member
Could someone please explain how they work when compared to a 1v1 games and what would be the best position to place them.
I have an idea on how to go about it but would appreciate some advice.
 
Last edited:
@Grit

Technically they work the same way. You have a set of cartesian coordinates that are constantly evaluated for overlap. Beat em' up and 3D vs. fighter collisions are individually more complex than 2D vs. fighters because they have to account for a Z axis, but functionally they're all identical.

Most vs. fighters use three body boxes (they tend to call them hurt boxes), one for head, torso, and lower body. Then a single attack box for most moves. They also tend to have a space box that creates an area other entities cannot pass through. The SS below of Haohmaru from CVS2 gives us a typical example. Blues are his body boxes, red is an attack box, and the green outline is a space box.

1715879072239.png

Beat em' ups usually just have one body and one attack box, for several reasons:
  • You typically don't need (or even want) the same level of precision as vs. fighter. Collision that is overly precise in a beat em' up can actually feel finicky and unfair.
  • Most beat em' ups don't distinguish the specific hit area. You're either hit, or you're not.
  • Beat em' ups already have a LOT more collision calculations to contend with. Not only are there more entities on screen, but you also have pathways, obstacles, and platforms that most vs. fighters completely lack or keep in extremely limited quantities. These all require the same type of collision calculations as attack and body boxes. Plus, as noted above, the individual calculations are more complex to run than a 2D vs. fighter.
  • Other than platforming objects, space boxes are almost anti-ethical to beat em' up mechanics. Imagine if the crowds of enemies in SOR or Final Fight took up physical space. The games would be virtually unplayable.
Collision calculations are one of the most CPU intensive parts of a game, no matter the genre. There are entire classes and research topics devoted to optimizing and reducing them. The really short version is "use as few as you can get away with". FYI, OpenBOR supports multiple collision boxes of each type per frame, but unless you really know what you're doing, there's no need for them. Just one body box and one attack is almost always sufficient.

I could write an entire tutorial on basic collision design, but IIRC, there's already a good one circulating around the Mugen forums. @O Ilusionista might be able to dig it up.

DC
 
Last edited:
Beat em' up and 3D vs. fighters collisions are individually more complex than 2D vs. fighters because they have to account for a Z axis, but functionally are all identical.
Thanks for some further insight into hit boxes.
I'll post a video over the weekend showcasing how I placed the boxes then I'd appreciate some feedback.
I really like what you did with the multiple attack boxes seen in those tutorials.
I'm also coming around to using the same method everyone been using since it will be easier to edit.
 
Thank you for this. I have been having issues with my hit boxes as well. It seems hard to hit the enemies unless the player is lined up perfectly with the enemy. I made the attack boxes and the enemy hit boxes larger, but nothing seems to help. So I look forward to getting more info on this so I can determine what I am doing wrong
 
Thank you for this. I have been having issues with my hit boxes as well. It seems hard to hit the enemies unless the player is lined up perfectly with the enemy. I made the attack boxes and the enemy hit boxes larger, but nothing seems to help. So I look forward to getting more info on this so I can determine what I am doing wrong

It's probably a z-alignment issue. There are basically two ways to resolve that :
- Make either attack or body box bigger on the z axis (they are properties for that). No matter the width and height of boxes, if they are thin, they won't collide unless entities are perfectly aligned.
- Use script at start of an attack to auto-align player and enemy if the distance is small enough. If done right it won't look like the player teleported himself to enemy.
 
It's probably a z-alignment issue. There are basically two ways to resolve that :
- Make either attack or body box bigger on the z axis (they are properties for that). No matter the width and height of boxes, if they are thin, they won't collide unless entities are perfectly aligned.
- Use script at start of an attack to auto-align player and enemy if the distance is small enough. If done right it won't look like the player teleported himself to enemy.
Thanks, is there a script already written for the auto alignment already? I saw a beatemup that had this function on YouTube a while back, and looked on the forums to see if I could locate a mod that used it. However I didn’t see anything
 
Thanks, is there a script already written for the auto alignment already? I saw a beatemup that had this function on YouTube a while back, and looked on the forums to see if I could locate a mod that used it. However I didn’t see anything
@Hyunchris Like Piccolo said, I recommend checking all your collision boxes and filling the Z parameter with a bigger value, at least before trying a scripted solution. A value between 10-15 can solve the problem.

1716248854695.png

1716249158650.png

1716249018072.png

If you are using the V4 build the bbox Z can be filled with upper/lower values, which adds even more accuracy. You also have a new collision box method too, but I suggest trying the legacy method first.
 
Everthing have been said.
By reading the manual and following all the elements of hitbox and attackbox, it will work !
Yes, Z width can be not enough. Increasing it just a bit would fix it.
A too big value will make weird results.
 
1715879072239.png
After experimenting I come to realize that the positioning of the attackbox in the image below is more or less where box should be since the main issue with beat em ups aside from the Z axis is the floor panel since you can hit their feet if they stand above you.
With the attackbox in the middle they have to be more in line before the attack connects.
 
I could write an entire tutorial on basic collision design, but IIRC, there's already a good one circulating around the Mugen forums. @O Ilusionista might be able to dig it up.
Yeah, there are a lot of tutorials about it - but there are different opinions on that and even different methods to do it.

For example, I know two methods: Pixel Based and Motion Based. I use the second one, even on OpenBOR.

The animation, for reference:
jzJI44d.gif


Pixel Based:
Pixel Based: Only takes into account the area that causes contact (whether attacking or receiving damage)

This is an example of Pixel Based
1716494263376.png

Motion Based:
Takes into account not only the area that causes contact (whether attacking or receiving damage), but also the trajectory of the attack itself

This is an example of Motion Based
1716494243290.png

On the surface, it might seem like it doesn't make sense to have the hitboxes in that part, but his fist passed through there while making that move.
Keep in mind that attack boxes are NOT persistent on Mugen (unless you set them as default), so each box will be active only on that frame alone.

Another tip: you don't need to cover the whole body with bodyboxes, as you can see on the images above.
In other words, you should totally avoid this:
1716494373003.png

The more collision boxes you use, the more resource you will consume, no matter the engine.

Finally, all this works for body parts, like legs, arms, etc. Weapons have different rules, specially if you have blades.
Here is an example: pay attention that I haven't covered the whole blade with a bodybox, just half of it
1716494665869.png
And why? Because you can't punch a tip of a knife without suffering damage.
 
you place bboxes and hitboxes in a way it looks nice aesthetically /visually, so you dont place them so when you punch then you hit opponent and you are stil few pixels from his nose with your punch - it looks off so.... good practice for me is to end attackbox on the wrist, so punch will go through a bit closer than usual + also wil make the game noticeably harder , so you do not have to do it like this at all times, a good balance for the right feel is more important imo, just make sure all attacks are reaching properly.

When your char has far reach- you can make him slower.
When he has weak short reach - make him faster to compensate.

Also i nlot of arcade games - enemies have way better reach than players to eat up your coins, in games its pretty much who has better reach - wins . cause he hits you when hes far and you cant cause your attackbox wont reach him. Finalfight is nasty about it.

You want easy game - give yourself far reach, you want hard game - give enemies far reach so when you both punch - he will win and you have to walk in closer to him to punch him and with his far reach it is not as easy for you as it is for him to punch succesfully.

That is pretty much all you need to know about hitboxes in beatemup.

Heres 3 examples with well known zuckerpuncher

This will work but its not great - blue box is wide enough to cover legs but now the head/torso takes hit when the hand is not even close
1716497224929.png



Now this second one is better but the red hitbox on the punch is too far to right - will still connect a bit too early .

1716497298336.png



This is the best case , you need to get closer and your punch will look like it does connect to the body cause now red box ends on wrist and the punch actually has to go through the blue box - like a real fight.


1716497397343.png

With that in mind - the game feels easier and "better" when your reach is bigger but still try to make it look like its al connecting.

fighting games - vs ones have many more boxes, multiple blue boxes to make up nicer shapes , in openbor we have to use less , maybe V4 has more boxes but its of course way more time to edit them all - it adds up quickly and benefit is not that big . I think with one red and one blue you can do just fine if you place them carefully.


idle bbox and pain bbox - they have to be identical, they go back and forth a lot so need to be pretty seamless cause otherwise when your pain bbox is misaligned - your chain combo will not connect, especially when pain moves enemy a bit back.

Chain combo - the one that occurs when you keep pressing the same button - each consecutive attack reach must be equal or higher than previous one , it cant be that attack1 reaches 100 pixels and attack2 reaches 80 pixels - in this case attack2 is borked and wont connect often.

This is all important when planning and designing attacks visually for your game - each consecutive attack in chain combo needs to be a bit bigger than previous, soi its reaching the "peak".

So you cant have 1st attack a long stick - and second attack a punch, that is bad planning.Unless the stick reach is smaller than punch which usually isnt.

Sometimes you can cheat - you can move character with small reach a bit closer towards enemy on attack2 to compensate if attack1 had longer reach than attack2.
 
Last edited:
maybe V4 has more boxes but its of course way more time to edit them all - it adds up quickly and benefit is not that big . I think with one red and one blue you can do just fine if you place them carefully.

The main benefit to multiple box support isn't more accurately describing shapes. As we've all noted, you don't want to do that in a beat em' up. It's for unique cases like say, Dhalsim limbs. It's also useful when you want to make special reactions. For example, you could put the first box in order (so it gets higher priority if multiple boxes are overlapped) just over a shield or piece of armor, then set up an auto-block or reduced damage if that part takes the hit.

You can already do this with a single box and careful hit placement calculation, but it's tedious, un-intuitive, and hard to debug.

I don't expect people to use it often, and as you noted, they shouldn't. There's rarely a need. But it's there for the times you do, and doesn't cost any extra resources when not in use. The next thing I am working on is an option to scale collision boxes similar to drawmethod, but I need to finish up a lot of other things first before I get in over my head again and it's another five years between updates.

DC
 
true , actually i did not seen any well known fighting game with as simple hitboxes as openbor has , even sf2 had them pretty advanced and it even had a pushbox.body box so enemy wont passthrough.
Its interesting , looks like they had 3 - headbox,bodybox and legbox.Each triggering different pain probably.
Openbor hitboxes are kinda like for platformers but with z depth.
We can fake more complex bboxes a bit by having delay1 or 2 on duplicates of the frame and different bboxes on each to cover the body better if you really want more precise dhalsim. I mean thats how i would solve it if his limb is drawn diagonally.
And the way i wrote the message above is maybe overdramatic, i mean nothing will happen if your hitboxes are a bit bigger, it will just look off, takes few seconds to fix the values, especially now in openbor with debug mode displaying boxes.

Now this is cute, i wonder if intentional to make her cheaper.Maybe some typo in the box placements.
dsfgsd.jpg
 
Last edited:
actually i did not seen any well known fighting game with as simple hitboxes as openbor has , even sf2 had them pretty advanced and it even had a pushbox
I think it's because one of the strongest points for VS fighting games is the battle accuracy. Considering that everything this kind of game will offer is just a 1 vs 1 fight, it must be well done.
On the other hand, beat'em ups have many more elements during the battle (multiple enemies, obstacles, level interaction, etc) and it's understandable having the collisions working in a simpler way, similar to most classics.

1716573979600.png

1716574015170.png

1716596530447.png
 
Back
Top Bottom