Dragonbones support?

[Rayek]

Just wondering if anyone knows when Dragonbones will be supported? This quality c++ animation runtime and its MIT license makes it simple to port, and is already adopted by Unity, Godot 2.1 and 3, RPG maker MV, Cocos creator, Pixi, Egret, Flash, and support is underway for Visionaire and Gdevelop.

Dragonbones is becoming more and more popular for 2d cut-out game character animation, and no wonder: it's free, has 2d mesh deformation, and the animation editor is much more advanced than Spriter - coming close to Spine (which is quite expensive). And we'd be supporting an open format, rather than a proprietary one (Spine).

C++ runtime:
https://github.com/DragonBones/DragonBonesCPP

 

[JeffJ]

Shouldn't we have actual, proper, full, not lacking in the most basic functionality Spine support first?

When we can't even have full support for one suite, I find it seriously optimistic to even consider a second.

 

[Rayek]

Well, it seems that DragonBones' runtime is complete and relatively simple to port. And Spine is not very accessible to many GameMaker users - it's expensive. The basic edition is too limited for semi-serious animation: no meshes, no free-form deformation, no IK constraints, no weighted meshes, ... All of which are supported by the free(!) Dragonbones.

And an open MIT license instead of Spine's closed proprietary license - which doesn't even allow anyone using Spine animations without a Spine license.

I know which one I'd prefer as an indy game maker.

 

[JeffJ]

No one's arguing that. Personally I wouldn't really care that much whether YoYo supported Spine, Dragonbones or another skeletal animation suite, or all of them - as long as they just do it properly and fully. As we have seen with Spine, several years after being officially introduced, we're still missing some of the most basic functions that have been requested pretty much since day one. That is why I find it really unrealistic to hope for multiple suites to be supported, when one is already too much.

EDIT
To be clear, I am not even talking about the runtimes not being up to date. Hell no, that would be a luxury. I'm talking about basic functionality with requests dating back as far as at least 2015.

https://forum.yoyogames.com/index.php?threads/spine-setting-custom-slot-color-through-code.37802

 

[the_dude_abides]

I vaguely recall someone doing a DLL for using Dragonbones, though what stage it ever got to I dunno. It would have been some time ago, back in the days of the old forum, which is what? several months? a year? Whether it got to the stage where it included more recent features is debatable.

You'd have to go through the old archives to find it, but I think all that kind of stuff was preserved after the move. Unless GMS 2 doesn't support DLL's anymore, or some of the functionality is incompatible, then it could still be used? I'm fairly sure it was compatible with GMS 1 versions. But as I said - how finished it ever got, and how up to date, is unclear.

EDIT: All the legacy stuff is found at the bottom of the front page of the community. But it'll probably take some doing to find it in there

 

[JeffJ]

Also, this might be of interest to you:

 

[the_dude_abides]

I just remembered the problem here: it's possible to import Dragonbones to GMS, but since its doing so in the Spine format you still need a Spine license. So, I guess the OP's post is really asking why they chose to support only the one (paid for) format..??

At the time of GMS 1 introduction it was the most developed available, but it did cost even then. Dragonbones was a fairly new alternative, which may be why it wasn't included.

 

[rIKmAN]

Also, this might be of interest to you:

That thumbnail is very misleading as Spine isn't used at all - in fact the dude in the video asks for donations so he can buy a licence at the end which means he doesn't own it himself either.
The video basically shows you how to edit DragonBones json files so that they load into GMS without the need to use Spine at all.

GMS uses the official "Spine Runtimes" to render those json files into animations, and it's irrelevant where or how the json files were made, the licence requirement is quite specific in that you need a licence if you use the "official" runtimes to render them, so the video is actually showing you how to break the EULA.

It's akin to a tutorial video showing how to get around having to buy a GMS2 licence to use it and make and export games, and then having that video in the tutorials section on the forum for everyone to take advantage of.

How long before YYG go out of business and we're all up street?
Same thing for Spine.

I just remembered the problem here: it's possible to import Dragonbones to GMS, but since its doing so in the Spine format you still need a Spine license. So, I guess the OP's post is really asking why they chose to support only the one (paid for) format..??

At the time of GMS 1 introduction it was the most developed available, but it did cost even then. Dragonbones was a fairly new alternative, which may be why it wasn't included.

As I said above, it's not the "format" that is the issue - they are just .json files.
The issue is that GMS uses the official runtimes to render them in-engine and this is why a licence is required.

If someone wrote an extension that rendered the json files within GMS without using any of the code from the official runtimes then you could use that without needing a Spine licence. This is what Defold did - wrote their own runtimes.

I own Spine and have used DragonBones, and honestly I can say that Spine is better in every way.
Yes it costs, but as with anything you get what you pay for - much better UI, more features, quick, extensive runtime support and upkeep (they update them for many engines and languages - one of which could have been GMS but YYG shot it down when Esoteric offered to help implement an "official" runtime), and the support is top quality with replies usually within a few hours.

My personal experience with DragonBones has been pretty poor - lots of info / documentation was only in Chinese to start with or broken hard to understand English, having to sign up to dodgy looking accounts to login to it, and weeks to return an email from their support.
Turns out the DB team is only 2-3 guys doing it in their spare time and updates / fixes will come "as and when with no schedule" (their words in the reply email not mine).

