Tjyylli

I understand that collisions in fighting games are detected using hitboxes and hurtboxes associated with specific frames of the animation

I am looking for techniques to author the data for these hitboxes to use in my Java platformer game (I'm not using a pre-existing engine)

I have a single hitbox for the character working, but as I add animations with sprites of variable sizes, I need to move from a single static hitbox to something that fits the animation frames.

So far I've considered:

• 
  

  Manually picking position & size numbers for each frame, and typing them out in a text file like a JSON data structure asset to load into my game.

  
  
  

  This works for short animations, but seems like it wouldn't scale to larger animation sets of 30-100 frames each.

  
  


• 
  

  Automated image segmentation with rectangles. I wrote an algorithm which divides the image into n rectangles with their transparent parts trimmed.

  
  
  

  However, it is far from optimized, and may produce inappropriate results. It cannot be relied to automate the task.

  
  

What method can I use to create suitable hitboxes for a large number of animation frames?

Handling hitbox and hurtboxes is something usually the artist and game designers decide. In the ideal situation these boxes are manually created for each frame of animation.

The main reason for creating them manually is because these boxes are context sensitive- that is, you need to understand what part of the character is dealing damage or what part of the character is defending and so on.

DMGregory provided answers with regard to how these boxes work and how one can implement them in the comment section of the question.

What if the animation contains a lot of frames? Keyframing and interpolation is your best bet.

In the animation use keyframes when and where boxes should appear, disappear and their locations. Interpolate the frames inbetween to transition the hit/hurt boxes. This way you only have to position these boxes at key moments and positions while the rest is calculated. If you have a fixed number of frames you can pregenerate the boxes as a data structure. If you have interpolated animations (example using Spine software or other skeletal animation software) you could do the boxes on the fly (some tools support this out of the box).

Regarding automated hitbox generation

Let's have a look at the animation of Ryu:

The animator has created a bunch of sprites that follow a sequence.
Now it is hard for an automated process to understand the first frame of the wind down part is where the attach ends. There is still a 'fist' in that frame, but it is no longer dangerous. Thus the artist has to tell the game what is needed.

Traditional sprite frames

So you would need to define for each individual frame where the hit and hurtboxes are. Now in some animation tools you can define the hitboxes and export the data.

In your game you would read your sprite data (which may contain sequence and timing data) and also the hitbox/hurtbox data. Upon collision you then check what frame you are and where these boxes are located and act accordingly.

Interpolation

If you use skeletal (or rigged) animation, it would mean that the artist poses the model for set intervals (let's say Ryu consists out of separate sprites for arms, legs, head and body) and move these parts to key moments in time. Now attach hitboxes accordingly on that same timeline. Imagine Ryu then smoothly transition from one frame to the next based on linear interpolation.

Then use that information to transition between the keyframes and recalculate the boxes as well.

Your workflow needs both the animation and a somthing to provide hitboxes for the (key)frame data. This is then exported as datapackages your game can read.

Conclusion

For hit and hurtboxes, you will need to add a step in your workflow to generate the required information. If you have really lengthy animations (30+ frames) you may try to combine the traditional animation with the interpolation technique.