I’m building a hitbox-based combat system in my Paper2D game, and I need some help determining the most efficient way to represent the hurtboxes.
I’m currently using box traces for hitboxes, (appropriately positioned traces are fired from the character’s tick based on the current flipbook frame), and I use a BoxComponent that only has collision with these traces for my hurtboxes. The BoxComponent is attached to my Character, and is re-sized and moved around every frame.
My problem is: I’m looking to get a tighter fit on my hurtboxes and am worried about performance with adding more BoxComponents and moving them each around every tick. I wouldn’t go quite as far as this picture from Third Strike, but the blue and light blue boxes are an example of what kind of hurtboxes I might require:
So, my question is: Should I add as many BoxComponents as I need and move them around every frame? Is there a more complicated shape component that I should be looking into? Is there a way for me to do this purely with traces? (In other words, is there a way for a trace to trigger a trace?)
I would worry that this is optimizing too early, but my next step is to build an in-engine tool to facilitate my drawing these hitboxes and saving the position data into a data table. I would like to have this part figured out to avoid refactoring the tool later.
Bonus question: Is it more efficient to have multiple diagonally placed traces like the red boxes in the picture, or to rotate one longer trace? Specifically when using Kismet’s BoxTraceMulti (Which calls SweepMultiByChannel). I would assume the rotation is faster since it seems like the underlying PhysX functions always calc with the rotator, even if it’s not going to do anything. Just want to check.
Thanks!