There is nothing to stop you using DragonBones to render out .png images and use those within GMS, although you lose the flexibility of skeletal animation that way of course, but unless you are working on a game which you are looking to be published then tghe Essentials version would be fine - and the cost is deducted if you upgrade to Pro.
I don't understand the "I want everything for nothing" attitude that some people have in regards to the cost of things which you want to use to make your game, and presumably make money off.

To quote OP: "The basic edition is too limited for semi-serious animation".
Well if you are "semi-serious" then I don't see why having a "semi-serious" attitude and saving the money to purchase some "semi-serious" tools would be a problem?

If you want a new car do you go to a dealership and moan to the manager that all the cheaper cars aren't good enough because you want the top of the line model but can't afford it? No, you either get what you can afford and save towards the one you want, or don't get anything and continue to save until you can.
That's life.

It may seem like I'm a Spine fanboy here (and I am, it's an awesome tool) but I should also say that the GMS support of the runtimes is very poor.
Apart from the fact that there are basic features of the runtimes not wrapped for use as JeffJ says, you won't be able to (reliably) use a version past v3.4.02 which means all those shiny new features you see on the Spine website (Clipping, Weight Painting, Tint Black etc) you won't be able to use anyway.
Not to mention all the improvements and bugfixes to Spine itself (UI, layout etc) - we don't get those either.

I'm not 100% sure I'd even recommend anyone buy the Pro version just for using with GMS.
I've had the advantage of using Spine in other engines outside of GMS, so I'm a little more appreciative of what it can do than someone who has only experienced it's very limited support within GMS and the handful of functions it offers to interact with skeletons.

Also I agree with @JeffJ with the fact that if YYG can't / won't keep Spine upto date and that is what's used as a big feature of GMS on the website etc, then I don't see them being able to double the workload and also implement DragonBones support to an acceptable level either on top of that.

From what's been said by YYG staff on the forums previously they are actually looking to decouple Spine from GMS and make it into an extension, which means they won't support it and it will probably become a community effort of some sort, so I wouldn't really expect an updates to what it currently is either, meaning an "official" DragnBones integration is very very unlikely too.

Maybe Esoteric could then do an official extension, but that depends on how many people actually use Spine and GMS together, and from all the posts I see on here moaning about it's price and talking to other people it seems there are probably less than 10 of us.

Maybe more that don't use forums / reddit etc, but almost certainly not a number big enough to bother putting in the work to make / upkeep an "official" runtime - if YYG don't think it's high enough priority to bother with when it's their engine that is using Spine as a feature to sell it, then the numbers can't be big enough to make it worthwhile for them.

I haven't checked recently either, but does DragonBones have runtimes for all targets that GMS supports?
Last time I checked there were only 3 I think.

Maybe you could contact one of the GMS extension writers with a view to writing an extension for you to support DB, but that would of course cost you as well, so whichever way you look at it there is going to be some cost somewhere along the way.

Apologies for the wall of text, I get carried away as I'm quite passionate in the belief that fully-featured "proper" support for Spine would make it much more attractive as an engine for a wider range of people and benefit everyone in the long term, as opposed to the half-assed "you can render a skeleton, what more do you need?" implementation we have now which isn't appealing to anyone.

At least I formatted the post, so there's that!

 

[JeffJ]

Wall of text

Just FYI - I completely agree with everything you said on a principle level, and I personally backed Spine when it was on Kickstarter - that's where I have my pro licences from. Even back then I did it just for GameMaker, even though there was absolutely no guarantee back then that it would even be supported. But it did, and even with the ty GM support, it was more than worth the investment. I also believe Spine is much better than anything out there - like you said - you get what you pay for.

That being said, I can understand why someone might want to go another route. Especially when the runtime support is as lackluster as it is.

 

[rIKmAN]

Just FYI - I completely agree with everything you said on a principle level, and I personally backed Spine when it was on Kickstarter - that's where I have my pro licences from. Even back then I did it just for GameMaker, even though there was absolutely no guarantee back then that it would even be supported. But it did, and even with the ****ty GM support, it was more than worth the investment. I also believe Spine is much better than anything out there - like you said - you get what you pay for.

That being said, I can understand why someone might want to go another route. Especially when the runtime support is as lackluster as it is.

Yeah, I also supported early so got a Pro licence cheaper than it's current price - not quite KS cheap - but it's also been worth it me and I recouped that investment before I ever started using GMS.

When I said I'm not sure I could recommend buying Spine Pro just for use with GMS I was specifically meaning the current full price cost, as you would be stuck using an old version with outdated features and Spine IDE. Just look at the amount of posts on here where people say it isn't working because they have just gone and downloaded the latest version of Spine expecting it to work.

If you are able to use it in another engine or language as well it is 100% worth every penny as you are able to use the latest versions with all the bells and whistles and interact with your creations via code on a much more in depth level than GMS can only currently dream of.
GMS is still dreaming of being able to colour a slot at runtime using functions already built into the official runtimes, but not wrapped for use in GMS for whatever reason.

If you wanted the use of FFD and IK etc for exporting sprites you would be better off using DragonBones as it's free and there are no licencing issues with exporting sprites, but that isn't going to work for all kinds of games as you lose the runtime features.

