Does anyone actually use Sprite Kit?

I have bulit an educational game entirely on SpriteKit. It hit the store and I have my first happy customers.

Apparently it worked for me.

The editor is undocumented, it's true. It has some other problems.

There's no snapping to grid, but I don't remember that I ever needed it.

I don't use the editor at all. I just want a game engine with as low CPU overhead as possible. The time I've spend placing buttoms in scenes is negligible in comparison with other stuff.

Why would using editor cause a CPU overhead?

No, of cause it doesn't. I just meant that I think that a framework like sprite kit shall focus on lightweight functionaltiy that works. I prefer quality instead of lots of buggy functionality. As an example, a stable game kit would have saved me lots of time.

I have had similar difficulty in trying to find documentation of the editor.

So have resorted to working programmatically - but doesn't seem right!

I'd appreciate anyone else's thoughts on this too - what do people actually do to lay out screens?

Isn't editor good enough without the documentation? I have no troubles using it.

It's pretty much drag-and-drop for most of the time 🙂

Sorry, but I don't think you've really looked into using Sprite Kit at all. It has an entire Scene Editor where you can add sprites, set their class, physics body properties, actually test the physics (without building), etc, And as of Xcode 7 you can use a Timeline to animate things. So for example, you could make a giant gear with the physics body set to the exact shape of the gear's artwork, and create a looping animation of it without any code. With Xcode 8 you've got Tile Maps now. Its an incredibly powerful game development framework. So it most definitely does have an easy way to layout an interface and entire levels.

I'm using SpriteKit to do quite a bit of UI and layout. For my card game Pharaoh, I'm using the .sks editor to lay out the location of all the UI elements and hooking them up to the functionality using the class-setting feature of the editor.

I find it easy enough to use. There are a few rough edges here and there, but for the most part, I find it very easy to lay out and wire up a new scene's UI with the .sks editor in Xcode.

There are a few "best practices" I've settled on:

* Use the "Aspect Fit" or "Aspect Fill" sizing mode for your scenes, and pick a reference size for all your scenes. Then, parent the stuff you want to move around based on the form factor of the device you're using to some appropriately-named SKNodes, like "top", "upperLeft", "lowerRight", "center", etc. I wrote a custom extension to SKScene that allows adopting that reference width or height, and then pegs those nodes to the extents of the scene so I can use those nodes in all my scenes and forget about them. No matter what device I'm running it on, it all uses the same .sks files.

* Don't bother with overriding init() or init(coder:) for your SKScene's or even SKNode's. Wiring things up for your scenes is just as easily done in your didMove(toView:). Learn to use the childNode(withName:) syntax, and you will be able to grab references to whatever you need to in the scene. Cast them to whatever it is you expect them to be, and you can configure them however you need to in the scene. Tear everything down in willMove(fromView:). Edit: It looks like there is a sceneDidLoad() function that may be a better choice than didMove(toView:) for this stuff. It's new in OS 10.0, so it's not backwards-compatible, but it makes your initialization safe to do in another thread while still avoiding the double-init dance.

* Expressive naming will really help with the above and your code readability - it's obvious what scene.childNode(withName: "QuitButton") is getting a reference to. It also helps you navigate your scene using the inspector.

* You can set SKNodes, SKScenes, SKSpriteNodes, etc. to use a custom subclass by typing the name of the class in the editor. (You have to click over to another panel in the inspector.) This allows you to define specific functionality for the things you add to your scene. For instance, I made a "Button" class that is a subclass of SKSpriteNode, so I can turn any sprite I drag into the scene into a button just by typing in the word "Button" in the class field. Since it accepts a closure for its action, I can just wire up its action in didMove(toView:) by grabbing a reference to the button as mentioned above.

* I also like to create "Templates" of things that will be spawned at runtime. For instance, in my game, I have a card almanac that you can swipe through to see information on all the different cards. In the .sks file, I have a SKNode called "Template" that has a SKSpriteNode for showing the card, an SKLabelNode for the name of the card, etc. To make the individual card displays, I just grab a copy of the "Template" node, remove it from the scene, and for every card I want to show, I copy the template, grab the appropriate children of the copy to set the sprite's image and the label's text, and add the copy to the scene. This allows me to do things like change the spacing, the font, the scale, and other things for these dynamic elements using the .sks editor GUI.

