Hi Nate,

Thanks for the honest responses and the info you've shared. I think this gives me a better plan too. I was considering doing the Runtimes from scratch if needed, but as you've stated it is a lot of extra work. So thanks for sparing me that Previously I was a bit frustrated because I felt like I needed to do that extra work, but it sounds like I don't.

It sounds like I need to try the generic c official runtimes and implement the SpriteKit for the sprite renderer.

Don't worry about doing UE4 first - I understand your priorities.

When you discuss the SpriteKit problem as "rendering images requires positioning rectangles by setting their scale, rotation, and translation," I'm guessing this is as opposed to other engines and frameworks that allow for 2D meshes to be rendered similar to how they are in Spine or (in 3D in Blender/Max/Maya). If that's the case, there may be a solution to this problem with SceneKit - but I'll have to double check on that.

Please share anything else I may need to know about what's needed in the rendering engine to make mesh deformation and non-uniform scaling work, and I'll see what I can find in SceneKit and report back here.

So, I've reached a place where I'm stepping back and re-evaluating where I want to go with my personal dev of SpriteKit Runtimes.

If you've followed my posts so far, claybear39 and I have cobbled together some fixes and adaptations to Michael Redig's SGG_SKSpineImport libraries that allow them to be used in current versions of Xcode with Swift (using the bridging headers).

Right now I'm trying to implement IK constraints in SGG_SKSpineImport because they are not already in either of the two libraries that are for SpriteKit:
mredig/SGG_SKSpineImport
simonkim/spine-spritekit

I'm at a point of no return. I'm having to make significant amounts of new code in the SGG classes to implement missing features. Both of these libraries are coded in Obj-C not Swift. They do work fine with Swift, but I'm not enjoying going back to Obj-C to add functionality.

Before I scrap my current work and jump in with making my own Swift/SpriteKit Runtimes I'd like to know a few things from the community and from the developers at Esoteric Software.

1. EsotericSoftware Developers: Do you have active plans for an official Swift/SpriteKit Runtime? If so can you share an estimated date of completion?

2. Esoteric: Do you have any pseudo-code written up for the runtimes? If so, would you be willing to share that with me? I'd like to understand the code better if I'm going to make a new Runtime library.

3. Community: What interest level is there? I've noticed a few people (2-5) that have responded to my previous posts or posted similar topics. If you are interested in Swift/SpriteKit Runtimes and haven't yet said anything, add a comment.

I'd like to have Swift Runtimes for a variety of reasons. I'd like to work with the developers and the community as everyone is interested and able. I plan to post the finished results to gitHub so that anyone can use them. Let me know how you'd like to help if you're able.

