Spine - 2D skeletal animation tool
Monkey Archive Forums/Digital Discussion/Spine - 2D skeletal animation tool
| ||
| http://www.kickstarter.com/projects/esotericsoftware/spine |
| ||
| Looks pretty good. |
| ||
| How did this already got funded and Objecty didn't? |
| ||
| How did this already got funded and Objecty didn't? Because the programmer is the co-author of Libgdx? |
| ||
| This looks great, would love a Monkey/BMax Runtime. |
| ||
| Amazing tools these - even a gfx pleb like me could do some nice stuff. The only problem is you still need the base images!! |
| ||
| How did this already got funded and Objecty didn't? And there is also a tool called Spriter, which does an awesome job already. |
| ||
| I've been meaning to relook at Spriter and the "new" alpha is great! Might be time to update my prototype Monkey loader... |
| ||
| Already bought into Spriter, but Spine looks good too. Of course if you can't load the output into your favorite Monkey framework(s) then it is not much more than a novelty. The thing I really like about Spriter was the planned support for named action points, collision rectangles, and triggers for sound samples on a per frame basis. On the other hand, I almost think that Spine seems to be more feature rich for basic character animation and reuse of the bone model. Had to laugh at the quote from the Spine guy about "So easy even a programmer can do it!"... Alas, with Jon's (skn3) Objecty, "We could've had it all all all..." I think one of the biggest problems was funding in Pounds Sterling versus the almighty ( maybe a stretch ) dollar... |
| ||
| Objecty's campaign was asking for £20K, Spine asked for $12K. That's a huge difference in terms of backers believing it's a goal that will be met. Also, while Objecty potentially offered a lot more, that scope also brings doubts about feasibility. Flipping the question around a bit and asking why Spine is being funded considering the existence of Spriter might also shed some light. Spriter, while progressing, still hasn't delivered v1.0. Spline is offering less functionality but is also presenting as being more likely to deliver on promises. |
| ||
| @muddy_shoes - Agreed on all fronts, very good comparison and analysis. Now since I have committed funds to both Spriter and Spine, need to find time to actually play around with both of these. Then there is the little problem of actually using the exported data with monkey :) |
| ||
| I just read the entire Spine Kickstarter page (yes you have to scroll down), and it is good to see that some (if not all) motivation for Spline is coming from lack of movement on Spriter. So it looks like Spline has all of the same planned future features of Spriter and then some. Not sure what it would take to integrate the output into a Monkey framework, but there is the option of paying $3,500 to make Monkey a first class citizen. Is there enough interest in the Monkey community for someone (read not me) to start a separate Kickstarter to raise $3,500 that would then be used to pledge that amount to the Spine project in order to get Esoteric Software to develop a Monkey Runtime? If nothing else, it would raise awareness of Monkey and if it was funded could do even more to bring future Spine users over to the "Bright" side that is Monkey! Not much time to get this going, as there are only 18 days left in the Spine campaign. |
| ||
| So you can't develop your own runtime for Spine? Is the file format an open one? |
| ||
| It spits out JSON so it's open to an extent at least. I'm not sure what the licensing is for the runtime code they have for libGDX. It's unlikely to be amazingly difficult to convert from Java to Monkey. |
| ||
| @MikeHart - As muddy_shoes points out the output will be JSON, but I don't think there is any gaurantee that it will be documented and I think it would prove difficult and challenging to keep up with future enhancements. I would think that an officially supported Monkey target would be the way to go on so many levels. Have a read through the "RISKS AND CHALLENGES" section on the kickstarter page, here is one example of why it would be better for Esoteric Software to build and support the Monkey runtime for Spine: We've spent an enormous amount of effort building Spine with great attention to detail and high standards for quality. We want to build the runtimes to match so that the entire Spine experience is seamless and pleasant from start to finish. So they actually "Want" to build the runtimes, and for $3,500 they will actually commit to build a runtime for Monkey. |
| ||
| I have invested in Spriter, so I have no need for Spine. |
| ||
| Hard to say, I also invested in Spriter and Spine. Based on the Spine Kickstarter it was created to address some of the shortcomings they found with Spriter. I guess for lack of interest by the Monkey community, the least I could do is contact Esoteric Software and put in a good word for Monkey. I will post back here if I hear any encouraging words... |
| ||
| There's nothing wrong with mentioning it to them but I'd be surprised if they saw Monkey as a priority. The numbers just don't add up. Equally there's no real reason for the Monkey crowd to be clamouring for a Spine runtime considering that most games don't need skeletal animation. Finally, even for those of us who might see a need for the tools and who have already backed Spriter and/or Spine, raising $3500 to get the runtime converted doesn't necessarily look like a good deal. It seems unlikely to me that Esoteric would have more expertise in the ins and outs of Monkey than the better programmers here who have been using it for a significant period. |
| ||
| @muddy_shoes - Yes, the cold shower of reality is refreshing... :) |
| ||
| Spine looks great sad times for me though as creator of Objecty! Spine definitely are doing things far better then spriter. There were a few factors that really killed the Objecty campaign: - I didn't have a demo for launch as I wanted to hit the UK kickstarter launch - the initial edit of the video (even with 10+ previewers detailed feedback) wasn't informative/short enough - there was a currency exchange rate issue which affected a lot of the first UK kickstarters, trying to hit the sweetspot amount of £15 didn't translate well to $ - objecty appeared to do to much too soon - most of the views the campaign got we're before I managed to rectify this all. - the unreachable target effect as was mentioned in the thread The annoying thing is most of the mistakes that made it fail we're because of advice I had taken from other people. I ended up ignoring my own instinct for many decisions.. A mistake I won't make again. Maybe good advice for anyone else working by themselves, take people's "advice" (opinions) with a massive grain of salt, trust your gut! Anyway, without meaning to hijack this thread... Spine truly looks awesome, I hope they don't turn out to be another spriter! For now objecty will remain inhouse! |
| ||
| Can some please tell whats the team behind Spriter has done wrong? They are still developing it and pretty active in news etc... |
| ||
| @Skn3 - "because of advice I had taken from other people". Been there! I "feel" that emotions are often underestimated in today's world :) Spine & Spriter open so many game possibilities. I do agree almost no games use skeleton animation, or need it, but imo in 2D there is a lot of games that could be much cooler by using it and it opens up an array of new possibilities, especially for indies. Here is the latest Spriter update: http://www.kickstarter.com/projects/539087245/spriter/posts/396549 Seems progress does exist! Spine does look slightly better. Wounder if someone will do a cross-exporting tool. |
| ||
| Can some please tell whats the team behind Spriter has done wrong? Same here. I don't understand it. Imho, the gui of Spine is overloaded. When I saw the video, everything was so crowed in these listboxes, it looks like an app made by a programmer for artists. Spriter gives a different feel there. Functional wise I think both apps are on par, maybe Spriter is more far ahead. I am looking forward to the next update that shoudl be out in the next days. What the Spine team wants to implement is also just a plan. You will never know if they will do it or not. They have already mentioned that for version 1.0 they will have only the LibGDX runtime ready. God knows when and if they will deliver the others too. They have also mentioned that they rather create these runtimes themself. I Also don't like the fact that the Spine team advertizes their app by downgrading Spriter. they did this in KS and also in messages to other developers. Spriter is actively developed and works. Their API/file format is open and everyone can get it. The Spine developers don't want to do this because they rather cash in the money for doing it themself. I simply don't like the attitude around Spine. |
| ||
| Personally it just seemed they have made it up as they went along. They offered a version for the kickstarter, people got behind it and got excited. Then they missed their deadlines because they decided to do a complete rewrite in another language. It's a good decision but its a little bad form when you have backers. In the long run I am sure it will turn good but I think they promised much and have only just started scratching on some of those promises. I guess a good analogy would be if the ouya console missed deadline, didn't regularly update and ended up releasing a console that ran windows mobile instead of android. |
| ||
| MonkeyCoders can also simply use Spriter and Spine for character animation to export sprite sheets that can easily be used in Monkey. Spriter exports just the keyframes at the moment, but they promised more. Not sure what Spine does or will offer for spirte sheet export? Ease of character animation and reuse of the bone structure ( at least with Spine ), for sprite sheet export were the deciding factors for me to support both of these products. Having a Monkey runtime for the skeletal animation with event, sound, physics, and whatever else these guys might add would just be icing on the cake. Would be interested to hear how others are using or planning to use either Spriter or Spine with Monkey and/or any of the available Monkey frameworks? |
| ||
| If you don't understand why Spine is cool then it's not for you. It does a lot of things Spriter doesn't already do. I have messed with both a bunch and backed both and I think both will have a place in use. Spriter is still really cool, very useful, and enough for a lot of people. The spriter dev has a physical injury which has made it difficult to make progress as quickly as he wanted, but I'm still supporting him. Still, some people did not want to wait so they made the tool they wanted to use themselves - and it's already mostly made to the point of being useful just missing support for different tools. It's good to support competitors anyway. Please don't be needlessly fatalistic or pessimistic. I support a ton of projects which I don't personally use because I believe in helping others who want to make things for everyone. >>export sprite sheets This is what the tools are made to avoid doing. You really shouldn't do this! I'm sure we'll have good Spriter and Spine support with Monkey eventually. |
| ||
| I contacted Esoteric Software to see what the chances would be to get a Monkey runtime developed or what other options were available for the Monkey community, I am sure other Monkey Coders cast their vote too. Good News, just got this email from Estoteric Software: Esoteric Software (February 7, 2013) - After much deliberation, we finally came up with stretch goals for Spine! The number of requests we've received about which toolkits to support has been mindblowing. We really want to make everyone happy and we think we have come up with a great approach: by providing generic toolkits for many programming languages, implementing new runtimes becomes a breeze. This has all the benefits of officially supported and maintained runtimes, but also allows the gaming community to easily implement their own. We can work together with the gaming community so Spine can support any toolkit! @Soap - This is what the tools are made to avoid doing. You really shouldn't do this! Don't see any harm in generating sprite sheets with Spriter or Spine, I currently use Flash Professional CS6 to generate sprite sheets and I would much rather use either of these tools to do the same. @Soap - I'm sure we'll have good Spriter and Spine support with Monkey eventually. Yes, eventually..., but even then there will be significant overhead involved when implementing bone based character animation inside a game and I don't think sprite sheet based animation is going to be replaced by this. |
| ||
| Why? There are already plenty of other animation tools which support all kinds of bone and IK 2d animation but are meant for rendering frames and not meant for having the stuff render in game. The whole point of the tools is to avoid that waste. >Yes, eventually I've been waiting for Spriter 1.0 before taking on a project with it. If no one else beats me to it (therevills) then I'll make sure it's working when I get to having time to work on a project which uses it, and the same for Spine. >there will be significant overhead involved when implementing bone based character animation inside a game What? >and I don't think sprite sheet based animation is going to be replaced by this. Again the whole point is to minimize waste and maximize reusability. Smart devs who are working on appropriate projects will use it. I have several possible projects lined up which I wouldn't dream of doing without a good bone system because doing all of the characters with sheets would create a much larger payload than I'm willing to budget. >How did this already got funded and Objecty didn't? Boils down to marketing. Every site which mentioned Spriter should have been contacted about Objecty. I don't know how much press Objecty really had but I didn't see much effort put into that. Objecty should have been funded. |
| ||
| Why? There are already plenty of other animation tools which support all kinds of bone and IK 2d animation but are meant for rendering frames and not meant for having the stuff render in game. The whole point of the tools is to avoid that waste. I don't know about all those other tools, I only have used Flash Professional and was looking for a better solution that is why I support both Spriter and Spline. I like the idea of using one tool for animation and target sprite sheets and in game bone animation, depending on the requirements of the project. My impression was that these tools are going to offer exceptional animation capabilities, I dare say this is another "point" of these tools not just to avoid the waste. I guess you are saying that there are better animation tools out there, it would be really helpful if this forum had a sticky topic listing out everybody's favorites (not just for animating), with a little blurb about how they are used and why they are useful. >there will be significant overhead involved when implementing bone based character animation inside a game @Soap - What? Processing overhead when compared to flipping through individual images directly from a sprite sheet image file. My impression is that you animate each bone segment independantly, more moving parts, more overhead? On the other in game bone based animation could bring less memory consumpution and the potential for smoother animation by not having to worry about building massive sprite sheets for more detailed animations. |
| ||
| I've started my Spriter Importer again for Monkey, its still WIP but you can see it in action here: http://www.therevillsgames.com/monkey/SpriterA4/MonkeyGame.html They totally changed the format... |
| ||
| @therevills: Not bad, not bad. |
| ||
| Awesome! |
| ||
| Looking good :D |
| ||
| > more overhead? Memory usage and binary size, especially on mobile platforms, is way more of an issue than what's needed to animated a few parts. If you have dozens of characters at retina resolution with tons of frames of animation you are going to have a lot of limitations - so many that for games which can really use animated characters like that I just would not do them if I baked everything into frames. That's only the memory concern. You want to customize stuff after making it? With baked frames that requires much more memory and binary space, and it's much more work to change things. With broken up parts it's as easy as changing one small part of an animation and then saving it, or editing one part of a characters whole. All the problems with those methods are meant to be solved with tools like Spriter and Spine. > Spriter Importer again for Monkey Woo! :D |
| ||
| @therevills cant wait till this is finished and in Diddy , anything that can help streamline the process of creating game art and then animating it will help so many people. I have to agree getting rid of sprite sheets is a good thing they consume so much space in video memory if your using a lot of actors. Whats even better is that with systems like this you can have 100 actors that essentially all use similar parts and in the end taking a fraction of the resources required to load and use them, as opposed to having 100 unique sprite sheets for each of their animations. |
| ||
| Memory usage and binary size, especially on mobile platforms, is way more of an issue than what's needed to animated a few parts For some circumstances, yes. For others, no. If you want to have dozens of instances of the same character on screen (zombies, infantry, whatever) then doing bone animation for all of them is going to have a significant processor overhead compared to using standard sprites. It's a useful technique but not universally superior. |
| ||
| @Taiphoz: I have to agree getting rid of sprite sheets is a good thing they consume so much space in video memory if your using a lot of actors. You'd still want to store them in an atlas if possible. Less texture rebinding = less vertex pipeline flushes = faster. |
| ||
| At the moment, Spriter doesnt support atlases... I thinks its on their TODO list. Texture atlas (spritesheet) support via texturepacker integration. <coming soon> http://www.brashmonkey.com/spriter%20features.htm I guess I could change the Monkey Importer to use an atlas. |
| ||
| You shouldn't have any problems converting it yourself. Use separate image files in Spriter, use another program to generate the atlases, then just make sure the names in your atlas xml/txt file match the expected image names in your Spriter file. |
| ||
| @Samah yeah I was talking about long strips of animation frames, of course your going to want to pack all of your little body parts, you just wont be wasting tons of space with unique animations as its all done in real time. |
| ||
| @Taiphoz Actually I was replying to therevills's comment about the lack of atlas support in Spriter. |
| ||
| >For some circumstances, yes. For others, no. If you want to have dozens of instances of the same character on screen (zombies, infantry, whatever) then doing bone animation for all of them is going to have a significant processor overhead compared to using standard sprites. Sure.. but I think most situations memory usage will be a bigger problem than how much cpu you are using - at least that has been the case for my project. Plants vs Zombies used an animation style which Spriter/Spine allows. That game has tons of units on screen possible all being animated at once - every plant and zombie is made up of a bunch of smaller assets. If they had done all of the animations possible as baked frames the game wouldn't have looked as good, it would have had a much larger binary, and it would have taken up much more memory to have all of those frames loaded. Just not acceptable. There are still situations where using sprites makes sense. Like if your characters only have a few frames possible, you don't need smooth animations, and you want a ton of them displayed at once. Yes! You should still use texture atlases. It speeds up loading time and lowers waste of memory also. Not using texture atlases is so dumb. Every texture you have in your game takes up to the next power of 2 in memory without using texture atlases. It also takes more time to load each individual asset, and if you have an HTML5 game each asset is an additional request for the browser to do. If you want your tool/framework to be taken seriously then you need to keep using atlases in mind. |
| ||
| Spine looks pretty complete already, it also looks genuinely useful for me personally, so I have KS backed it(well really to get a cheap early-bird licence! :P). Thanks for the link! :) |
| ||
| So will it be possible to write importers etc for Spine ourselves, or is the format closed and we have to raise the $3500 for them to write the Monkey exporters for us? |
| ||
| @rIKmAN - As of February 7, 2013 they decided to drop the idea of writing and maintaining "Full" runtimes for game engines except for the original 3 (Unity Futile, Unity 2DToolkit, and cocos2d-iphone), plus Corona. However, they added stretch goals for other languages to build and maintain "Core" runtimes that do everything but the actual drawing. Unfortunately Monkey didn't make the grade, so it is unlikely we will see an officially supported "Core" runtime for Monkey. I don't see that there is anything stopping anyone in the Monkey community to create the full game engine to support Spine output. It would be a matter of choosing one of the runtimes that is officially supported and using that as a base for a port. Of course that makes it more difficult to keep up with changes to the output of Spine, but we have yet to see how that process will work. They (Esoteric Software), did say they would work with the community so there is a chance that someone could create and maintain a Monkey "Core" runtime and have better coordination with Esoteric on implementing changes. |
| ||
| @rIKmAN - They just reached the stretch goal for C++ and it is good to see some documentation on the export format http://esotericsoftware.com/spine-json-format . Will be interesting to see what a "Core" runtime is going to look like. |
| ||
| Ah good news, thanks for the info Andy! |
| ||
| http://www.kickstarter.com/projects/esotericsoftware/spine/posts/406637 |
| ||
| http://www.kickstarter.com/projects/esotericsoftware/spine/posts/408039 |
| ||
| http://www.kickstarter.com/projects/esotericsoftware/spine/posts/410470 https://github.com/EsotericSoftware/spine-runtimes |
| ||
| Spine is on a roll and continues to knock off more of the stretch goals! FWIW, I didn't realize that my message to Esoteric Software on February 5th was answered within hours, but went through the kickstarter email system on the website. We'll be holding a poll today (Feb. 6th) to vote for which additional toolkits we'll support because of the Kickstarter. We'll do an update to publicize the poll and we'll be sure to include Monkey. :) Thanks for the pledge and for dropping us a note! :) -Nate Of course this is history now, but it was nice to see that Monkey got a little love. Little less than 2 days now for MonkeyCoders to get in on this, get your discount, and help boost the feature set in the process. |
| ||
| OK, I pledged. Now what? |
| ||
| I love how it looks , but not going near it without support for monkey built in. |
| ||
| Hey! this is the first time I really look at it And It looks So familiar. They use a lot of my ideas. I wonder if they looked at my code before starting on their project: bones <---designed Jan 2011 |
| ||
| I love how it looks , but not going near it without support for monkey built in +1 Just too much of a headache later otherwise |
| ||
| OK, I pledged. Now what? You wait till the Kickstarter has ended and if its fully funded (as Spine will be), they will take your money and you wait for your "reward"... @Jesse... that zip has my graphics in it, you cheeky bugger :P |
| ||
| yea, I stole them when you posted them over at indiecodez in your same type of project. :) if it bothers you or feel uncomfortable with me using them, I can replace them. Sorry for plagiarizing, I should be shot. |
| ||
| Nah, its cool - I actual LOL'd when I saw it :) |
| ||
| You know what, I think I'm going to bribe/harass them into giving me a free copy once is released. I really wish I could afford to contribute but I am really broke so I'll do the next best thing. :) |
| ||
| Just backed it (First kickstarter project I've supported!) While I won't have a use for it anytime soon, it seems like a worth while app and I like the fact they're building a generic C++ runtime. |
| ||
| http://www.kickstarter.com/projects/esotericsoftware/spine/posts/411140 >Hey! this is the first time I really look at it And It looks So familiar. They use a lot of my ideas. I wonder if they looked at my code before starting on their project: Many, many, many studios have created fully featured tools like these over and over again - just never released to the public. Some studios even made multiple versions internally without knowing that people on other projects were also making them! First ones I know about go back to the late 80s. |
| ||
| I am sure the genera idea is been thought of hundreds of times over but there are two many similarities in Spine that are too much of a coincidence to ignore. Either that or I am a hell of a psychic. Any way I was just making a silly comment. I posted the code in a couple of places for anybody to do as they like so I should have not been surprised either way. Note that until I saw Therevills post over at indiecodez I had no idea there was such a software or any thing closed to what I had done. Honest! Lets compare, Spriter does not look anything like mine but spine has a lot of similarities. if you don't see the similarities what can I say... just ignore me. if anybody else think I am exaggerating I apologize. |
| ||
| Often good ideas are redeveloped by people interdependently. Likewise you both could have had the same inspirations which lead you to your own designs independently (far more likely imo). I've seen one of the private tools by a major publisher and it is very similar to Spriter/Spine in ways. It's really absurd how many things have been made over and over again because some people didn't want to share/market. |
| ||
| It really is not that important. If you say it isn't than it isn't. |
| ||
| What is important is to make your pledge now with less than 9 hours to go. If you have some spare funds and are even remotely interested in seeing what could be done with Spine output and Monkey, then now is the time to buy in. You get a discount on the license, all future releases of the product, and can help the project reach the final stretch goals. |
| ||
| I pledged! Worth backing even if it is sour grapes for me :) |
| ||
| Looks like a worthwhile tool to have; already coming up with game ideas I've never had before. I pledged! |
| ||
| @Skn3 - A bitter pill to swallow for sure. If it is any consolation, I think all of us here in MonkeyLand would have been much better served by Objecty, so it is bittersweet for us too... Cheers to you for supporting Spine quite a noble gesture in my book! |
| ||
| Cheers :)) |
| ||
| 1,533 backers $67,569 pledged of $12,000 goal That means the only thing they didn't get to is "Free-form deformation" but...I bet they will add that later on anyway. :) In the end, it's good for all of us. These kinds of tools are a huge advantage to those who use them. |
| ||
| I thought they might have got a bit more than Spriter due to the lower goal: 1,844 Backers $71,179 pledged of $25,000 goal http://www.kickstarter.com/projects/539087245/spriter |
| ||
| Shows even more how important Marketing is! |
   |