screenshot club


I dunno if people remember my post about making a fighting game engine on the previous forum but that’s still a thing, and after years it’s slowly on the way to having a decent feature set.

Including a kinda janky but quite functional scripting language (here the stuff needed for a hadoken, upper left is the condition for getting into the right state, down left is the character state that throws it, right is the hadoken itself. The language for the quarter circle movement is probably familiar to mugen scripters):

EDIT: forgot to post it because that’s not the bit I’ve been working on recently but there’s a hitbox editor too, that you can trigger from inside training mode:

(the third character is just the bit you draws the hitboxes on, which may be confusing)




Would you know why most modern FGs insist on handmade hitboxes?


Indeed I do!

The rock-paper-scissors aspect of which moves hit what is a huge aspect of fighting game balance, and entirely the result of the tetris game of collision interactions, and so as moves are balanced you may need collision geometry to drift significantly from what it was in the first place. That means collisions might differ significantly from where the displayed character geometry is!

If you take that uppercut in my screeenshot, how safe that move is can be greatly controlled by the relative sizes of the red hitbox and its immediately surrounding hurtbox or even the directions in which they do or don’t overlap. If the hurtbox were smaller than the hitbox this would be a significantly safer move than it is now and it’d affect the feel of the move and game (the stereotype goes that capcom hitboxes are usually like the one displayed here while SNK hitboxes tend to extend beyond hurtboxes for example).

The extreme example would be dragon punches, where the upper half or even all of your character may be devoid of hurtboxes for a couple frames because it’s an anti-air move. A more discreet example would be how having your reel animations use the same hitboxes as your idle pose will make combos more consistent and thus easier to learn.

This is something Capcom learned the hard way in the early SF4 days, where all kinds of balance and feel problems came to be because they thought having hitboxes be closely based on the animations would be a good thing. As new versions were made hitboxes came to be much more disconnected.

What’s more, because balance may be iterated on quite a bit, it’s a huge advantage to have collision authoring that doesn’t require an animator and can instead be entirely handled by a designer. With that dependency gone animations and collisions can be worked on and touched up without affecting each other. In some production structures where animations are outsourced to another team this might even be critical because you may not have access to an animator at all when balancing moves.

That isn’t to say the initial collision geometry will never be generated from animations in the beginning, though. It’s just that it may drift significantly as things are iterated on.

In that context 2d hitboxes are pretty much the easiest to author and visualize, too, as anyone who’s ever dragged a selection box knows how they work, plus you can study and directly apply collision design patterns from older fighting games.

On top of that they’re also super cheap computationally which might come in handy if you need your main update loop to be super fast (for rollbacks for example).


Animation principles (bounce and stretch) and tunneling (physics objects not registering collisions when moved too quickly) are also good reasons to move colliders by hand.


Indeed! For a fighting game example see UNIST, where attacks will often only have before/after frames but hitboxes do cover the missing arc.