Snorky

Hello, just wanted to inform about my upload of a basic Spriter implementation for Sprite Kit at GitHub: https://github.com/indieSoftware/INSpriterKit It supports only the simplest sprite animation and non-scaling bones. None of the other Spriter features are supported, so it's meant as a basis for further extendings and not for a productive usage. Feel free to clone the repo and extend it. Cheers

After watching the tutorial videos and playing around with Spriter B8_2 on my Mac here some feature requests from me: Toggle button for looping the playback in Spriter Actually playing an animation in Spriter will automatically loop when the playhead reaches the end of an animation. That is nice for animations which will normally be looped in game, too, but sometimes it is also irritating especially for animations which are designed as translations. For example a get-into-crouch-animation shouldn't be played again from the beginning after the character gets into the crouch position and that behavior should also be possible to simulate in Spriter's preview. So my suggestion is a little button like the current "Loop" button, which only stops playback of an animation in Spriter when it reaches the end. Shortcuts for playback control Actually there are shortcut keys for jumping to the next and to the previous keyframe, but the other controls in Spriter (jumping to the beginning, to the end and playback) don't have shortcuts even they are visually placed together in the window. Especially start and stop playback should have shortcuts to get easy access to see changes just done in the scene in realtime, rather than scrubbing the timeline with the mouse myself and to have a custom playback speed depending on the speed of my mouse movement. Especially with my feature request above it should be easier to judge changes on short animations. Just start playback, Spriter playes the short animation and stops, you can modify things and press the play key to the applyed changes in no time. So my suggestion is to bind the 1-key to "jump to the beginning", the 2-key to "previous key frame", the 3-key to "start/stop playback", the 4-key to "next key frame" and the 5-key to "jump to the end". The start/stop key toggles and starting playback when the playhead is already at the end of the animation will start the animation from the beginning, but only once when the looping toggle button is unselected. Non-shortcut controls for shortcuts There are actually some nice features in Spriter which are (as far as I know) only accessible via shortcuts, but each good user interface should also enable the possibility to achieve the same result with a "normal" way. For an example the B-key needs to be pressed and holded when assigning images to a bone. This is a common situation and it is good to have the B-key possibility. However, why doesn't exist a "normal" way for this action? Well, you can drag and drop the images in the hierarchy view to assign them, but that is actually an other action. It is "changing the hierarchy", but "assigning to bones". There should be a button or something like that to activate the behavior of assigning images to bones (which in return indicates as a mouse tooltip that it can be also toggled with the B-key). This is not only a plus for those who don't want to use the keyboard, but also for all those who are new to Spriter and don't know anything about this shortcut or have forgotten the actual key binding. So my suggestion for additional controls (buttons or menu entries or something else) in addition to the B-key action are controls for the Z-key "bone tree selection" action and the shift key for "IK animations". Common actions like the command key for cloning of course don't need separate buttons (however could still profit from a menu entry). Double bindings The alt key (at least in the mac version) is bound to the equipped tool which is creating new bones as default. When scaling an image while holding the alt key is as mentioned in a video also bound to the action to scale the image relative to an edge rather to the pivot point. That is a double binding which should be avoided, because it tends to create bounds when trying to scale the image, so scaling should be bound to an other key and in addition have an own control element as mentioned in the passage before. Exact values for all properties For most properties like scale and position of an image there is a rough input possibility just by using the mouse in the canvas. For all those rough entries there should also be a possibility to enter exact values. For scale and position there are possibilities in the Object Properties view, but there is no possibility to fine assign the pivot point. Normally it should be enough to move the point roughly, but there is also the possibility to assign a pivot point as a default for images in the files view. So why is there no exact input possibility in the Object Properties view? It should be. And it should also be possible to set the spin direction in the properties instead of workaround the rotation direction by adding a new keyframe at a point with less than 180° changes. File type association Neither the scml nor the scon files are assignable with Spriter (on Mac, don't know for Win). It would be nice if a double click in Finder would open Spriter right away with the selected file loaded. At least it should be able to load a file via drag&drop on the icon or by right click on a file and choose Spriter by "open with". Project and exported files You should consider to separate Spriter project data from exported animation data. At the moment everything seems to be in a huge scml/scon file, both data for animations needed by implementations in games and meta data used by tools like Spriter. This way there are instructions like obj_info which are not needed by games and only makes the data unnecessary complex, the file big in size and increases the parsing time. I think it is better to have a project file which holds all the data as it is in today's scml files (maybe with the extension ".spriter" instead and gets an association with the Spriter tool). The project file is therefore only for designers and all other tool stuff can be saved in it, like interface restoration properties. This project file is of course only for Spriter (why bother for other editing tools, they will probably have their own project files). Spriter then needs an export button which writes only the data needed by a game binding in a new (scml/scon) file. While exporting Spriter asks for the file type and the file version. With the first you can choose wheter it should be XML or JSON (or maybe another format introduced later) and with the latter you choose the file's structure. The latter is important to be compatible with already implemented game bindings. So when there is already a binding which won't be updated to a new file's version you can still export the data from Spriter with the old version so the binding can still import and use the data. However, you should update the exported file's structure with time, because there are many obsolete properties and structures in the current scml file which may be optimized, like the timeline key - object relationship or the path in a file's name what is not needed because the folder already has the path in it's name. To make the creation of new bindings as easy as possible (and that is what you should want by now, because easy binding programming will make Spriter available for more engines by the community, so more people want to use and buy Spriter and that is also why you should definitely improve the documentation) the exported files should be as clean as possible. That is what the file's version number is good for. Increase the latter number (1.0 -> 1.1) for structural changes only affected by the file itself, i.e. merging the object tag into the key tag so only a bindging's file parser is affected. Increase the first number (1.0 -> 2.0) if the data model and the logic behind changes so the binding itself needs to be changed, i.e. letting objects already vanish when there is no follow up keyframe or a tag like the looping flag has been removed. If the file's structure is extended with additional tags, i.e. a new property like the chained animation is introduced a third version number should be increased (1.0 -> 1.0.1) to indicate which features this file supports, but normally a paser and the binding is backwards compatible for these version changes and don't need necessarily to be updated except the new feature should be supported. Default values in files Speaking of the exported files and their structure. Not all properties are always set in the file. It seems defaults are often skipped so if the first key frame in the mainline is at 0 ms the property "time" will not be saved to the file. For the time property it may be reasonable, because 0 is a default value in most programming languages for an absent value, but there are other default values which are not 0, but missing in the file, like the alpha value or the looping flag. The default alpha for Spriter is 1 and for looping "true". Especially looping will never be set to "true", only to "false" or it is missing at all. This is really no good manner. In my opinion every property should always be exported, no defaults should be missing so no assumptions are needed, especially with a lacking documentation. The additional characters in the file and the increased parsing time are worth to get rid of the ambiguousness. At plus this way it is easier to tweak some values in the file manually, because their properties are already there, only the value has to be changed. However, at least the missing properties should default to 0/false and no other values if you really don't want to print them, but in this case I think it is better to have a "compression" flag while exporting which writes a file in a structure which is more optimized for disk space savings, i.e. a binary format. Objects with no follow up keyframe An object is animated during two keyframes so it is locked on both keyframes. The properties will be interpolated between both keyframes. When the object is only locked onto one keyframe and not on the other no properties will be interpolated and after reaching the next keyframe this object will vanish. Well, this time between the locked keyframe and the next where the object is not locked on the object stays totally immobile, only moved by bones. I think it would be better to remove the object already when there is no follow up keyframe for it. So when the object is not also locked on the next keyframe it will already vanish after the first keyframe, because there are no properties to interpolate to. If it is not meant to vanish that soon just add a keyframe with the same properties at the position where it should vanish, but if an object should vanish directly after an animation a new keyframe only a few frames later is needed only for not locking the object, to reduce the time of immobility and let the object vanish earlier. My suggestion is to adopt this behavior of removing when no follow up keyframe for the object exists with an update of the export file to be backwards compatible. Chained animations At the moment each animation stands for itself. The game has to tell the engine which is the correct animation to play and also has to handle with the end of an animation by telling what to play next, but often it is already clear by the time of the animation creation. As an example when creating a "get from stand into crouch animation" the default animation which follows should be a "crouch idle animation". So it would be nice if the designer can already chain the "crouch idle animation" to the end of the "get from stand into crouch animation". The engine can then apply the correct followup animation automatically when there is no other input from the game logic. My suggestion is to have a single entry field or drop down box for choosing one of the other animations in the same entity which should be automatically played by the engine when the first animation ends. "None" should always be possible to set for "normal fire and forget" animations. Of course the second animation may chain again to another animation or to itself for cycling, which an "idle animation" will normally do. So this request is only another property bound to an animation which will be saved and shouldn't have much impact on the Spriter tool itself. However, I think this chaining feature will be useful for reducing game logic code and it replaces the current loop button. Cheers