henchmen yazdıCurrently, any game with skeletal attachments would need to implement a naming convention workaround
Adam yazdı
We wouldn't have to do workaround - like putting the tags into item names, like we do it now.
Adam, henchmen: Why? Name your things what makes sense, eg "right arm". Don't jam extra data in the name. Separate from Spine, describe data in a way that is best for your runtime using the name as a key. Eg, maybe you are using psuedo-JSON:
bones: {
right arm: {
blending: burn,
damage: 4
},
...
},
attachments: {
name: { ... }
}
This allows you to describe the data in any way you need. It also decouples the animations from the game data. You don't want to be describing damage values and other game data in your animations because then you need to open Spine to change the values and you have to export and replace all your animations to update the values.
Adam yazdıIf someone does a bad decision that he will put there data which doesnt belong there - that's just a bad decision.
I agree. I'm all for giving you enough rope to shoot yourself in the face, if the features are useful when they aren't abused. That is the question at hand.
Using the numbering from your image:
2+3) You could just as easily name the slots. Name the slot "bodySkeleton". At runtime, your game knows to attach the "body" skeleton to the "bodySkeleton" slot. There isn't a reason to describe this in Spine or in the slot name.
4) Your skin names are really "skin1 blue", "skin1 red", etc. This is not embedding a tag in the skin name, it is just naming the skin something unique and meaningful. The runtime knows which skin to pick because it knows the names of the skins. The names don't need more data embedded.
I think in just about any game of reasonable complexity, there will need to be some knowledge in the runtime of the animations. Eg, the runtime needs to apply attachments, skins, etc so it needs to know about those.
Currently Spine gives you a unique name to identify a bone, slot, attachment, skin, animation, etc and you can tie any extra information to this name externally, in some format your runtime understands. This gives you ultimate flexibility for your extra data.
The proposal to add name/value pairs to a bone, slot, attachment, skin, animation, etc would allow you to describe some data about those objects within Spine instead of externally. Your game's runtime still needs to make sense of this data, so it really isn't any help from the game's perspective, which probably has an easier time with JSON or some other format. The advantage is for the animator, that attaching some game specific data to an object is done quickly and easily within Spine.
The disadvantages are that you have to use Spine to edit the data which otherwise is not used by Spine or the animations. Also, you are limited by how Spine allows you to describe the data. The UI toolkit for Spine doesn't have a multi line textarea, so all you will get are single line textfields. Another example, if all you have are name/value pairs and you want a list of things, you end up using a delimiter, eg "name: thing1thing2thing3". What if you want a map? Eg "name: key1=>value1;key2=>value2". What if you want a map of lists? Your runtime has to parse that stuff and describing it in Spine is suboptimal.
I'm not sure that this data should be edited inside Spine. I'm not sure this data belongs embedded in the animation data. Is adding name/value pairs a stopgap that just pushes the problem down the line? Will you use name/value pairs in Spine and later, when the data you need to describe is slightly more complex, will you have the pain of extracting all that data from Spine and putting it in an external JSON file?