* Control your z-depth. I try to have a plan for where all the important z-levels are going to "land" so that when I create some new element, I set its z position accordingly. This requires a bit of discipline, especially as you go parenting things to other SKNodes, since you sometimes have to do a little math to figure out a node's "real" z position, but it pays off. Everything defaults to zero z-position, which can cause problems if you just let it sit there. Always be explicit about it, and you will save yourself some headaches.

* Remember that when you cut and paste an element in the .sks editor, it puts it 20pt to the right and 20pt down. A quick shift-up-up-left-left will put whatever you pasted right where the source was. Handy for making arrays of things or copying oft-used layouts to other scenes.

Hope this helps.

> Wiring things up for your scenes is just as easily done in your didMove(toView:).

I believe this may lead to a visible delay. Am I wrong?

I'd prefer to prepare everything before a scene is moved to view.

> I believe this may lead to a visible delay. Am I wrong?

I suppose it might if you do a lot of wiring-up in didMove(toView:). But I have yet to have an issue with this approach, and I do quite a bit of initialization stuff in there.

At least in my experience, most of the time, you only need to grab a handle to a handful of items. Things like setting a closure for a button to fire, or injecting model references into displays. Stuff like that, unless you do a crazy amount of it, isn't going to affect your fps.

And since it would be identical computation whether it appears in init() or didMove(toView:), the only difference between the two is whether you can shove that initialization off into another thread while you set it up. If you're not already creating your scenes in another thread, it's identical behavior, and therefore extra work/clutter to do all that in init()/init(withCoder:). And if you do decide to shunt that initialization off to another thread because a particular scene is acting up, it's simple enough to do that when it is needed - no need to do premature optimization.

Looking at the documentation for SKScene, however, I just noticed that there is now a sceneDidLoad() function, which is new to iOS 10. This might be the best of both worlds - it avoids having to define everything in multiple init methods, keeping the cruft down, while still handling all the initialization at load time instead of display time so it would take advantage of a scene being initialized in another thread.

Edit: There are also some issues with doing setup in init(withCoder:). It turns out that if you set a node to be isPaused = true in your .sks scene's init, it will be unpaused by the loading process anyway, and become unpaused again, whereas if you pause it in didMove(to:view), it will "stick".

To your main question, very few people use SpriteKit. It's nowhere near the popularity of other engines.

I believe there's some very clear reasons for this lack of use, but your point is one of the biggest.

That there’s not many users is now a self perpetuating pattern and now a significant problem because it prevents the kinds of progress that would grow users, mainly because Apple seems to be putting little to no resources into SpriteKit.

The lack of users was inevitable in SpriteKit's first version - unavoidable. Everything new starts at zero. But any release of a clone of the basic premises and paradigms of cocos2D needed to grab audience and users. It didn’t… and some of those reasons are telling and continue.b

