• Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

Legacy GM Spine (Esoteric Software) and GameMaker intergration

Tim

Member
There has been a bug chillin' in the YoYo Games database for about two years and I am wondering if we might get some traction on it. It is about allowing GameMaker to 'hear' event triggers set into Spine's animation timeline. The bug is here:

http://bugs.yoyogames.com/view.php?id=16582

If this system could be hooked up it would be incredibly useful for nearly anyone using Spine (link to homepage here) and GameMaker and maybe even make a few converts. Read on!

The short of it is you can set snippets of code into Spine's animation time line and have them triggered on specific frames. Examples:
  • You could set a 'gunflash' animation to happen during a particular frame of a gun firing
  • You could trigger footstep sounds when your character's feet hit the ground by entering the trigger the correct frame
  • You could have an object spawn particle or even other objects when it is running a 'destroyed' animation.
  • Generally speaking this is a system to allow syncing and creation to happen via animation triggers in a pretty straightforward manner.
There are a LOT more things possible and with a little creativity this is a very useful system. I've been using Spine and GameMaker for nearly two years for Boss 101 and I love it. We've been hoping to see this feature happen and are watching that bug. Since it doesn't look like it's moving anywhere we're coming here.

If anyone is curious about our workflow I can give a broad summary. We use Spine for all character and background animation. If it's animated, it is pretty well done in Spine and brought into GameMaker. From my perspective it has been a huge time saver for our small team. I can't imagine Boss 101 done without it and done in the same amount of time. Your mileage may vary and it might not be the best thing for you but it is worth a look. There are a couple pricing tiers and honestly - the lowest price one has all the features I ever use. If you have further questions you can message me or ask here. I will answer as I can.

Thanks for reading and hopefully this lands under the right eyes.

-Tim
 

obscene

Member
Unfortunately this isn't a bug but just a feature they never implemented. It's been requested and Yoyo seemed interested but probably not going to see it anytime soon I'm afraid.
 
  • Like
Reactions: Tim

Tim

Member
Unfortunately this isn't a bug but just a feature they never implemented. It's been requested and Yoyo seemed interested but probably not going to see it anytime soon I'm afraid.
Dang that's unfortunate. I do hope this gets done though. Fingers crossed for sooner than later!

Thanks for the reply!

-Tim
 
T

Tirous

Guest
Could such things be implemented manually? Like with a fancy dll or something, if so then one should make a extension for it and put it up on the marketplace or whatever.
 
  • Like
Reactions: Tim
Could such things be implemented manually? Like with a fancy dll or something, if so then one should make a extension for it and put it up on the marketplace or whatever.
Well, if you can use Spine without the runner in GameMaker, then I guess yes, you could make that manually - the code must be in the json, and GameMaker can open json-files as ds_maps :) Not something I want to try right now, though even if I did, I think it would take some work to make it function fast enough/well enough to make it really usable ^^

But is it possible? sure
 

Tim

Member
I do believe they will update the Spine runtime soon, so we can all cross our fingers they will be including that feature as well :) In all honesty I doubt they will, because I can understand why they haven't already, but we are allowed to hope :D It would be a lovely feature to have :)
Out of curiosity why do you doubt they will or understand why they haven't? Not looking for a blame candidate - mostly curious.

From my end I could imagine Spine and GameMaker teaming up on this front and actually moving copies of both software packages. I say that as a game developer of 25 plus years plus a purchaser and user of many, many game dev software packages. Like anything else I get this is probably no small feat but if you are looking to bring in more people to the fold you could do worse than expand Spine's functionality into the Event system.

We talk daily about how useful it would be and the time if would save. It would open up a world of options from the art end and allow much easier triggering of specific timed events (of which any game has tons). Firing animations could spit casings at a specific frame, light flashes, explosions, sound FX and the list goes on. I feel I'm preaching to the choir though - if you get it you 'get it' if you don't you might need an example or two but trust me, you will benefit! HA!

-Tim
 
I would love the feature, and I can only say preach brother :D I "get it" and have "got it" (and hoped for the feature) pretty much since the beginning :)

My reason of doubt is pretty simple: They left it out the first time around, and have made no indications they will add it now (though maybe I should try ask them?), and then I have a hard time seeing exactly how it would work (which is how I "understand why they haven't"):

You could get the Spine-Event data in somewhat same manor as you use skeleton_bone_state, since this is how you currently access data from the skeleton. But timing between game steps, image speed and keyframes can easily be askew, which could result in skipped Spine-Events. You could of course circumvent this by "bulking-them-up" and give you all the would-have-triggered events between the last step and the current one, but then you would need to supply timing-data as well.

