(update 10/5/2015)  Hi everyone, still making very good progress.  Barring any unforeseen external delays, we plan to have an implementation supporting all current features either released or available for testing in approximately 2 weeks. [LIST] [*][b]Planning/Overall Design %99 [/b] This is the most important and difficult step - determining the overall structure and design of the implementation. Considerations that have weighed most heavily on the design are speed, memory usage, extensibility, and ease of porting to other languages.[/*] [*][b]Data Model 92%[i] [/i][/b][i](^2)[/i] This is where all of the data will be stored. It will contain your entities, animations, timelines, keyframes, etc, and will basically be an optimized version of what you see in the file.[/*] [*][b]Flyweights 92% [/b][i](^2)[/i] Most of the data required to animate a character can be shared for every instance of your character. If you have dozens or hundreds of the same character, you don't want to make a copy of all of the characters animation data over again. The flyweights will only store the fully processed information about your character's current state. The transformed x and y coordinates, the current image to display for each sprite, etc.[/*] [*][b]Iterators 92% [/b][i](^2)[/i] These will traverse the data structure and update the flyweights. These will store behind the scenes state information about each instance of a character. Their main purpose is to make it so the flyweights can update their state from main data model as quickly as possible, without having to repeatedly locate their respective timelines, or loop through keyframes to find a specific time.[/*] [*][b]File Handling %27 [/b][i](^2)[/i] To make file handling as painless and easy to port as possible, the loading of the data structure won't be tied to a specific xml or json library, requiring every port to replace every individual command. Instead, there will be a handful of general commands to find keys and retrieve values, and the code to load the data tree will be composed of these generic commands. When it's time to port to a new language or xml/json library, the developer will only have to worry about coding in the specifics of that handful of generic commands, instead of the entire loading routine.[/*] [*][b]Interface %82 [/b][i](^2)[/i] This is the only part that users of the implementation (as opposed developers working on the implementation itself) will ever have to see. It will provide a clean and intuitive list of commands to do things like play and pause animations, change animations, set playback speed, etc, as well as ways to retrieve specific information, like the current time within the animation, current animation, etc. For game authoring tools that provide users with a graphical interface, this section will also serve as a complete guide that can be used to ensure that plugins for those authoring tools have all of the same power and flexibility.[/*] [*][b]Test Bed %92 [/b][i](^2)[/i] Since this implementation won't be tied to a specific display or file handling library, this will be what we use to test as we complete the reference implementation, as well as a way to demonstrate progress, and demo the completed implementation.[/*] [/LIST] [i]original post: Hi everyone, We posted this on our KickStarter page a few days ago. Sorry we were a bit late to post it here. Here's a somewhat itemized list of what needs to get done for the reference implementation to be finished, along with a rough percentage that I feel I've completed for each component. I'll be updating this list at least once a week until the reference implementation is finished and released as open-source on github. With each update to the list, the percentages will become more concrete, as will the items within each section. I'll also be able to mention more specific details of what I added to each component as things progress. Please take the percentage estimates with a grain of salt, as, until the testing has reached a more involved stage, it's difficult to know exactly how close to finished something really is. It's equally important to remember that the percentages don't necessarily represent an amount of time relative to how much time has been taken so far. Expect the next progress update to this list by May 17th at the latest. Finishing this implementation is my top priority, but of course if any critical bugs are found in Spriter itself they will be dealt with immediately. Thanks again everyone for your patience and support.[/i]