Multiple entities & character maps

[8DashP]

So Mike, in another post, you said entities and character maps are not related. But isn't an entity a single character?

In the case where there are multiple entities in a single ScmlObject, the current definition has the default character info at the ScmlObject base level. Wouldn't you want your default character info assigned to a given entity instead?

Character Maps, while I can see them being distinct from a given entity, still seem to be too generalised at the ScmlObject level as well. You may have the situation where you want a single entity but mapped to different charactermaps of the same entity, or even a mix and match where some versions are the same, and some are different. The current format of the CharacterMap & MapInstructions data does not seem to cater for different combinations of entities and maps.

And while I'm here, on a slightly related matter, the current// fields at the ScmlObject level also seem slightly misplaced when considering multiple entity/animations running at the same time. I guess they could be used and swap the values between every update, but it would seem simpler to either put them down at the entity/animation level, or disassociate them directly from the reference structure, and require the implementer to implement them externally in a runtime structure, instead of in the fixed structure of the definition.

Does that all make sense? I'm just really trying to get a good solid structure down first this time with my rewrite. After starting with the generic C++ implementation last time, and then having to modify it to bits to work with Shiva, it became a real mess. So I'd like to get it down as lean and efficient this time around, as I don't want a 3rd rewrite.

Thanks. Russell.

[lucid]

So Mike, in another post, you said entities and character maps are not related. But isn't an entity a single character?

In the case where there are multiple entities in a single ScmlObject, the current definition has the default character info at the ScmlObject base level. Wouldn't you want your default character info assigned to a given entity instead?

This is correct. Character Maps are per entity, not per file.

Character Maps, while I can see them being distinct from a given entity, still seem to be too generalised at the ScmlObject level as well. You may have the situation where you want a single entity but mapped to different charactermaps of the same entity, or even a mix and match where some versions are the same, and some are different. The current format of the CharacterMap & MapInstructions data does not seem to cater for different combinations of entities and maps.

Basically the way it works in Spriter (and the way it's meant to be used at runtime), is that you have a copy of the folder/file structure you're currently displaying for each entity instance at runtime. To apply a character map, you apply all of the map instructions.

So as you add each additional character map, any instruction will overwrite what was already there for a given part, for instance:

And while I'm here, on a slightly related matter, the current// fields at the ScmlObject level also seem slightly misplaced when considering multiple entity/animations running at the same time. I guess they could be used and swap the values between every update, but it would seem simpler to either put them down at the entity/animation level, or disassociate them directly from the reference structure, and require the implementer to implement them externally in a runtime structure, instead of in the fixed structure of the definition.

Correct, if you have multiple instances of the object, they should not be sharing eachothers' animation data. The file structure should remain available for each new created instance of an entity. Each instance, should at least copied down to the reference level, so you can store your animation data local to that particular instance of character. This is especially important with the upcoming features like variables, where you may want to allow the user to be able to modify variables within the animation.

Even further down the line, after the documentation is more thorough and complete for the basics, it will also be expanded to show how to implement various realtime modifications at runtime that can blend with the currently playing animation.

Also, I apologize we're a bit behind, but the documentation will be thoroughly updated after 1.0, most likely with an improved format that explains everything in detail in addition to presenting example code.

Let me know if that answers your questions.

[8DashP]

Thanks. That clears things up a bit.

I guess I've been trying to conserve time and space by loading the whole .scml into a memory structure initially, but then not making copies of the file data at runtime, but seems that's not realistic. I'll have to keep my base version for reference, and then create runtime versions of at least the entity structures with their own control data.

[8DashP]

OK, I'm up to thinking in detail about how to implement my runtime classes.

I was still hoping to get away with just pointer references to the base animation data, but it seems to cater for future functionality, the base data should be treated as static. I'm a bit concerned about performance when creating a copy of the base animation data tree, for every new runtime Entity, as that's no an insignificant number of levels of data to copy.

I know most of it is simple numbers and a string or 2, but when you have animation->mainlinekey->bone/object refs & animation->timelines->keys->, that's quite a bit of iteration for each copy. If you consider in a shooter of some kind, if you have animated projectiles, then you could be creating 5, 10, 20 new runtime entities each second, all with their own independent animation data structures. This may be the edge case, but as plugin developers, we need to cater for the worst-case scenarios.

Do yo have any actual data around issues with this approach, or is it still the great unknown? I guess my safest path while developing is to put the most flexible code in, at the cost of performance, and look for optimisations down the track when hard data is available.