Book Review: Diving into SpriteKit

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.

Just one iteration of the many choices you have for games.

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.

Raspberry Pi NES Emulator Project

In my previous blog post, I mentioned that I didn’t grow up with a video game console of any kind. My experience with Super Mario Brothers was watching other people play from the couch.

I had wanted a mini-NES when they were released last year because I never got to have one when I was a kid. I didn’t get organized to camp out and hunt one down and I lost out. I was incredibly disappointed at missing my second chance at having an NES.

My birthday was earlier this month and The Boyfriend indicated he had put a lot of thought into organizing it. I was super curious about what he found me. I thought maybe he found the mini-NES, but he found something better. Instead, he bought me a Raspberry Pi to build an emulator.

Bill of goods (plus a pug card) for the Raspberry Pi emulator

I knew a lot of people advocated using emulation for retro games, but I thought it wouldn’t be the same experience. One thing that appealed to me specifically about the mini-NES was the form factor. It looked like an NES. It was small and cute. It had tactile buttons. You could tell a lot of love and attention to detail were lavished on the design of that product.

The Boyfriend also has an eye for design details and knew that was a major part of the appeal of the mini-NES. He scoured the web looking for a good enclosure and managed to find one that felt like the mini-NES. It had tactile buttons, was the right color, and even had a slot where the cartridges used to go.

Parts List

Here is a list of all the parts he bought to help build the mini-NES emulator:

The first and most important part of this assembly is the Raspberry Pi. For anyone not super familiar with all the hipster IoT stuff, the Raspberry Pi is a full computer board the size of a credit card. It differs from Arduino by the nature of the projects both are designed to do. Arduino is designed to do rapid prototyping of electronics projects that need to talk to sensors and buttons by removing the need to understand how to solder or design circuit boards. Raspberry Pis are ideal for single, self contained projects and tasks where you require a full operating system. Emulation is a common use case for Raspberry Pis. Penetration testing is another. It’s possible to build a Linux emulator within a virtual machine on your home computer, but it’s more fun to have a dedicated device that is portable and easy to connect to the TV. There are a lot of different models of Raspberry Pi. The emulator site recommends using the Raspberry Pi 3 Model B.

The second most important component is the enclosure. There are many knock-off mini-NES enclosures on the market, but they’re not all created equal. Some don’t have the right kind of buttons. Some are not as detailed. This particular one was pitch perfect in recreating the look and feel of the NES.

The MicroSD card is where the operating system and the emulator are stored. This card will also hold all the games. The ROMs for the games are not super large, but it’s good to have a decent amount of space to hold all the software components.

The final three components are all adaptors. Being an electronic device, the Pi requires a power adapter. This specific power supply had the proper connector. Additionally, we required extra power to fun the lights and buttons on the enclosure. Rather than trying to buy reproductions of the controllers, The Boyfriend brought his own childhood controllers to use with the emulator. There is a certain tactile feel that you can’t reproduce that you get from the original hardware. These predate USB, so we require an adapter to be able to connect the controllers to the Pi. Plus USB is low latency so there is less of an issue with lag.

Now that we have all our necessary components we need to install the emulator and the ROMs.

Emulator Installation

There is a good main site to go to for a Raspberry Pi emulator: RetroPie. The emulator is solid and it has an excellent installation guide.

We had to flash the emulators to the micro SD card. I fortunately still had an older MacBook Pro before Apple eliminated the SD card slot. We had some slight trouble because the MicroSD adapter that came with the card was defective. We managed to scrounge up a new adapter, but fair warning that the adapters can go bad pretty easily.

There are directions on the site about how to install the emulator on various devices. I initially thought to follow the Mac directions, but I remembered that the actual operating system for the Pi was Linux. We used Etcher to flash the emulators to the SD card.

Adding ROMs

One of the components in the box of goodies from The Boyfriend was a USB drive with a bunch of ROMs that fell off the back of a truck. ROMs are the programs you need to load onto the Raspberry Pi in lieu of using a disk or a cartridge. You can blow on the USB if that makes you feel better, however.

We found the initial process to be slightly confusing. The directions are fairly straightforward. You need to create a folder called retropie on your USB stick and plug it into the Pi. The directions tell you to unplug it once it stops blinking. Our USB stick never stopped blinking and we got confused. I am uncertain if the directions meant the Pi or the USB stick. After a reasonable amount of time we chanced it and unplugged the USB stick and found that it had in fact successfully generated our folder structure. There were folders for every type of hardware the Pi could emulate. This ranges from the Commodore 64 to the Nintendo 64. We then moved the ROMs that fell off the back of a truck into their appropriate folders.