1. BUGS! There were huge claims about its rapidity of use and performance. But the first version had an array of bugs when dealing with sprites and textures, the very things it was claimed it was good at.
2. CLAIMS! Every release has been pitched and marketed at WWDC as though it was the new coming of a golden era in game engines. Each year there’s more bugs and horrendous oversights.
3. PERFORMANCE isn’t what it’s claimed to be, unless you do everything right, and to the (unknown) limitations and contortions desired of the engine
4. DOCUMENTATION is bereft of any truly welcoming aspects and is ageing rapidly, not kept up to date and often left in an Objective-C state
5. DESIGN of this engine is non-existent. It’s a MishMash of ideas, paradigms and processes all parcelled up in a manner that’s extraordinary difficult to discern because much of the ideas are at odds with one another. This has become much more so in the Swift world.
6. UNAPPROACHABLE: Swift typing is painful, in both senses of the word “typing” as it applies to programming. Autocomplete stammers and stutters (didn’t previously work at all) and refactoring is impossible. This despite refactoring being something the iterative nature of game development requires more than most all other programming endeavours.
7. PREREQUISITE REQUIREMENTS: The “ease of use” that might have been in Sprite Kit has only been true for the unfriendly looking Objective-C and those already familiar with Apple’s take on MVC in its other frameworks, which is a massive hurdle, to put it mildly.
8. PIECEMEAL additions. Physics are a great example, no delta time, then weird fields, their natural conflict with the Actions paradigms of movement, the shitful timeline that crashed all through Xcode 7’s life, a disconnected particle editor, and now a tile map system that’s half baked.
9. UPDATE ****: Apple doesn’t acknowledge bugs, doesn’t inform progress on fixes nor list changes in each update that does come out. It’s a mystery mix every point update, which means everyone has to test their games, again. In the dark.
10. PARADIGM BLENDS: GameplayKit’s attempt to integrate ECS thinking into the current blend of MVC, event driven, physics and game loop **** that is already there is absurd. Next year we’ll probably get a focus on POP and structs to add to the mix.
11. NO PROOFS! There’s no little demos, no little samples for each and every feature and approach, no insights into how to best do things, nothing to really get at where and how they think
12. ABANDONMENT: Apple’s not been shy about just ignoring their massive samples that were supposed to demonstrate the power and functionality of Sprite Kit.
13. A POOR RECORD in the fold at Apple, they have consistently showed a failure to support SDK, software and API/Frameworks. Their long history of neglecting Core MIDI, SceneKit’s wobbling state, the complete neglect of Core Animation in 2016’s WWDC (despite the fact it’s being shifted to Metal), and whatever your pet API/Framework is… goes here
14. THIS FORUM is an outpost that exemplifies many of the points above, and demonstrates the lack of use of SpriteKit and Apple's lack of dedication to it...

Yet I like that it launches quickly. And that it forces me to learn Swift and gripe and yell about Apple's foibles. And it makes things like UIKit look reasonably polished, by comparison.

my game is entirely SpriteKit, coded. never used the layout stuff. I found it much easier to define everything in Swift.

works for me anyway.

wow.. i find the complete opposite to most of your points...

I've now built a couple test projects in SpriteKit and am currently building two commercial projects, which will both be released within the next three months. So you can say I'm very involved in making SpriteKit work for me, and would love to see it flourish. I think the main grievance I still have with SpriteKit is the lack of cross-platform support (of course), which is the number one issue when pitching it to clients as a platform to use. I'm happy to live with that, though, as I've already pivoted my career from full-stack web/mobile to iOS. In terms of game development, my history has been with Cocos2D, so transitioning to SpriteKit was relatively painless, or more of an educational challenge.

I gave the Scene Editor several serious tries under Xcode 7, but it never offered the flexibility that was necessary for my projects. So eventually I just went back to my Cocos2d days and continued doing stuff entirely in code, which is what I continue to do now. I've noticed that some things have improved with Xcode 8, such as reordering layers on the timeline (DUH!), but it's still nowhere near the efficiency I can get by just code. I'm personally a stickler for screen-size responsiveness, so the lack of auto-layout and constraints already turns me off in a big way.

I do a lot of dynamic stuff, so in a way a visual editor in many respects won't give me the flexibility I want. Where the Scene Editor would be the most necessary, however, is the laying out of images in a complex hierarchy with placement coordinates, based on for example a Photoshop file. But for the life of me, even after more than a year of trying, I can't get what I want done. So with those hurdles, it's just more efficient to write it up in code.

Good post!

I code most everything by hand as well, but the editor is good for mockups / quick animation building. It's definitely way more powerful with tile-maps, and being able to make custom classes for nodes in-editor is good too, but I don't use it often.

However, I would think that it would be almost mandatory for something like a side-scroller... since you'd have elaborate and detailed levels that would need to be visualized (especially if you had a level designer / artist that wasn't part of the code team).

I haven't tried making a platformer like that, but I imagine I would need to make friends with the Scene Editor quickly >.>