Hi gobione, from what I can tell if you flip a sprite in the Spine editor by animating x or y scale to -1, things work fine as is with SGG_SKSpineImport. I've already tested that and have an example working in an app. I think the skeleton itself can be flipped with the existing tools, but you'll have to double check the example file.
Also worth noting - you'll have to follow claybear39's post to get these libraries set up. That's because they are not yet implemented in Swift, but Apple's interoperability between Swift and Obj-C works really well. It means you'll have to set up the bridging headers. I can see lots of benefits to an official fully Swift and SpriteKit runtime, but the SGG_SKSpineImport libraries may be fine once I've got the IK constraints implemented. (If you don't use those, you're already set with the SGG libraries as is.) Although due to differences in Swift and Obj-C (I think that's why) you may want to add in what I posted on ben_ 's thread on the runtime forums. It's a getter/setter method for the queuedAnimation property. If you don't explicitly state it there you'll end up with a nil reference thrown to the REPL loop and it will crash everytime in Swift.

If you want to wait, I plan to post my updates to the SGG_SKSpineImport libraries on github after I complete the IK constraints classes and methods.

On the implementation of the IK constraints - I have a question for Nate or whoever handles the runtimes on the esoteric software team: (I'm referencing the official generic C# runtimes) where do you find the values in the JSON data to set the BoneData's properties FlipX and FlipY? Are those inferred somewhere by getting the pos/neg sign from the scalar values? Also, where do you get the alpha/mix property for the IKConstraintData and IKConstraint? I'm guessing this is something that can be specified in the editor to say, for instance, I'd like to weight an IK Constraint to 0% in an animation so I can basically use FK animation, or 30% for a partial effect. Is that right?

ben_, Shiu, I apologize. I have tried the simonkim/spine libraries, but right now I'm working with what claybear39 posted here (SGG_SpineImport): viewtopic.php?f=7&t=3737
Follow claybears39's directions there and then you can add in those additions I've posted on this thread.

I'm making progress on the IK Constraints and considering doing a z-sort/draw order method if it's easy enough to do on the way. I'll post those when I finish them. I'll need some people to test then :happy:

Hi Mitch,

Indeed Xenogears is my all time favorite and reason I make games.

My day job work has been in IT for a few years now and I go in phases of paranoia of internet info/security, so I occasionally go by obscure aliases. You can call me Alan if you'd like.

Hey everyone,

I've been spending more time on the runtimes section of the forums, but I thought I might post my progress with the actual animation. It's a blast to animate in Spine, things are very easy to use, straightforward and powerful. I started learning 3D animation a while back and still love that, but have found this pipeline to be much quicker to get really great results.

So this is an islander girl that is (currently the only) character in my global game jam entry this year.

More on the game here:
http://globalgamejam.org/2015/games/samsara-cycle

A game about the cycle of life and moving on. It is planned to be an experience that moves beyond being a survival game and into a place where circumstances and interactions beg the player to decide their next move. Often with no warnings, motivations or obvious decisions much like life. I'm posting what I have which is basically the movement system and day/night cycle. This game is dedicated in memory Jessica Link, a childhood friend that sold me her NES - my first video game console. One of her last wishes was for all people to consider and register as an organ donor as she did. Breathe easy, Jess.

Since then, I've got the animated character working in the app, though I need to implement IK in the SGG_SKSpine runtimes I'm using. I've also added a basic system for player hunger and a fish that can be eaten to satisfy the player character for a short period of time.

Some more animations I plan on doing are: emotions/expressions, walking, fishing, sitting, sleeping, aging, dying, sickness, trees in the breeze, moon phases, waves on the beach.

Thanks for what you've posted claybear39, it's a huge help in getting started. I've already added an implementation for the queuedAnimation property that may not be necessary in Obj-C, but was in Swift due to optional mess. I'm going to look into an IK implementation, but it seems like it's going to be a bit more work to do that. I'll either post here or set up a gitHub repo with my changes to Michael Redig's work on these libraries.

I too have been working through this style of pipeline. SpriteKit and Swift are now the way to go if you are making iOS apps that you don't immediately want to port to Android. I'd really like to see an official runtime as well.

The simonkim/spine-spritekit that you mentioned is what I'm using. I'm able to switch animations by calling SpineNode.runAnimation() with the different animation's name on whatever event I want to switch it on. I haven't figured out how to make the transition happen smoothly yet, it just abruptly goes from one to the other, but you can barely see the difference with the animations I'm using.

Benjamina, are you using Swift or Obj-C?

I can't seem to get the queueAnimation function to work properly without crashing in Swift. I think the problem I'm having comes from how Swift handles optionals. Basically I'm trying to set the property of SpineNode.queuedAnimation? = "animation" and I keep getting nil returned. Do you have any ideas on how to actually set the String to that property? If so, I think things would be much more functional with this runtime.

Okay, so I figured out why the queuedAnimation feature wasn't working - it hadn't been fully implemented.

I added this to SGG_Spine.h at line 60 (Obj-C):

-(void)queuedAnimation:(NSString*)animationName;

and this to SGG_Spine.m at line 40 (Obj-C):

-(void)queuedAnimation:(NSString *)animationName{
    _queuedAnimation = animationName;
}

In the viewDidLoad method of your GameScene you'll need to set the queued animation like so (Swift):

girl.queuedAnimation("animationName")

Then I can evoke it in my GameScene in any event function like touchesBegan (Swift):

girl.runAnimation("wave", andCount: 1, withIntroPeriodOf: 0.1, andUseQueue: true)

where "girl" is the SGG_Spine node that I've created. The andCount:1 part runs the animation twice then returns to the "animationName" That we queued up earlier.

Let me preface this support by saying that I kickstarted Spine and really enjoy using it. Coming from 3D animation, it makes a lot of sense and does things simply and well.

So here's a question for the dev team: which runtimes support meshes and FFD? I'm assuming the official ones do but I'm having trouble finding a quick chart in the documentation. These features are really cool and I'd like to use them for things like facial animations.

Second, I posted on another thread and I wonder why there's no Swift/SpriteKit official integration. I'd be willing to work some with coding/porting that but I'm trying to figure out at this point if it's worth it. I know Apple's got a lot riding on people using their own tools or else they wouldn't have made swift or spriteKit - but are most people still just using Cocos2D?

I'm going to try what claybear39 is using and then I may write my own iOS 7.1/8.x SpriteKit Swift importer. We'll see how it goes. I'll come back here to post it when I get things worked out. Part of the reason Obj-C libraries aren't all ported to Swift yet is that Swift has changed up several of the basic concepts of coding - and for much of this year was in a beta state that changed. Theoretically you can also bridge between the code because I think swift eventually compiles down to obj-c.

That aside, I really enjoy Spine and look forward to using it in projects on iOS in Xcode.