- Đã chỉnh sửa
[Feature Request] Bounding Box User Data (Hit/Hurt boxes)
Hey,
Generally speaking, I'd like to be able to do this:
Hình ảnh bị xóa do không hỗ trợ HTTPS. | Vẫn hiển thị
http://forums.shoryuken.com/discussion/ ... itbox-data
https://sites.google.com/site/scrubfigh ... -hurtboxes
Create Bounding Boxes and assigning a property to them to say what kind of bounding box they are. Hitboxes, Hurtboxes, boxes that send messages (start blocking), etc.
Right now, bounding boxes can only be used for one thing.
IMO, Spine is first and foremost for animation. I'd push it to say it's animation plus letting the programmer know what's happening in the animation (ie, when a sound should play. Where a body part visually is. What things can be clicked).
Right now, bounding boxes can already have names attached to them. That means you can already tell bounding boxes apart from each other. So it's not really true that they can "only be used for one thing".
Attaching semantic tags to bounding boxes wouldn't change much. You'd still need to do the same things: Collect bounding boxes separately based on their labels. Attach different functionality to them.
Best of luck implementing your hitboxes and hurtboxes though.
Right, I've been browsing the forum and just come across mention of folks using "Longer#Names" to sneak in properties of things. I've even come across similar suggestions. Still, this information is closely tied to animations themselves. Specifying damage values in an animation is understandable not ideal, but specifying what parts deal and do damage, send and receive other messages, is important. It does look like a lot of cases can be worked around using "Longer#Names", but this is still not ideal.
Ah, I see. I agree, putting tags in the name would be quite hackish.
Still, if it's a versus game like Street Fighter, I can't imagine you'd need to resort to tags just to be able to have hitboxes and hurtboxes.
Isn't there only a finite number of boxes that you'd need, and therefore only very few non-arbitrary names the system needs and you need to check for? (As opposed to having to look through all the bounding boxes and check their tags.)
Well in the case of Street Fighter, you can just look at the image to see all the kinds of boxes. Every box there means something:
- The red box is the hurt-box.
- The green border boxes are the hit-boxes, every single one of them.
- The yellow body box is his collision versus other players.
- The yellow box sticking out of him is actually very long (3-5 Ken's wide), and tells the other player to activate a block (if they are pushing the correct buttons).
- There's a hard-to-see blue outline of boxes that says where grabs must touch.
Not seen in the image are filled blue and green boxes for throws and projectiles. There's also a flag to say whether a box is not affected by projectiles (or only affected by projectiles). I'm sure I'm missing some too.
But basically, you can have a lot of boxes. 
On a related topic, I actually want more bounding volume types. Polygon boxes are "fine", general purpose and all, but Circles, Capsules, and Oriented Bounding Boxes are useful too (not to mention cheap to calculate collisions for). Especially given that we make things out of multiple images in Spine, it's reasonable to expect I may want a collision box for every image in the body. If I need to use multiple boxes anyway, they may as well be extremely cheap to calculate collisions between. We can't exactly deform polygon boxes.
When creating the tools for meshes I took care to make them relatively generic where possible. The intent is that bounding boxes will be updated to use the same editing tools in Spine as meshes, then it will not be hard to deform bounding boxes.
It's true circle, AABB, and possibly other types of bounds could be useful and cheap to calculate. Lots of things to do though!
Yep! I realize there's waaaay too much to do, but I had to bring it up.
một năm sau
Pharan đã viếtIMO, Spine is first and foremost for animation. I'd push it to say it's animation plus letting the programmer know what's happening in the animation (ie, when a sound should play. Where a body part visually is. What things can be clicked).
Right now, bounding boxes can already have names attached to them. That means you can already tell bounding boxes apart from each other. So it's not really true that they can "only be used for one thing".
Attaching semantic tags to bounding boxes wouldn't change much. You'd still need to do the same things: Collect bounding boxes separately based on their labels. Attach different functionality to them.
Best of luck implementing your hitboxes and hurtboxes though.
You wouldn't happen to know how to retrieve hitbox names in the spine-starling runtime would you?