Or you could add it into GameMaker as a GameMaker-Event, which would probably be the best way.. Still, here the problem is if the programmer manually controls the image index without using the build in image_speed property. If the programmer adds two to the image index, you might want to run the Spine-Events in-between. However, if the programmer resets the image index to 0, would you want to trigger all the Events in-between that? (could be many)

I think the feature can be added easily, and then it will be good for some, and bad for others (depending on the pros and cons of the chosen way to do it), but I have a hard time seeing a clean way where it will just work for all purposes.

Though I might just be overthinking it xD Honestly I would be happy with even a non-perfect solution :)
 
  • Like
Reactions: Tim

Tim

Member
I would love the feature, and I can only say preach brother :D I "get it" and have "got it" (and hoped for the feature) pretty much since the beginning :)

My reason of doubt is pretty simple: They left it out the first time around, and have made no indications they will add it now (though maybe I should try ask them?), and then I have a hard time seeing exactly how it would work (which is how I "understand why they haven't"):

You could get the Spine-Event data in somewhat same manor as you use skeleton_bone_state, since this is how you currently access data from the skeleton. But timing between game steps, image speed and keyframes can easily be askew, which could result in skipped Spine-Events. You could of course circumvent this by "bulking-them-up" and give you all the would-have-triggered events between the last step and the current one, but then you would need to supply timing-data as well.

Or you could add it into GameMaker as a GameMaker-Event, which would probably be the best way.. Still, here the problem is if the programmer manually controls the image index without using the build in image_speed property. If the programmer adds two to the image index, you might want to run the Spine-Events in-between. However, if the programmer resets the image index to 0, would you want to trigger all the Events in-between that? (could be many)

I think the feature can be added easily, and then it will be good for some, and bad for others (depending on the pros and cons of the chosen way to do it), but I have a hard time seeing a clean way where it will just work for all purposes.

Though I might just be overthinking it xD Honestly I would be happy with even a non-perfect solution :)
Yeah, I think the deal is - if there are questions ask the community at large. That's effectively what these forums are for. Designing in a total vacuum is OK for some things but this might be better served by talking with people who have a lot of Spine experience. It's not an ideal situation to solicit that kind of help but it makes a sort of sense.

I understand there are plenty of reasons this could be tough feature to implement but perhaps some back and forth with people working day to day with Spine on a shipped or shipping product might reveal it's easier than we think in terms of implementation. By that I'm referring to the scope of what would serve people well. We might not need every bell and whistle available.

This is all grand speculation on both our parts and maybe it's easy to do, maybe it's not. I don't know and we're guessing at this point. What I do know is this - I have used Spine for about 6-8 hours a day with GameMaker for the last two plus years to animate a lot of things. Before that I did game animation and worked with game editors for nearly 20 years. Many times I have spoken with our lead programmer about the things we could do with events and the time saved by moving certain 'triggerings' over to my plate instead of his. Events would solve a lot of little things for us and allow a small team like ours to do more. Mostly it would let Spine be sort of an 'editor' for our cinematics and gameplay scenarios. The event system would move a lot of convoluted timing scripts we have over to a much more straightforward "when I hit frame X then create this (object, scene change, VFX, SFX, etc)".

You get it so I won't belabor it. I also know people who don't use Spine a lot or perhaps only in a cursory fashion might not see this as a worthwhile effort. To them I can only say - talk with me and I believe I can help convince you Spine is a pretty good investment if you have an animation heavy game in the pipe. My hope is to get more people using it and then as a group have more leverage to request changes in the way Spine integrates with GameMaker. In the end I see this benefitting EVERYONE. Spine might be to animating in GameMaker what Photoshop (or insert fav graphics program) is to making Sprite art. There is no reason to expect GameMaker to have top notch art and animation editors on top of the underlying engine. What I mean is GameMaker will likely never have a "Spine-like" tool built in. Just like people working with Unity might use 3DSMax or Maya; I see Spine having a similar relationship to GameMaker. Why not? HAAAAAAA!

At any rate - let's hope for some traction.

-Tim
 
Last edited:
Not something I want to try right now
Okay, I tried anyways, and thought you would like an update :) I have made a couple of scripts which allows us to access the Spine-Events, though there is some caveats:
  • It only works for track 0, and..
  • You need to have a copy of the json as an included file, since I cannot access the files used in GameMaker, though a json is just text, so that should not be too bad.
I have not tested the speed or anything, and I am still working on refining it for public release, but it works and should be of use already :)
To use it, first you need to initiate the system by calling spine_events_init();, and then you can use spine_events_add_json(); to link your sprites to the extra, included jsons. First argument is the sprite index, second argument is the path to the json file.

