Originally Posted by Volnaiskra
I cannot reply on behalf of concept game, but I can definitely give you some insights as to why the Spriter Extension has become a very important part of my workflow, beyond simply the cut-out animation:
* within fusion, you can use the Spriter unlimited 'trigger events' to eliminate pieces of redundant code: Most of my animation transition is done via the trigger and variables within the Spriter files, which I can set while creating new animations. Same with playing sound, or any other particular event which can occur during a given animation (change of character status, creation of hitboxes, creating visual effects, calling specific pieces of code as a call back, etc).
* the ability to have unlimited "action points" or even get at run times data about a specific piece of animation's position and angle (for example, position of the "head" sprite). This is extremely helpful when you want visual effects to be created during a specific animation.
* the ability to have animation Strings, integers and floats that you can define in the animation file, and then retrieve within fusion code to have specific behaviors during run time.
* the fact that you can in real time edit and reload the spriter file, tweak the animation and have that update taken into account without doing anything in Fusion directly
All of the above (and many more things which one could probably do to accommodate one's specific workflow) are extremely powerful tools as opposed to the native "active" objects Fusion offers. However for what you describe, and especially if active objects are already cemented into how you manage animated characters and object, what I mentioned above would probably not be of any help, as I don't think Spriter as an animation software is really as powerful and ergonomic as some of its competitors.
Also, I should point out that the extension still has a few major issues regarding performances and visual artifacts (which you can read about in the above comments). My biggest concerns are the loading times (which is extremely slow upon creation at run time compared to that of an Fusion active object) as well as the fact that animation does not seem to work properly outside of the camera view (which is a big issue for the aforementioned Even triggers, values if used to command some specific behaviors through the Fusion events).
I do wish these would be fixed and optimized by someone in the community who masters c++. But even with the drawbacks I mentioned, I could not go back to using active objects anymore for main characters, enemies, etc.
I hope this helps :)
I am slow to answer at the moment. I can only agree with what you said.
I would add the followings:
- smooth animation transitions by merging them (run, walk, idle for example)
- multiple collision boxes following the animation without any heavy CF2.5 coding
- changing sprites on the fly keeping the animation skeleton (haxe, sword, gun, bow for example)
As you said, there are still bugs or drawbacks which prevent the extension to expressing its complete power. Some times ago and still now, I was and am gathering bugs and optimization inputs.
I was stopping investing time in it because it already took me at least hundred of hours and I was not developing any game in the mean time. Since I am developing now a game where I want these kind of animation, I will certainly fix some of them. The file loading time should be improved with a json parser instead of scml (actually xml format) for example.
The extension is also open source so there is always a possibility to ask an expert to fix an annoying bug or optimize something.
: as you said, the tool itself (Spriter Pro, not the extension), may also break your habits. It is for sure not an easy step. I can only say that I found Spriter Pro rather intuitive and I am not a professional animator, at least for the obvious and simplest features.
Regarding Spriter 2, I have no idea if it would be compatible. I did not take a look. Maybe brashmonkey may answer this.
Hi conceptgame !
Happy to hear that the extension might get some improvements in the future.
If you'd prefer, I can create "proper" feature requests / bug tickets within the GitHub project so it's easier to follow for you (or anyone else with C++ skills who enjoys bug crushing XD ) ?
Let me know if/how I can help, I'd be happy to!
Thanks for your answers, guys. Since my workflow and systems are pretty deeply embedded in my game already, I was hoping I could get some small benefits out of using Spriter in a lightweight, peripheral way. But from what you guys say it seems that using Spriter would need to involve a bit more work and compromise than I was hoping for.
The aesthetic side of my game is on hold for now though, while I work on getting all the structural and programming stuff built properly. So I'll keep Spriter in mind and check back before I eventually start animating again. Thanks again!
RapidXml is supposedly 30-60x faster than tinyXml, so if parsing the xml file is what is slowing down load times it may be beneficial to try switching libraries. I'll play around with it and see if it improves speed a bit.
Originally Posted by conceptgame
There is a tinyxml2 library now, with bunches of improvements.
Originally Posted by Shadoku
I would really like to see more updates to this extension, specially with Spriter 2 around the corner...
Let's hope it doesn't need lots of change to work, so you can just add the new stuff to it!