Of course I can understand people wanting alternatives, but like you said the "official" Spine support is so poor in GMS so why would DragonBones support would be any better?
It's the same thing with the vector support - yes GMS loads and renders them, but they come with so many limitations and caveats that it makes it hardly worth bothering with without careful planning and designing your game around those restrictions beforehand.

I also disagree with the way in which pretty blatant breaking / skirting of the EULA is published as a tutorial on the forum, but that's just me.
I'm sure if someone uploaded a video showing how to use GMS2 without needing a licence that it would be stomped on pretty quickly, and it's much the same thing.

I guess the only difference is that people can't seem to get their head around that it's the usage of the runtimes that the licence is required for.
It's doesn't matter where or how the files were created, it's how they are being played back in-engine.

 

[andev]

To quote OP: "The basic edition is too limited for semi-serious animation".
Well if you are "semi-serious" then I don't see why having a "semi-serious" attitude and saving the money to purchase some "semi-serious" tools would be a problem?

I agree with everything you said except this. Not everyone with professional level skill has access to money, and especially not the premiums that spine charges. It costs more than twice as much as the full version of GM2.

If you want a new car do you go to a dealership and moan to the manager that all the cheaper cars aren't good enough because you want the top of the line model but can't afford it?

This example would only apply if the only car you could buy was a tesla, and there were other cheaper cars but it was illegal to drive them on the road.

 

[Rayek]

Agreed, not everyone has the financial means to invest in Spine - but aside from this the implementation in GM is half-baked. I can afford Spine - but why would I if it isn't properly supported in GM? The reason I asked about Dragonbones is simple: it seems to be easily integrated, and the runtime is MIT licensed. I've animated several character with it, and it works quite nicely - much better than Spriter, for example. If Dragonbones hadn't been free, I'd still consider using it.

Personally, I feel it's a bit painful that the primary competitors of GM offer BOTH good built-in animation timelines (against no extra cost) AND also support a number of alternate cut-out IK animation apps and workflows that exist - both commercial and free. In this, GM is trailing the bandwagon by several miles, and losing more ground with each day passing.

