When SpriteKit came out in iOS 7, I thought it was a game changer. A lot of people in the community seemed really excited by it and I was looking forward to seeing what people would come up with.
Four years down the road, I am seeing far less SpriteKit love than I thought I would. SpriteKit still gets more love than SceneKit, but not nearly as much as it did when it first came out.
My friend Paul Hudson is a technical book author who is so prolific that it’s astonishing. He mentioned to me earlier this year that he had a killer idea for a SpriteKit book that was completely unique and he was surprised that no one had attempted it before. That idea culminated into his newest book, Diving into SpriteKit.
The gist of the book is that it’s a riff off of Choose Your Own Adventure. You will come to certain points in the book where you make choices that affect the direction your game moves in. These changes can be as simple as choosing a theme for the game (space, under the sea, etc…) and as complex as choosing the goal of the game and how scoring works.
The book comes with four projects. Each project has multiple choices that you can make to create a different game. This gives the book instant re-readability. You can work through the book a half dozen times and try out a lot of different mechanics.
One thing that appeals to me about this approach is this choice mechanism. I have spoken to a lot of people who learned to program on the Apple II. These people have told me about having the experience of programming a game in BASIC and wondering what would happen if they change one thing, and then another and another.
I’m a better programmer than I once was, but a lot of times when I work through a tutorial I worry about changing anything because I am afraid it will break. I appreciate being given the experience of making changes to the game with enough hand holding to ensure that the game won’t break. Some people really groove on breaking and fixing code. I am not one of those people!
Diving into SpriteKit is a good introductory book for SpriteKit. Paul includes a lot of SpriteKit chapters in his flagship Hacking With Swift book that are far more advanced and complicated than any game you create in this one. That isn’t necessarily a bad thing.
Game development has different design patterns than normal mobile development. One thing that really held me back for a long time was my assumption that SpriteKit would be a flavor of Cocoa and share most of Cocoa’s design patterns. SpriteKit was designed to be more like Unity than UIKit. Once I grokked that game development had its own feel and design patterns my life got a lot easier.
Another issue I had with getting into game development was trying to find or make assets. I assumed the programming would be the hard part, but creating and finding assets really holds you back. Paul cited several cheap/free resources for assets. You can use these in production or simply have them for prototyping before investing in hiring an artist/composer for your game.
I found Diving into SpriteKit to be very approachable and I would highly recommend it to someone who didn’t know much about SpriteKit but was familiar with Swift. I think it’s a good foundational text that makes more complex SpriteKit books more approachable. It’s also fun to use as programming practice. I like to spend an hour or two in the morning just working through tutorials to help warm up my brain for the day. I greatly enjoyed working through this book the first time for that purpose.