felixjones
commented
7 years ago Existing animation definition formats
Best approach may be to look into an existing sprite animation format with an editing tool and use that. Gain some animation tool support along with extra frames - similar to the recent support for TileD polygon collisions through the TileD editor.
A quick Google search shows there isn't an obvious sprite-animation definition standard with a tool so we may end up finding nothing - in which case we'd need to design and document a small format for how animation frames are defined in this file.
Altimit custom animation definition format
I'd like to retain as much editor-support as possible, so I think our custom definition should extend from the current MV image-naming format scheme so default images can be displayed as expected in-editor and default sprite behaviour is retained.
Accessing extra frames, directions and animation presets could be done through Plugin commands for individual characters. Perhaps all extra frames are handled on a completely separate sprite-sheet with their animation loops, directions, etc defined in the definition format. Could optionally define extra frames on the parent image - more options means more power to the end user.
Actor1.png would have Actor1.json/Actor1.xml which points to the extra image files to be used and defines frame-count, frame-rate, directions, labels, etc for the extra frames. We could also sneak-in in-file collider definition for Actor1.png in this file, so 100% of the map-information for Actor1.png would be defined in this JSON/XML file.
JSON vs XML
JSON is great for developers, but end-users tend to find it confusing. End-users without coding experience usually find XML much easier - to the surprise of many. If we are unable to find a subtle format with an editor, I think XML should be the 2nd choice with JSON support at an optional later date.
Conclusion
I think we should use this issue to start defining an extra-frames format. My original plan was to have extra-frames as an extension module, as described, however the allure of being able to define per-sprite sheet colliders in this file makes me now think it would be good to have this as a built-in feature of the main Plugin - it would be "meta sprite-sheet information in a file" rather than specific to extra-frames.
This file could later be expanded to include things like foot-prints, shadows, normal-maps for a 3D lighting Plugin and rotational sprite frames for a 3D maps Plugin.
If someone does find an existing sprite editor with a good format to use, we should investigate that to see if it fits our needs before jumping on creating a new format.
vico93
Hi!
Wondering about this for a while, i thought in a different (and more organized) way to achieve this kind of feature in your plugin.
In my experiences making Minecraft resource packs i learn about the way the game stores data to render a animated texture, and i thought if this structure could be brought to RPG Maker, since it uses JavaScript and JSON is its data subset format.
Basically, the structure is: instead to register all the information (frame count, etc) direct in the image filename, Minecraft read a companion JSON file with the same name (and in the same folder) than the character png image, but with a different extension (like texture.png it would read a companion texture.mcmeta, which is nothing more than a JSON-formatted file), with a structured information about that char inside it.
The organization is far more better than have several characters on the sprite filename (eg.: !Celes(6 , 6 , 7, 8).png), something would broke in web servers due to the possibility to have weird characters in its name.
The full specification can be found here and here.
So, what you think about, in the case you start to implement advanced sprite control in your plugin. to organize it in a mode like this? And sorry if i wasnt much clear, my English isnt perfect.