Exporting all your frames to PNG is a work-around solution that might work for some situations, but misses the point of why we would use Spine or Dragonbones in the first place - to integrate a more efficient and flexible animation workflow. (And GM frustratingly enough doesn't support WebP either, which would lower animation file storage requirements drastically :-( )

@rIKmAN, reading your answers I am beginning to understand that the GM developers have no real interest in providing good Spine support, let alone alternatives such as Dragonbones. If that is indeed the case (and it seems to be, based on your own experience with Yoyo), I'll just have to look elsewhere.

It's a bit disheartening, however.

 

[rIKmAN]

I agree with everything you said except this. Not everyone with professional level skill has access to money, and especially not the premiums that spine charges. It costs more than twice as much as the full version of GM2.

The Essentials versions of Spine costs $69 and this gives you a valid licence to use the runtimes, as well as being deductable from the cost of Pro should you ever upgrade, and while FFD and IK are nice - are they showstoppers to someone making a game?
I'd say no, and that proceeds from a game using Essentials and sold via Steam / Itch.io etc could go towards funding the full Pro licence.

It's like people complaining that GMS2 "costs $1500" like they have to have all the exports including console from day one or else it's not worth bothering with. They don't even take into account the extra costs associated on top of the price of GMS: other software, Android / iOS phones, tablets, Macs, dev licences etc etc, they just think that unless they are able to export to every device available then it's not worth it, and voice their incredulity at the $1500 price tag - it's just silly.

You could get GMS + Spine Essentials for ~$170 (~$120 if you get Creators for $39 and then save for 12mth towards Desktop) and get on with making a game that you could make that money back off of easily if you are "semi-serious", or you can get neither and look elsewhere for an engine with better support for workflows that fit your needs and are free. Pick your poison.

This example would only apply if the only car you could buy was a tesla, and there were other cheaper cars but it was illegal to drive them on the road.

Yeah, it was more a generalisation of the "I want everything for nothing / peanuts" attitudes of people - not directed at OP (sorry if it came across like that OP).

It seems more prevalent in the GMS community than any other place I've been - maybe because it attracts a younger userbase who grew up in the free / freemium / f2p boom and have become accustomed to getting things for free or $0.99.

I'm not sure if they realise that the people that make the tools they want to use need income, and if they don't get it those companies go bust and things stop being updated, and they are left with nothing.

I can afford Spine - but why would I if it isn't properly supported in GM?

It may be worth it, that comment of mine is very subjective.

Take a look at the Spine release notes and check the features that came after v3.4.02 and see if there are any which you would require - if not then it may be worth it for you personally. FFD and IK does work in GMS, but anything after that version isn't reliably supported so it's best to stay clear.

Personally, I feel it's a bit painful that the primary competitors of GM offer BOTH good built-in animation timelines (against no extra cost) AND also support a number of alternate cut-out IK animation apps and workflows that exist - both commercial and free. In this, GM is trailing the bandwagon by several miles, and losing more ground with each day passing.

Yeah, it is very frustrating - once the discussion got to the point of Esoteric offering to help implement a runtime and it was turned down I realised I was flogging a dead horse and gave up trying to get anything to happen.

As I said earlier though, I don't know the numbers but it seems Spine + GMS users are few and far between, so I can see why it would be low priority for YYG, but on the other hand it's a self fulfilling prophecy: poor support in GMS = nobody uses it, nobody uses it = poor support / low priority update status. Catch 22.

@rIKmAN, reading your answers I am beginning to understand that the GM developers have no real interest in providing good Spine support, let alone alternatives such as Dragonbones. If that is indeed the case (and it seems to be, based on your own experience with Yoyo), I'll just have to look elsewhere.

It's a bit disheartening, however.

As I said, check out the Spine feature list and see if anything after v3.4.02 is crucial to what you had planned - if not it may be worth it for you.

Also keep in mind that if / when YYG ever do decouple Spine into an extension that it may very well be updated to support the latest version of Spine (probably as a paid asset on the MP by someone or a community effort of some sort) and also that you can use any of the other supported engines if that may be an option in future - it's not just limited to use with GMS.

I don't regret buying it and neither does Jeff - who bought it specifically for use with GMS - but it's a decision only you can make based on your specific needs for your game and whether v3.4.02 can fulfill them.

 

[maru_th_undrtkr]

I doubt its because its too hard. Its probably a deal they have with spine. It would be nice, but I get if their hands are tied on that.

 

[andev]

I doubt its because its too hard. Its probably a deal they have with spine. It would be nice, but I get if their hands are tied on that.

I think it's more likely to be that the current implementation works just fine, so it's safe to leave it on the back burner and get fixing the game breaking stuff.

 

[Rayek]

Thanks, @rIKmAN
The reason for my original question is that my next game project must accommodate heaps of 2d character animations, and cut-out 2d IK-based ones are the best solution - it allows me to re-use the same rigs and animations for various characters. Ideally animation mixing should be supported, and a built-in timeline in the game dev environment would probably save me loads of time. Game Maker still doesn't feature or support a built-in timeline, so I might have to look elsewhere anyway.

I will do some testing over the weekend.

 

[GMWolf]

I have seen some speak of converting dragonbones files to spine files so that they can be imported in GM.
I don't know if it has been mentioned already (tl;Dr), but that's not really legal.

The spine runtime license doesn't come with Gamemaker, but with the spine editor.

 

[MadPropz101]

No one's arguing that. Personally I wouldn't really care that much whether YoYo supported Spine, Dragonbones or another skeletal animation suite, or all of them - as long as they just do it properly and fully. As we have seen with Spine, several years after being officially introduced, we're still missing some of the most basic functions that have been requested pretty much since day one. That is why I find it really unrealistic to hope for multiple suites to be supported, when one is already too much.

EDIT
To be clear, I am not even talking about the runtimes not being up to date. Hell no, that would be a luxury. I'm talking about basic functionality with requests dating back as far as at least 2015.

https://forum.yoyogames.com/index.php?threads/spine-setting-custom-slot-color-through-code.37802

That thumbnail is very misleading as Spine isn't used at all - in fact the dude in the video asks for donations so he can buy a licence at the end which means he doesn't own it himself either.
The video basically shows you how to edit DragonBones json files so that they load into GMS without the need to use Spine at all.

GMS uses the official "Spine Runtimes" to render those json files into animations, and it's irrelevant where or how the json files were made, the licence requirement is quite specific in that you need a licence if you use the "official" runtimes to render them, so the video is actually showing you how to break the EULA.

It's akin to a tutorial video showing how to get around having to buy a GMS2 licence to use it and make and export games, and then having that video in the tutorials section on the forum for everyone to take advantage of.

How long before YYG go out of business and we're all up **** street?
Same thing for Spine.


As I said above, it's not the "format" that is the issue - they are just .json files.
The issue is that GMS uses the official runtimes to render them in-engine and this is why a licence is required.

If someone wrote an extension that rendered the json files within GMS without using any of the code from the official runtimes then you could use that without needing a Spine licence. This is what Defold did - wrote their own runtimes.

I own Spine and have used DragonBones, and honestly I can say that Spine is better in every way.
Yes it costs, but as with anything you get what you pay for - much better UI, more features, quick, extensive runtime support and upkeep (they update them for many engines and languages - one of which could have been GMS but YYG shot it down when Esoteric offered to help implement an "official" runtime), and the support is top quality with replies usually within a few hours.

My personal experience with DragonBones has been pretty poor - lots of info / documentation was only in Chinese to start with or broken hard to understand English, having to sign up to dodgy looking accounts to login to it, and weeks to return an email from their support.
Turns out the DB team is only 2-3 guys doing it in their spare time and updates / fixes will come "as and when with no schedule" (their words in the reply email not mine).

There is nothing to stop you using DragonBones to render out .png images and use those within GMS, although you lose the flexibility of skeletal animation that way of course, but unless you are working on a game which you are looking to be published then tghe Essentials version would be fine - and the cost is deducted if you upgrade to Pro.
I don't understand the "I want everything for nothing" attitude that some people have in regards to the cost of things which you want to use to make your game, and presumably make money off.

To quote OP: "The basic edition is too limited for semi-serious animation".
Well if you are "semi-serious" then I don't see why having a "semi-serious" attitude and saving the money to purchase some "semi-serious" tools would be a problem?

If you want a new car do you go to a dealership and moan to the manager that all the cheaper cars aren't good enough because you want the top of the line model but can't afford it? No, you either get what you can afford and save towards the one you want, or don't get anything and continue to save until you can.
That's life.

It may seem like I'm a Spine fanboy here (and I am, it's an awesome tool) but I should also say that the GMS support of the runtimes is very poor.
Apart from the fact that there are basic features of the runtimes not wrapped for use as JeffJ says, you won't be able to (reliably) use a version past v3.4.02 which means all those shiny new features you see on the Spine website (Clipping, Weight Painting, Tint Black etc) you won't be able to use anyway.
Not to mention all the improvements and bugfixes to Spine itself (UI, layout etc) - we don't get those either.

