Hey, I’m doing some work on a fork of engine to add a feature that my game needs. I wanted to bounce my idea around to see if I should make my implementation generic enough to be merged, or if I should just burn through it for myself.
goal is to make an efficient solution (processing and workflow-wise) for per-frame hitboxes in Paper2D using traces. Combined with existing per-frame sprite collision, would give people a streamlined hitbox/hurtbox system. is for any game that has attacking object, (fist, sword, whatever), as a part of sprite art instead of as a socket object. There are tons of posts that show desire for , but I wanted to check first before I put effort into making sure my changes don’t add much cruft for people who don’t want to use it.
I’ll be adding another array of FSpriteGeometryShape next to current “Shapes” array in FSpriteGeometryCollection. new array will be for non-colliding shapes–basically just position data that can be drawn by a user in sprite editor like current sprite collision shapes and accessed in normal game programming from FlipbookComponent. new array won’t be passed through to PhysX collision box calls like Shapes is, so it should be an efficient way to handle position data. I’ll be adding in UI and attaching to right hooks to make it same process as adding sprite collision.
Here’s kicker: PaperCharacter Tick function will have logic to check if there’s any shapes in NonCollidingShapes array. If there is, it will run traces using each shape’s position data. There will also be a new function pointer or delegate in PaperCharacter for you to attach your trace logic to.
For people that don’t want to use it, only dead weight would be an empty array in FSpriteGeometryCollection, and an added check on every PaperCharacter Tick call to see if new array has anything in it.
For people that do want it, their workflow would just be to draw boxes on each sprite and specify in PaperCharacter a collision channel and a function to pass any HitResults to.
Thoughts? Valuable to eventually PR, or too specific?
At moment it seems really specific but if you create general use all case for kinda system where it’s efficiently used across board for anything you’d like to do in paper2d then I don’t see why not. Always helps to have instead of want.