• Editor
  • Official support / state of Spine?

  • تم التحرير
Related Discussions
...

I had a question for the people on this forum about the official support / progress through the backlog of bugs. Our studio is full of experienced game developers and we love the tool in general, but wanted to get some clarity / conviction on the long term life and support of Spine before we commit to it as our animation pipeline.

So for the people who have been using Spine / have been active on the forum for a while:

Lots of questions, but answers / relevant thoughts from anyone would be much appreciated!

Assuming your main worry (asked in many questions) is, how reliable will Spine be while you're using it. I could talk about how support has been great historically, and that, historically, there were mere weeks between editor updates with really nice features, and the runtimes were also fixed left and right. I don't think I would have become a regular here at the forum and a contributor to the runtime had it not been for the stellar work that was done on Esoteric's side. I may have knocked a bit too hard on the door some times, not gotten a few feature requests, but things got done, features got pushed out, sometimes so fast that a lot of bugs got caused, but bugs got fixed too.

But I don't think these stories of the past is any reassurance to you, nor would they be any answer to these questions, looking to the future. Logically, not being able to say "all things held constant", you couldn't extrapolate.

Though as far as I can claim to know Nate and Esoteric, I would dare say right now is a very peculiar but temporary situation. I've been in contact with Nate. He's alive and working on the thing and hasn't turned into an asshole yet. If you're worried about being screwed over, IMO, that fear would be unfounded. Though let's do hope he doesn't keel over and die (for his sake, of course). They've got so much planned for Spine in the future and— I think— they're not in any financial trouble.

THE MAIN THING TO KNOW: There's a major— and, in my opinion, necessary, practical and beautiful— overhaul of the bone transform inheritance system that was a lot of work but is (mostly, according to Nate) done. That's what's being called Spine v3 and it's a total system thing. Both editor and runtimes need to be updated.
That's really what's blocking many of the other things from being fixed/updated. The fixes highly depend on how v3 is implemented.
Release should be any week now, and the weeks following that will maybe be chasing after little regressions users catch.

A number of active Spine users have been given authority to check on the runtime repo, check bugs and fix them if they're straightforward enough, look into optimizations, etc. As far as I can tell, Spine-Unity's got the best action going because of contributors. But even we're blocked by Spine v3's upcoming changes.

Right now, you'll probably get really good support asking your questions here in the forums than through email, especially while v3 is juuust right there on the horizon.

I'll let official Esoteric explain the rest.

What kind of decision are you about to make that's making you worry anyway?
You said you "love the tool". Have you not been using it already?

Thanks for the detailed response, Pharan. I appreciate it! 🙂

You're definitely right that one thing I wanted clarity on is the long term reliability / keeping up with runtime updates from Esoteric on Spine, and it's great to hear that you've had positive experiences in the past with Nate and the tool. That's really good to hear. 🙂

I would doubt that Nate (or anyone else that works at Esoteric?) would turn into an asshole and intentionally screw over users of the tool. Even if so, the loss we would have there is less about the $300 spent on the tool and more the investment of establishing a studio's workflow and content around that tool.

Also good to hear that there's an update coming soon. Is there any visibility on the status of that / the roadmap of features to be included there?

My experience with the tool thus far has been evaluating it as a fundamental part of our art pipeline as we scale up our studio. I've worked with variants of this 2D deformation tech for quite a while and I have multiple friends at other companies that have used the tool and weighed in with their opinions as well, which have mostly been positive.

The information I'm mainly looking for isn't about concerns that the company would screw over its users intentionally, but more of what the current scale of the team and its velocity towards improving the project / supporting it look like. Many of these tools are small teams that need to focus on a small set of features / improvements and it often means that official support gets (unfortunately) dropped by the wayside. Not anything against the teams, but it does make committing to a tool more concerning if things don't work out.

As an example, one of the things that we're going to need to achieve the visual style of the game we're working on is changing out a mesh region while preserving the FFD, which has been on the backlog for over a year. Totally understand that it can get de-prioritized for other work (like a rewrite), but was trying to get an understanding of what reasonable expectations for turn around updates to the editor / runtime, feature requests and bug fixes looks like (very dependent on the size of the team).

My strongest preference would be to not be a burden on the Esoteric team for features that our team definitely needs - I would love to just be able to license access to the editor's source so we can make the changes that aren't a high priority on the current backlog. 🙂 We're a team of very experienced game developers and could be updating the editor to our needs and contributing back to the original repo to improve the product for all of us.