I'm not 100% sure I'd even recommend anyone buy the Pro version just for using with GMS.
I've had the advantage of using Spine in other engines outside of GMS, so I'm a little more appreciative of what it can do than someone who has only experienced it's very limited support within GMS and the handful of functions it offers to interact with skeletons.

Also I agree with @JeffJ with the fact that if YYG can't / won't keep Spine upto date and that is what's used as a big feature of GMS on the website etc, then I don't see them being able to double the workload and also implement DragonBones support to an acceptable level either on top of that.

From what's been said by YYG staff on the forums previously they are actually looking to decouple Spine from GMS and make it into an extension, which means they won't support it and it will probably become a community effort of some sort, so I wouldn't really expect an updates to what it currently is either, meaning an "official" DragnBones integration is very very unlikely too.

Maybe Esoteric could then do an official extension, but that depends on how many people actually use Spine and GMS together, and from all the posts I see on here moaning about it's price and talking to other people it seems there are probably less than 10 of us.

Maybe more that don't use forums / reddit etc, but almost certainly not a number big enough to bother putting in the work to make / upkeep an "official" runtime - if YYG don't think it's high enough priority to bother with when it's their engine that is using Spine as a feature to sell it, then the numbers can't be big enough to make it worthwhile for them.

I haven't checked recently either, but does DragonBones have runtimes for all targets that GMS supports?
Last time I checked there were only 3 I think.

Maybe you could contact one of the GMS extension writers with a view to writing an extension for you to support DB, but that would of course cost you as well, so whichever way you look at it there is going to be some cost somewhere along the way.

Apologies for the wall of text, I get carried away as I'm quite passionate in the belief that fully-featured "proper" support for Spine would make it much more attractive as an engine for a wider range of people and benefit everyone in the long term, as opposed to the half-assed "you can render a skeleton, what more do you need?" implementation we have now which isn't appealing to anyone.

At least I formatted the post, so there's that!

I can't express how sad this makes me, my friends and i are making a game and we were all so excited to use Spine, and even willing to cash out for the Pro version even though believe it or not it's a lot of money for us. I can't believe the last Spine version that GMS 2 supports came out in august of 2016? Has the support been totally abandoned?
The Essentials version seems like a mockery tbh, all of the coolest features from the Professional version are missing, so from what i understand Gamemaker basically doesn't some of the best features?
From what i understood IK is basically dynamic reactions to other objects/collisions, does that work? Also, do meshes, path and transform constraints, and skins work? Can you target specific bones and for example make the character look towards the mouse, or a certain object, or bend his body down and look up when you wanna shoot up?
What would happen if you tried using the newest version of Spine with GMS 2, it simply wouldn't work at all?

 

[rIKmAN]

I can't express how sad this makes me, my friends and i are making a game and we were all so excited to use Spine, and even willing to cash out for the Pro version even though believe it or not it's a lot of money for us. I can't believe the last Spine version that GMS 2 supports came out in august of 2016? Has the support been totally abandoned?
The Essentials version seems like a mockery tbh, all of the coolest features from the Professional version are missing, so from what i understand Gamemaker basically doesn't some of the best features?
From what i understood IK is basically dynamic reactions to other objects/collisions, does that work? Also, do meshes, path and transform constraints, and skins work?
What would happen if you tried using the newest version of Spine with GMS 2, it simply wouldn't work at all?

It hasn't been abandoned, but there aren't many GMS users who use Spine it would seem and although YYG have been fixing bugs in that time - this makes it low priority in terms of keeping the runtime updated.
Whilst annoying for those of us who use Spine, this is understandable - although I still would have hoped we would have had a runtime update within an 18mth period from the last one.

In terms of features - as far as I am aware every feature in Spine upto v3.4.02 works, that includes meshes, IK, paths, transform constraints and skins.
That is to say the Spine example files that use these features all run fine in GMS2 from my testing and they playback exactly as they do in the Spine editor without issue.

Newer features such as Clipping, Tint Black, Weight Painting etc aren't supported in GMS and trying to load files exported from later versions that use these features (in Spine) will fail to load into GMS as it uses an older runtime that doesn't support those features (v3.4.02).

There are also some rules to follow when using Spine with GMS - mainly not using the "Shear" key as it isn't supported and making sure every single bone has R/T/S keys set at the start and end of every animations otherwise weird things can happen. There are also some other quirks that can be a little puzzling until you know what they are and then they aren't really an issue - most of which I've posted about on the forum (or others have) so you could use the search and have a look through the results.
You also can't currently manipulate slots at runtime using code (change colour / alpha) , but I'm hoping to fix that shortly.