After this is done, you can call the spine_events_listen_for(); script to listen for specific events. For example, your animation may have an event called Step, in which case you just do this:
Code:
var __a = spine_events_listen_for("Step");
If the event has not been triggered, it will simply return 0 (false), but if the event has been triggered it will return an array with four indexes:
  1. The int-value you can set in Spine
  2. The float-value you can set in Spine
  3. The string-value you can set in Spine
  4. The duration offset*
I will probably finish up the system soon, but until then you are welcome to use this W.I.P. to play around with :)

* If your current image index is 1, the event is happening at 2, and your image_speed is 1.3, then the event will still trigger after passing 2 and the fourth index will contain the duration difference. This will not be .3, since it is measured seconds, but the value can easily be converted to image frames:
Code:
frame_difference = __a[3]/skeleton_animation_get_duration(current_animation)*image_number;
Hope that explanation made somewhat sense ^_^
 
  • Like
Reactions: Tim

Tim

Member
Okay, I tried anyways, and thought you would like an update :) I have made a couple of scripts which allows us to access the Spine-Events, though there is some caveats:
  • It only works for track 0, and..
  • You need to have a copy of the json as an included file, since I cannot access the files used in GameMaker, though a json is just text, so that should not be too bad.
I have not tested the speed or anything, and I am still working on refining it for public release, but it works and should be of use already :)
To use it, first you need to initiate the system by calling spine_events_init();, and then you can use spine_events_add_json(); to link your sprites to the extra, included jsons. First argument is the sprite index, second argument is the path to the json file.

After this is done, you can call the spine_events_listen_for(); script to listen for specific events. For example, your animation may have an event called Step, in which case you just do this:
Code:
var __a = spine_events_listen_for("Step");
If the event has not been triggered, it will simply return 0 (false), but if the event has been triggered it will return an array with four indexes:
  1. The int-value you can set in Spine
  2. The float-value you can set in Spine
  3. The string-value you can set in Spine
  4. The duration offset*
I will probably finish up the system soon, but until then you are welcome to use this W.I.P. to play around with :)

* If your current image index is 1, the event is happening at 2, and your image_speed is 1.3, then the event will still trigger after passing 2 and the fourth index will contain the duration difference. This will not be .3, since it is measured seconds, but the value can easily be converted to image frames:
Code:
frame_difference = __a[3]/skeleton_animation_get_duration(current_animation)*image_number;
Hope that explanation made somewhat sense ^_^
Awesome and thanks for looking into this. Our programming lead is checking out your idea and seeing how it might integrate into our pipeline. Perhaps something can come of it.

Regardless though - we really appreciate your making an effort on this!

Best,

-Tim
 
J

Joshua Allen

Guest
Ok, I’ve looked at it and made a few changed that would better suit our needs.
Here is a link: Spine events

As you can see I made spine_events_listen() because what we want to do is have events like “sound snd_shot1” so all I have to do is parse the string and execute the command. We have something like it with our text box system.
 
Ok, I’ve looked at it and made a few changed that would better suit our needs.
Here is a link: Spine events

As you can see I made spine_events_listen() because what we want to do is have events like “sound snd_shot1” so all I have to do is parse the string and execute the command. We have something like it with our text box system.
Whatever suits your needs :) The reason I did the listen_for was so that different events can happen at the same time, but if that's not a need in your project, it makes sense to leave it out ^^

I'm happy you found use for it :)
 
  • Like
Reactions: Tim

Tim

Member
Whatever suits your needs :) The reason I did the listen_for was so that different events can happen at the same time, but if that's not a need in your project, it makes sense to leave it out ^^

I'm happy you found use for it :)
Yeah - your code was what Joshua built from. Overall, we like the idea A LOT (as you already know). Really appreciate the effort too!

I recall one of the things Joshua mentioned was this system required a re-work of how we add Spine files - I think we have to drop a copy of the .JSON in the Included Files AND put the Spine in the Sprite folder. Ideally some people at YoYo take a look at official integration for Spine Events so we wouldn't have to go that route. Wouldn't that be nice!

-Tim
 
Yeah - your code was what Joshua built from. Overall, we like the idea A LOT (as you already know). Really appreciate the effort too!

I recall one of the things Joshua mentioned was this system required a re-work of how we add Spine files - I think we have to drop a copy of the .JSON in the Included Files AND put the Spine in the Sprite folder. Ideally some people at YoYo take a look at official integration for Spine Events so we wouldn't have to go that route. Wouldn't that be nice!

-Tim
Sure would be ^^
 
  • Like
Reactions: Tim
Top