Once we got the Pi connect to our home network, we were able to remotely add ROMs to the Pi using Samba-Shares. We connected to server smb://retropie/roms to access the ROM folder structure to add more games to the Pi.


This was a really fun and thoughtful project. There are a lot of games I need to catch up on that I never got to play. I have felt uncomfortable about a few newer games because they assume that you grew up playing Mario and Call of Duty and whatever else has been produced over the last thirty years. Sometimes going back to the beginning can help with figuring out how we got to where we are. I am incredibly excited to finally get to play Super Mario Brothers on my own Nintendo that I built myself.

I played Super Mario Brothers 3 for the first time ever. I didn’t get past the first level. It’s harder than it looks.

Welcome to Red Queen Game Development

Hi. My name is Janie Clayton. If you’re reading this post, you probably know me as Red Queen Coder. I have been blogging since 2013 and I have been speaking at conferences since 2014.

I started my initial blog, while I was still a student. My background was in journalism and writing, so for me creating a blog was a natural extension of my learning process. I wanted to write out the issues I was trying to figure out and how I was able to solve them. I had some concerns that it would expose my ignorance, but I hoped that by showing I could work through problems I would show that I was capable of learning and solving problems. I also wanted to give some hope and support to other people trying to learn programming that they were not alone and that they could accomplish what they wanted.

I have accomplished a respectable amount of success since those early days of the blog. If you told me five years ago that I would be the author of multiple books, spent a year building and programming robots, and was a member of Ray Wenderlich’s tutorial team, I would think you were crazy. The last five years have been extraordinary and I have had opportunities I didn’t imagine were possible back when I started

Sadly, I have somewhat neglected the blog over the last year. I spent a year fulfilling a dream of mine, which was to write a book on GPU programming targeted at people who didn’t study computer science in college. This book was incredibly challenging and really pushed me to my limits. I had to put a pin in a lot of my interests to focus every ounce of mental energy I had into that book. Sadly, one of the interests I put a pin in was my blog.

I had some mental health issues before and during the writing of the book, so my blog sort of veered away from programming and got more into mental health and self care advocacy.

Now that the book is completed, I have a lot of things I would like to write about in the tech field, but right now it doesn’t feel like these posts should go on I created that when I had the idea that programming was a large broad skill rather than an amalgam of dozens of dark corners and proprietary knowledge. Having a single blog for all of my tech interests doesn’t feel like the right path anymore.

So I have purchased a few domains for blogs that separate out my different technical interests. I will maintain for my personal blog posts, but I am moving my technical posts to this more segmented, targeted approach.

My Approach to Game Development

Over the last fifteen years I have learned a lot of skills that were incredibly unfamiliar to me. I got a video editing degree in 2007 because I had always been fascinated by video production. I never had access to any of the software or hardware, so it was something I didn’t know anything about when I started. I worked with people who had taken classes in school and bought equipment with money from high school jobs. It was incredibly intimidating to be surrounded by people who seemed so much further ahead than I was. But I was stubborn and didn’t want to give up. I learned video editing, but more importantly, I learned how to learn a weird skill.

The way you learn any skill is to start with some basics. Everything can be broken down into smaller pieces that are combined to create complexity with larger and more complex systems.

When I learned video production and Photoshop, there were books that started with some simple projects that get you familiar with the tools. Once you’re familiar with the tools, you delve into more complex and complicated projects. I have found that this is the best approach to learn anything.

I do not see a lot of that philosophy in programming or game development.

I have a lot of books on game development and I would say 90% of them are about tools. They explain how to use Unity or SpriteKit. Some of these are tutorial based where you work through a project. But I have found that I don’t learn game development well from these projects.

These projects are good at getting you familiar with an engine or a framework, but you finish and don’t really know how to proceed from there.

I have tried finding game programming books that take an iterative approach that I had with Photoshop, but I have thus far been unsuccessful in finding exactly what I am looking for.