As I said previously if you can make your game with v3.4.02 and don't need / can workaround any of the newer features then go for it - I've never said it doesn't work.
It's just that I've used Spine in other engines with newer runtimes and when compared to those the GMS support isn't great - that isn't going to stop you from making animations and loading them into your game though.

I've spoken to people who have only ever used Spine with GMS and love it because they've never used it with another engine - if that's you then you might love it too.
Basically don't let my moaning put you off using Spine - it "works" in GMS, but it could be so much better and that's why I get so frustrated.

Also take a look through the Skeletal Animation section of the manual so you can see what functions are available for you to interact with Spine sprites, it should help you work out whether you will be able to do what you are planning with your game.

 

[MadPropz101]

It hasn't been abandoned, but there aren't many GMS users who use Spine it would seem and although YYG have been fixing bugs in that time - this makes it low priority in terms of keeping the runtime updated.
Whilst annoying for those of us who use Spine, this is understandable - although I still would have hoped we would have had a runtime update within an 18mth period from the last one.

In terms of features - as far as I am aware every feature in Spine upto v3.4.02 works, that includes meshes, IK, paths, transform constraints and skins.
That is to say the Spine example files that use these features all run fine in GMS2 from my testing and they playback exactly as they do in the Spine editor without issue.

Newer features such as Clipping, Tint Black, Weight Painting etc aren't supported in GMS and trying to load files exported from later versions that use these features (in Spine) will fail to load into GMS as it uses an older runtime that doesn't support those features (v3.4.02).

There are also some rules to follow when using Spine with GMS - mainly not using the "Shear" key as it isn't supported and making sure every single bone has R/T/S keys set at the start and end of every animations otherwise weird things can happen. There are also some other quirks that can be a little puzzling until you know what they are and then they aren't really an issue - most of which I've posted about on the forum (or others have) so you could use the search and have a look through the results.
You also can't currently manipulate slots at runtime using code (change colour / alpha) , but I'm hoping to fix that shortly.

As I said previously if you can make your game with v3.4.02 and don't need / can workaround any of the newer features then go for it - I've never said it doesn't work.
It's just that I've used Spine in other engines with newer runtimes and when compared to those the GMS support isn't great - that isn't going to stop you from making animations and loading them into your game though.

I've spoken to people who have only ever used Spine with GMS and love it because they've never used it with another engine - if that's you then you might love it too.
Basically don't let my moaning put you off using Spine - it "works" in GMS, but it could be so much better and that's why I get so frustrated.

Also take a look through the Skeletal Animation section of the manual so you can see what functions are available for you to interact with Spine sprites, it should help you work out whether you will be able to do what you are planning with your game.

Thanks a lot for the reply. I'm sorry if i didn't understand this right, but if you use the newest version of Spine (for the benefits of improved UI and Performance) to create your animation but don't use any of the stuff that isn't supported by GMS 2 (Clipping, Tint Black and Weight Painting), shouldn't the exported file still work in GMS 2?
I also looked at the Skeletal Animation manual that you gave me, i'm assuming that if you wanted to let's say make the character look at something like the mouse cursor you would use the "skeleton_bone_data_set" function?

And yeah even though there are plenty of features that work with GMS 2 it kinda worries me that there was no runtime update for such a long time, i really want to invest into Spine Professional but i'm worried that it might suddenly stop working.

 

[rIKmAN]

Thanks a lot for the reply. I'm sorry if i didn't understand this right, but if you use the newest version of Spine (for the benefits of improved UI and Performance) to create your animation but don't use any of the stuff that isn't supported by GMS 2 (Clipping, Tint Black and Weight Painting), shouldn't the exported file still work in GMS 2?
I also looked at the Skeletal Animation manual that you gave me, i'm assuming that if you wanted to let's say make the character look at something like the mouse cursor you would use the "skeleton_bone_data_set" function?

And yeah even though there are plenty of features that work with GMS 2 it kinda worries me that there was no runtime update for such a long time, i really want to invest into Spine Professional but i'm worried that it might suddenly stop working.

It might work, it might not - it depends what has changed in the json output from Spine.
Sometimes they just add new sections which might be ignored by GMS and so load normally, other times they might change the names of some properties so it will give an error and you have to manually edit the json files to correct any wrong data - this happens less often but I believe they did this with "weightedmesh" changing to something else around v3.3 (if I remember right).

It's fixable - but if you have a lot of Spine sprites you have to do this editing every time you export from Spine - or write a macro or tool to do it for you.

As I say not the end of the world, but no ideal either - you could run some tests with different versions to test out the point it breaks.
The docs say 3.5.x "should" work and 3.6 probably won't, but I stick to v3.4.02 as that is the "supported" version and I don't wanna risk working in a later version in case something goes wrong - you can't load later versions of Spine files into earlier versions so it'd mean a lot of work redoing stuff in 3.4.02.

Yeah you would access the bone data using the skeleton_bone_* functions, that's correct.

Why would you worry about it stopping working?
You can download any version of Spine by using the menu in it to specify the exact version number - and it works in GMS now so just use the right versions of Spine and GMS and it'll always work as it is now.

It's taking a long time to get any better, but it isn't going to get any worse.

 

[MadPropz101]

It might work, it might not - it depends what has changed in the json output from Spine.
Sometimes they just add new sections which might be ignored by GMS and so load normally, other times they might change the names of some properties so it will give an error and you have to manually edit the json files to correct any wrong data - this happens less often but I believe they did this with "weightedmesh" changing to something else around v3.3 (if I remember right).