Spine clearly looks like a solid product of passion for the Esoteric team. I just want to make sure that if our studio commits to using it we're empowered to make the fixes / updates to our workflow to not slow us down.

Hope that helps clarify the specifics of what I was curious about. 🙂

I'm afraid to tell you the best thing you can do is wait for Spine v3 and only then decide if you are going to invest in Spine v3 or not.
The problem is that supposedly Spine v3 already has more than a year and no one here really knows the future features of Spine v3. The official support is currently a bit poor (there is only support for the same customers in the forum).
I as a new buyer would advise you wait for the supposed Spine v3 or go another tool like Creature kestrelmoon or others.
Currently Spine 2 has several bugs without fix right now because Spine v3 is in developing (it makes sense but it supposedly happened one year).

Its true that the past of Spine is brilliant but right now the support from Spine does not give me a good taste in the mouth and I dont know what think about. As a buyer already give me some concern about the investment I made on Spine (as is common for any buyer who has a silence of the seller).

On the other hand I dont know if in the supposedly release of Spine v3 the price will be increased, so buy it or not is your final criteria.

Good luck

Oh, so you're about to scale up your studio and will need to invest time in like... R&D stuff for everything? So you have to decide if Spine is the right tool to use. Sounds fair.
I agree with newbacknew. If you're in doubt— and justifiably so from all this eerie quiet— wait for v3 to come to full bore. (Also for Esoteric to answer your questions themselves. I have a hunch some of them need to be answered privately.)
You have to know Spine's technical support team is puny. But Nate did mention that they're trying to add a few more people to speed things up.

Spine's ready for production as it is and big companies like Rovio are and have been using it.
The question is probably if it's ready for your uses, precisely because some of the features you need may not be there yet.