A lot of books make a major leap in complexity. You start with tic-tac-toe and move on to World of Warcraft. There is also an implicit pressure that you’re supposed to know what you want to code as a game. You’re supposed to have some grand idea of a large, complex game like Mass Effect that you want to create. These ideas are always overly ambitious to learn on and a lot of people give up in frustration. There is the idea that if you’re not creating something innovative and Game of the Year worthy, then it’s not worth doing. I don’t think that’s the case.

I think that by recreating simple games, you can work through a lot of issues you will encounter in larger projects that you don’t think about. Saving a game, creating a leader board, designing a level… By focusing on doing these things for simple games like tic-tac-toe, you can become familiar with them by the time you get to the game you actually do want to program and design.

One thing I learned from learning programming is that in order to get good at programming you have to practice. Creating a bunch of crappy, throw away projects that do one thing really help you hone your skills in a lower stress environment. I know people in game development for whom they went all in financially on their first game. I want my learning experience with game development to be a fun hobby and not a major source of stress because if my game doesn’t sell a billion copies I will lose my house.

I also come from a weird background for game development. I didn’t have a video game system growing up. My only experience with video games was being at daycare watching my babysitter’s kids playing Super Mario Brothers because I wasn’t allowed to play. I played a few adventure games in school like “Day of the Tentacle” and “Myst” that were available on the Mac, but I didn’t own a gaming console until a few years ago. I know that I have a lot of history to catch up on for game development.

Part of me feels like this is an indulgence. Lots of people grew up wanting to be programmers because they wanted to create Mario Brothers. I wonder what I have to contribute to game development because I didn’t grow up wanting to make video games. I am back in the same position I was in with video production where I want to learn something simply because it interests me and I feel I am already behind everyone. This time there is not a laid out curriculum for someone like me, so I am designing my own.

The first year of this blog is going to be rather boring. I made a list of simple games that I want to create simply to learn the patterns and to get comfortable with game programming and design. I want to create these simple games with both Apple gaming technologies and Unity/Unreal.

When I started with Photoshop I had no idea what I wanted to create with it because I didn’t know what was possible. After immersing myself in it I came away with a lot of ideas about what I wanted to do. I am hoping by putting in some work to recreate games that I begin to see patterns that I can iterate on to do something unique.

I also work better with goal oriented objectives. I loved working on my book because before I wrote a word, I had an outline in place. I had no idea how to do 18 of the 20 chapters in the outline, so I focused on the two I could do. Then I figured out what looked the next easiest. I worked my way through the book that way. Having small iterative steps I could take that added up over time really helped me out a lot with my mental health. I felt I was accomplishing something. Even if I didn’t do much on any given day, getting something done helped me get closer and it added up over time. It also helped that I have a constrained scope where there was an actual “done” condition on the book. There was a finite number of chapters and topics to cover and once those were covered, the book was complete. One thing that frustrates me about programming is that nothing is ever done. One gets the illusion of things being done by creating discreet tasks and having sprints and declaring that sprint done once those tasks are complete.

I like having large projects to work on that are broken up into smaller tasks that I can focus on and complete. If you are not organized, you get overwhelmed quickly by things that you don’t need to focus on for a while. Anything can be accomplished if you just put one foot in front of the other and not worry about what you’re doing at Mile 25. By having some smaller projects that I control and can lay out all the requirements on, I am hoping to learn these organizational tactics by the time I find a larger project I want to do.

In Doctor Strange, The Ancient One asked Doctor Strange how he became a great surgeon. He said he became one through many hours of study and practice. With study and practice, anyone can learn anything. The purpose of this blog is for me to focus on my own study and practice so that I can gain a skill that interests me. Sometimes study and practice are boring to observe. Zen Buddhism focuses on the here and now. Instead of fantasizing about how things are going to be in a year, you focus on doing the best that you can with the present moment. Every task you do is important, even if it’s boring. By being mindful and treating every task with respect, it’s possible to learn faster and better. My hope is that the work I am doing in two years is better because I am going back and teaching myself fundamentals. I worry that people will judge me because I am planning to spend a few posts explaining how to code a tic-tac-toe game in SpriteKit. I have decided I don’t really care if people judge me or not. I am writing this blog for myself and my own learning style. There is no one way to learn. This way works for me.

Hopefully this blog will be of interest to people curious about game development. I would like to turn these posts into a book at some point. But for me the main purpose is to lay out goals for myself and have constrained projects to work on so I can practice and get better. I’m looking forward to learning new things. Thanks for joining me on this journey.