It's fixable - but if you have a lot of Spine sprites you have to do this editing every time you export from Spine - or write a macro or tool to do it for you.

As I say not the end of the world, but no ideal either - you could run some tests with different versions to test out the point it breaks.
The docs say 3.5.x "should" work and 3.6 probably won't, but I stick to v3.4.02 as that is the "supported" version and I don't wanna risk working in a later version in case something goes wrong - you can't load later versions of Spine files into earlier versions so it'd mean a lot of work redoing stuff in 3.4.02.

Yeah you would access the bone data using the skeleton_bone_* functions, that's correct.

Why would you worry about it stopping working?
You can download any version of Spine by using the menu in it to specify the exact version number - and it works in GMS now so just use the right versions of Spine and GMS and it'll always work as it is now.

It's taking a long time to get any better, but it isn't going to get any worse.

Yeah you’re right, probably better to be safe than sorry, even though it means having to skip put on some “quality of life” improvements .

 

[rIKmAN]

Yeah you’re right, probably better to be safe than sorry, even though it means having to skip put on some “quality of life” improvements .

You could build your "main" skeletons using v3.4.02, then make a copy of the files and load that into v3.5.x or v.3.6.x to test if they work with GMS.

Just remember to ALWAYS keep a backup of those v3.4.02 project files, because as I said once you load them into a later versions of Spine they are no longer compatible with earlier versions and you'll be in for a lot of tedious json editing to try and remove all the extra data to get it back working in 3.4,

Good luck with your game, look forward to seeing what you do - always good to have another Spine user in community as the more of us there are the higher priority updating it might become.

 

[andev]

About 4-6 months ago I was using the latest version of spine to export to game maker without any problems. It supports mesh weights, swapping bone skins for custom ones, and direct bone editing via a map.

 

[MadPropz101]

You could build your "main" skeletons using v3.4.02, then make a copy of the files and load that into v3.5.x or v.3.6.x to test if they work with GMS.

Just remember to ALWAYS keep a backup of those v3.4.02 project files, because as I said once you load them into a later versions of Spine they are no longer compatible with earlier versions and you'll be in for a lot of tedious json editing to try and remove all the extra data to get it back working in 3.4,

Good luck with your game, look forward to seeing what you do - always good to have another Spine user in community as the more of us there are the higher priority updating it might become.

About 4-6 months ago I was using the latest version of spine to export to game maker without any problems. It supports mesh weights, swapping bone skins for custom ones, and direct bone editing via a map.

Just wondering if anyone knows when Dragonbones will be supported? This quality c++ animation runtime and its MIT license makes it simple to port, and is already adopted by Unity, Godot 2.1 and 3, RPG maker MV, Cocos creator, Pixi, Egret, Flash, and support is underway for Visionaire and Gdevelop.

Dragonbones is becoming more and more popular for 2d cut-out game character animation, and no wonder: it's free, has 2d mesh deformation, and the animation editor is much more advanced than Spriter - coming close to Spine (which is quite expensive). And we'd be supporting an open format, rather than a proprietary one (Spine).

C++ runtime:
https://github.com/DragonBones/DragonBonesCPP

OMGG GUYS, I COME BEARING GREAT NEWS:

http://esotericsoftware.com/forum/How-limited-is-the-Spine-support-for-Game-Maker-Studio-2-10006

Hi MadPropz101, the GM developers recently contacted us because they're about to update the runtime to our latest Spine version, so don't worry!
You can do a lot of amazing things with ESS already, and that is fully compatible with GM, and you can always upgrade later for the difference in price if you find out that you want more. Depends on what kind of style you are after!

 

[bbbower]

OMGG GUYS, I COME BEARING GREAT NEWS:

http://esotericsoftware.com/forum/How-limited-is-the-Spine-support-for-Game-Maker-Studio-2-10006

Hurray, I tried to read this whole thread but I then realized it looked like some sort of ethics rant war XD but there was this golden nugget at the end!
I own a spine license, but I like using Dragonbones it's nice to see the contrasts however. I spent more time than I care to admit coding my own animator within gamemaker to allow simple 2d animations with 4 directions (Top Down Adventure Style). I felt both of them lacking in the simple aspects. I simply needed my sprites in 4 directions to have layers (the animations were already in the pngs) (ie. shirt,pants,hair) and it was the most ridiculous process to add every single item to the spine file rather than just being able to swap them with resources imported into the game or even external resources. I searched quite a bit trying to find work arounds but I was basically left with the impression this is for primarily for side scrolling and not much else.

I did watch that "controversial" video however and read some of all your rant walls before my ADHD couldn't handle it anymore. So I did some quick research and just so you know included in the long, many sections of the spine runtimes license is the phrase
"You are granted a perpetual, non-exclusive, non-sublicensable, and
non-transferable license to use, install, execute, and perform the Spine
Runtimes software and derivative works solely for personal or internal
use."
followed by the sentence
"This Spine Runtime may only be used for personal or internal use, typically to evaluate Spine before purchasing."
which indicates that using it the manner described would not be a violation, however when you go to release it or make it publicly available (as also explicitly stated in that video) you would need to purchase the license.
In seeing that, I'm not an overpaid copyright lawyer but I can't see how using Dragonbones export feature and the runtime in gamemaker would be any violation whatsoever until you actually went to release / sell your product.