Your let-us-help-mod-and-develop-spine-editor proposal aside (I know I'd love the same opportunity),
If you're looking for more information, I think it'll be helpful if you detail each need you have on its own thread.
Like you need the mesh swapping thing. You could ask if the particular set of things you want to happen (runtime and workflow-wise) is supported.
That stuff also guides Spine's development as a workflow use case if the feature's not there yet, and you'll get feedback on how long that'll probably take, or if it's actually already doable now.

The implemented features would be here: http://esotericsoftware.com/spine-changelog/
and the idea pool and backlog is here: https://trello.com/b/frGlgsF7/spine-editor
There's also the far-out-into-the-distance stuff like the cutscene editor.

nozomiyume wrote

How is the support? I've tried to reach out via the contact link on the support page and not received anything back. 🙁

Sorry you didn't get a response. I don't see any messages from your email address?

Is Spine still in active development?
How quickly is the backlog getting addressed?

Yes. You can see the update history to see what is typical for us. Lately we haven't been releasing updates though, due to having a large update in development and frankly some burnout and need for a break. We had been pushing hard for over 3 years and eventually that catches up with you. We are back on the horse and will go back to updates much more often soon.

Is there a roadmap of expected feature delivery anywhere?

There is Trello, though I'm not super happy with it. It tends to be a jumbled mess, especially with so many "ideas" and features that we want to implement, but not in the near future. We plan to change to something else, or at the very least to reorganize the Trello board.

How many members of the dev team are there cranking through issues?

I do all of the editor coding, with Shiu doing art. I also do the runtimes along with Mitch and others. Keeping a small team ensures Spine's quality is high and I I hope this shows. The team may be growing slightly soon. A small team doesn't necessarily mean that updates are slow, as shown by the changelog archive linked above. It does mean that support tends to suffer, though I doubt most experienced game development teams require much support. To help us manage support we funnel questions to this forum, which is archived and searchable so answers can help those in the future. We do offer a paid support option if guaranteed response times are required.

Is there any availability for a source license of the editor?

This isn't something we have done or have plans for. The source is our entire business and distributing it, even under license, puts us at huge risk. We do offer a source code escrow option, which would provide the source in the event that we go bankrupt or no longer exist. In that case you would be limited to using the source only for your own use.

newbacknew wrote

The problem is that supposedly Spine v3 already has more than a year and no one here really knows the future features of Spine v3.

It has been almost 7 months, not a year, though still a long time. v3 features are not a surprise.

Thanks again for the responses!

Pharan wrote

Oh, so you're about to scale up your studio and will need to invest time in like... R&D stuff for everything? So you have to decide if Spine is the right tool to use. Sounds fair.

Yup, that's exactly right 🙂

Nate wrote

Sorry you didn't get a response. I don't see any messages from your email address?

Ah, I probably sent the request via my work email address and created the forum account on my personal. I'll send another request after posting this in case there's anything to take offline to continue the conversation.

Appreciate the links to the update history - that definitely helps me understand a little bit better the plan on record and history of releases. I totally understand cranking on something for years, especially a small team. Burnout is totally real, especially when you have a live userbase of developers using your toolset. I genuinely hope it's not causing you guys too much stress. Even labors of love take a toll.

Nate wrote

There is Trello, though I'm not super happy with it. It tends to be a jumbled mess, especially with so many "ideas" and features that we want to implement, but not in the near future. We plan to change to something else, or at the very least to reorganize the Trello board.

Yeah, we've used Trello in the past, although in general I've found Pivotal Tracker (https://www.pivotaltracker.com/) and Asana (http://asana.com/) to be better, more comfortable fits. Trello has some clean visual simplicity, but I tend to like Pivotal Tracker for teams that are on active sprint development (when you near burn down charts to reaching milestones) and Asana to be excellent when you want to break work into projects and just maintain a priority list (a bit more minimal, but functional). Just some suggestions to look into if you're interested.

Nate wrote

I do all of the editor coding, with Shiu doing art. I also do the runtimes along with Mitch and others. Keeping a small team ensures Spine's quality is high and I I hope this shows.

Totally get it, and I would do the same thing in your shoes. 🙂 I definitely believe in small, focused teams. My main question was making sure to have confidence in the long term of Spine and updates for external changes (like a new engine update and requiring runtime updates, etc) and improved workflow.

Nate wrote

This isn't something we have done or have plans for. The source is our entire business and distributing it, even under license, puts us at huge risk. We do offer a source code escrow option, which would provide the source in the event that we go bankrupt or no longer exist. In that case you would be limited to using the source only for your own use.

I totally get it, I really do. I understand the reluctance, and similarly, I need to make sure to keep my business safe as well and clearly understand what my engineers can do to augment our artist's pipeline, especially with some features that we know we need and that we could write effectively (it's possible lots of these are supported in 3.0). Any external dependency where we don't have the ability to fix the issues / needs that come up for our team introduces a large risk for us too. :/

There are lots of very successful companies, big and small, that license their source code to other companies safely, especially game engines (Valve's Source, Unreal, Unity, Crytek, Cocos2D, etc). It's definitely something we value very highly and is often a deciding factor for using external tech. I won't push you to do something you don't want to do, but would urge you to consider it. 🙂

That all in mind - is there any expected timeline for the 3.0 release? In the case that we need to wait for that to really evaluate whether a closed source version of Spine is a good fit, it would be helpful to get an idea of when that's coming. 🙂

Again, appreciate the responses all! 🙂

I think it's important for users to have the runtimes' source. Having the editor source is a bit like having the source for Photoshop. It's extremely complex and wouldn't be easy for others to work on.

I would say v3 should be ready within weeks, not months.

I hear you and respect your take. That being said, paying for Photoshop also comes with guaranteed official corporate support and a massive development team, so hopefully you understand why it feels quite different to us (especially while some of the features we'd like to add to our pipeline aren't prioritized right now). It's always complex working in a live codebase, but it's something that would unblock us.

If you're firm on your stance there (which is sounds like you are), we may just have to wait until v3 comes out and look at other tools / roll our own solution if it doesn't have the features we need.

Appreciate the replies. Cheers.

Good luck!

Guaranteed official support doesn't help if Photoshop is lacking a feature you need. Try asking Adobe for a specific feature or even a bug fix and see how long it takes. 😉 The benefit of our small team is that we are much more agile and responsive.

Even if we were open to a source license, I don't think you really want to be working on the editor. The runtime source is open, which can facilitate development of many needs.

For the specific feature you mentioned, changing the texture used by a mesh so the mesh structure and FFD continues to be used, you could do this via the runtimes. Briefly, setup your mesh in Spine with a single texture. At runtime, get the MeshAttachment and adjust the UVs to point to a different region and optionally change the texture it uses. Lacking editor support to key this switch this makes it more difficult to key in animations. Events could be used to key the texture switches, though this would still lack visualization in the editor..

We don't have to get into a debate about it, but I humbly disagree. 🙂

The difference is that Adobe has a massive dev team working closely with the huge audience that uses it, so the amount of new features and improvement is at a pace that's in a different world than what a team of one or two can accomplish. So the chances that a feature that's needed by the community is much higher. 😉

Like I said, I hear you that working in another person's live source code is hard, but we're an experienced team that's worked on and contributed back to many different game engines and tools that have source licenses. We know it's hard - it's absolutely a pain to build inside of someone else's codebase, but increasing an artist's workflow by 5% or even 1% over the lifecycle of the product / company is totally worth it. We disagree on that value, and that's ok. 🙂 Just a bummer for us that your opinion that we wouldn't want to be working on the editor prevents us from working to add that value to our team and to Spine.

Thanks for the suggestion for a hacked solution for the runtime - it's the approach we were planning on taking if we end up landing on Spine. It is very hacked on and doesn't give the artist the ability to iterate on their work in the editor (as you mentioned). Honestly it makes me just want to build another layer inside of Unity that does and visualizes that work, forcing the artist into a clunky workflow if they want to see their work, and decreases their ability to be awesome. That sucks. 🙂

Looking forward to v3 and will be looking into alternatives in the meantime. Thanks for the help.

Adobe certainly has a lot of manpower, but they won't fix your bugs and release an update the same day it was reported or even write down your feature requests. 🙂

The main reason we don't license the source is the risk it puts on our business. This is separate from my opinion that getting involved with setting up and forking a complex tool is not usually necessary.

It depends on your use case as to how much of a hack it is. The various textures need to be very similar to be applied to the same mesh, so all that is involved is a visual check for replacement textures. It's not uncommon to have a tool for previewing skeleton configurations and associating/editing game data. This could allow artists to preview their mesh texture swapping, hot reload images, etc. The skeleton viewer tool is nearly what you'd want for this and it's only 150 LOC (without UI).

There is a similar situation which is common, where an app has hundreds or thousands of images per slot. It doesn't make sense to do the work of attaching them all in Spine just to preview that the art is correct. It's much more efficient to setup only a single image per slot, like a template, then programmatically replace the attachments with the actual images needed. In this case you'd also want a tool artists can use for previewing.

Best of luck figuring out how you will be building you game! If you have any more questions or concerns about how Spine might work for you, feel free to ask them here.

Nate wrote

Adobe certainly has a lot of manpower, but they won't fix your bugs and release an update the same day it was reported or even write down your feature requests. 🙂

Not guaranteed, but a heck of a lot more manpower than a two man team. This is also why I firmly believe in source licensing. We can do the work ourselves if it's not in the pipe. 😉

Nate wrote

The main reason we don't license the source is the risk it puts on our business. This is separate from my opinion that getting involved with setting up and forking a complex tool is not usually necessary.

We disagree based on our past experiences, but that's cool. 🙂

nozomiyume, you are a pain the ass. It is wrong to criticize the way you want to take your intellectual property.. is not your problem. Also you dont have obligation to buy the software.. seriously... go somewhere else

Sorry you feel that way newbacknew.

All the best.

newbacknew, you are free to disagree with others but please keep it civil.

6 أيام لاحقا

I actually thought he was just fine. Disagreeing with an assessment is nothing at all like being a pain in the ass. The entire discourse between Nate and homeboy went smoothly enough to me.

I would like to pitch in. Not that the previous support was bad at all, but from our view (myself and the boss man here) spine 3.0 has been a massive pain in the ass in terms of the 'official support'. It isn't just the massive down time that is the issue, although it was/is (things seem to be picking up on the forum), the problem, for us at least, was the lack of patches. Spine 3.0 has caused a lot of (critical) bug fixes to be locked behind a v3.0 wall. And because the update has taken/is taking so long this is highly frustrating.

In my opinion bug fixes should have been done on another branch of the repo, so they could be released without having to wait for 3.0. It is annoying to work with the editor which currently has many frustrating bugs (now fixed in 3.0), but what's worse is we are coming to the end of a project, and wont be updating to spine 3.0 to get the bug fixes. (unless of course there is an 'use old ik and scale' tick box, so projects work exactly the same)

I hope the support returns to its previous glory.

🙂