[edit]
Just to further support the subject if you look through yoyogames terms the spine runtime seems to be specific to owning the pro license to game maker not spine as indicated in the following quotes.
"IMPORTANT: Spine integration in GameMaker: Studio is a Pro licence feature and will not work in the Free/Standard versions."
and even further in
"The functions found in this section are only for use with sprites that have been imported from a skeletal animation file (like the JSON files that Spine exports)"

To me, even as a paid supporter of spine, this indicates the fee to use the runtime is in the license fee for gamemaker but using "spine" exported specific files (even though they are JSON files with the only inherent expressed limitation of such files being comically stated as "shall be used for Good, not Evil") would definitely require the spine license (that would be piracy obviously as you used that program specifically without a licence ).

This further extends the gray area in which the debate started, but still in short I see the only possible problem arising when you make your creation public.
[/edit]

 

[Tom O'Rourke]

Does anyone know if the runtime has been updated since the announcement here: http://esotericsoftware.com/forum/How-limited-is-the-Spine-support-for-Game-Maker-Studio-2-10006 or if there's a timeline?

Many thanks,

- Tom

 

[rIKmAN]

Does anyone know if the runtime has been updated since the announcement here: http://esotericsoftware.com/forum/How-limited-is-the-Spine-support-for-Game-Maker-Studio-2-10006 or if there's a timeline?

Many thanks,

- Tom

No it hasn't, and YYG haven't mentioned anything themselves about it so there is no timeline or official confirmation when or if it's happening.
The only mention they looking at updating the runtime is that post on the Spine forum.

Fingers crossed though, as it was an Esoteric staff member that posted it, so almost certainly correct.

 

[Tom O'Rourke]

Ok fingers crossed, it's interesting as both Spine and Game Studio 2 are both paid for tools (that I've paid for) that purport to work together but in fact there is a huge lag in the support. I'm resisting the 'no brainer' move of just switching to Unity as I'm sure a lot of people do as I really want to commit to a solid made for 2d engine

 

[Rayek]

I really wish Yoyo would just integrate a good animation editor natively, and not depend on external apps for this.
Just saw this news here: https://godotengine.org/article/godot-gets-brand-new-animation-editor-cinematic-support

I've mentioned this before, but once again: would be brilliant if Gamemaker received similar functionality at some point. Can you imagine full bezier spline animation control for any property in Gamemaker? Native cut-out characters?
Cinematic animation controls? All the other major engines have this, and it'd be sort-of expected of Gamemaker as well sometime.

Hopefully the GM devs are aware of this. It certainly would make my life (way!) easier as a game dev involved in narrative game design.

 

[GMWolf]

I really wish Yoyo would just integrate a good animation editor natively, and not depend on external apps for this.
Just saw this news here: https://godotengine.org/article/godot-gets-brand-new-animation-editor-cinematic-support

I've mentioned this before, but once again: would be brilliant if Gamemaker received similar functionality at some point. Can you imagine full bezier spline animation control for any property in Gamemaker? Native cut-out characters?
Cinematic animation controls? All the other major engines have this, and it'd be sort-of expected of Gamemaker as well sometime.

Hopefully the GM devs are aware of this. It certainly would make my life (way!) easier as a game dev involved in narrative game design.

It would indeed be amazing, but not gonna happen anytime soon.
Look at the last couple GM updates. Progress is INCREDIBLY slow! seriously, in the last 6 months we go some slightly fancier UI and object variables.
Yet we still dont have an animation system, we dont have a UI system, the particle system is still very bare-bones, and the list goes on.

 

[Rayek]

@GMWolf I can live without a proper UI and particle system (however, check out Godot again for inspiration), but the lack of an animation timeline is making my particular narrative-type game development much more difficult than it needs to be.

At this point I am considering the move away from GM, but I am staring at that proverbial wall to start learning a new engine. Still, I suppose with my next upcoming project this Summer I'll have to. Bit tired of waiting, and an animation system will cut my development time in half, perhaps even more (I did some simple tests a while ago to guesstimate the impact on my workflow).

Don't want to / can't wait any longer. Difficult situation to be in indeed: don't want to leave GM behind, but my hands are forced somewhat by ever-increasing expectations from my clients and what the competitors are doing. I create serious games for construction and oil industry companies, and the narrative part is obviously very important and essential. The competition has been heating up these past few years, and I need to become more efficient while improving the overall animation parts as well. Spine is not really an efficient solution for my type of work.

While I love GM, the lack of that long-hoped for interactive animate-all timeline is hurting my workflow and end quality now. I am an animator aside from being a developer, and seeing industry-standard animation tools (similar to ones usually only seen in dedicated animation software) now available in engines like Godot and Unity being used more and more, I can't see myself continuing GM after finishing my latest project in a month. A shame, but it is what it is.

 

[Tom O'Rourke]

FYI I just got a response from YoYo Games via Facebook, not support which was a deadend. A Spine update is on the roadmap for the end of the year....

 

[Nocturne]

Guys this is the GAMEMAKER forum and not a forum for **insert-other-engine-here***... So, please don't discuss the merits/pitfalls of other engines.