Tic Tac Toe: Unit Tests

One of the biggest investments in time/money you have as a game designer goes into doing graphics and user interfaces. It’s important to check out the game logic before putting a bunch of UI into place. The UI is more difficult to debug than the game logic is, so it’s a good thing to make sure your game logic is solid and functional before trying to plug it into the UI. That eliminates a possible class of bugs and allows you to debug faster. The game logic should be independently testable without any user input. This is an ideal place to create unit tests.

Unit tests can be set up to check every single possible state of a function. Apple has a built in testing framework called XCTest. This framework allows boolean comparisons, value comparisons, and whether a function properly throws an error. There is a guide to writing good unit tests in Xcode here.

The reason I made all of these stand alone functions was because it would make them easier to unit test. Instead of having to create a View object and call these methods on those objects, I can just call functions and pass them state to test each condition within them.

I don’t want to repeat all of the code I already wrote that I am testing, so if you want to refer back to what I am testing, check out my previous post here.

Testing Reset Board

The smallest and easiest function to test is the function that creates the array that holds all of the tile state. This function has no parameters and returns one object that will consistently be the same no matter what.

Here is the test function for resetBoard():

func testResetBoard() {
	let accurateBoard:[TileState] = [TileState.notSelected,
	let testBoard = resetBoard()
	XCTAssertEqual(accurateBoard, testBoard)

The first variable of this test is to create an instance of what I expect the board to look like. I didn’t use a for loop to create the board because that is the code I am testing within my function. If I use the same code to create my test cases, then the tests will never fail, but the code still may not work the way I expect.

The next variable is generating a board using the resetBoard() function.

Finally, I am running an XCTest function to verify that the two variables are the same. XCTest has functions to assert equality and inequality. I am checking that they have the same capacity and hold the same data types. I ran the test and the test passed, so I know that my resetBoard() function will give me an array of nine TileState.notSelected instances.

Testing Switch Player

The switchPlayer function is slightly more involved than the resetBoard() function. The GameState enum contains three possible cases that need to be tested:

  • The current player is Player A
  • The current player is Player B
  • The game hasn’t started yet and no one is the current player.

Each of these cases will need to be tested to ensure that this function works properly. First, I want to create instances of Player A and Player B to plug into my tests. I could just create them within the function call, but I like to have labels for things:

func testSwitchPlayer() {
	// Player Objects
	let playerA = GameState.playerA
	let playerB = GameState.playerB

The first case I will test is what happens when Player A is the current player:

// Player A Case
let firstPlayerTest = switchPlayer(currentPlayer: playerA)
XCTAssertEqual(firstPlayerTest, playerB)

According to our function logic, if Player A is the current player, then switching the player should return an instance of Player B. Likewise, starting with Player B should return an instance of Player A:

// Player B Case
let secondPlayerTest = switchPlayer(currentPlayer: playerB)
XCTAssertEqual(secondPlayerTest, playerA)

The final test case is what happens where there is no current player. I determined in my logic that Player A would always start, so if we are switching the current player at the beginning of the game, Player A should always be the returned value:

	// Not Currently Playing Case
	let thirdPlayerTest = switchPlayer(
            currentPlayer: GameState.notPlaying)
	XCTAssertEqual(thirdPlayerTest, playerA)

Again, this test passes and I have verified each possible test case.

Testing Make Move

One reason I am testing these in order of complexity is so that I can use some of these tested methods within my future tests. For the makeMove() function, I need a lot of instances of a game board. I don’t want to have to type out all of these boards like a monkey, so being able to just generate a board using my resetBoard() function is very useful. I feel comfortable using that for this because I have tested it and verified it works.

First I want to create some reusable objects for setting up my assertions:

// Objects
let playerA = GameState.playerA
let playerB = GameState.playerB
let notPlaying = GameState.notPlaying

let selectedA = TileState.playerA
let selectedB = TileState.playerB
let blankBoard = resetBoard()

I have to create a .notPlaying test case even though I do not believe there will be a point in my code where it actually gets used. It is for the sake of safety and completeness that I include it and I need to test it to verify that it’s benign if it does ever wind up getting used.

First I want to check what happens if Player A makes a move:

// Player A move
let firstNewBoard = makeMove(tile: 0, currentPlayer: playerA, board: blankBoard)
XCTAssertNotEqual(blankBoard, firstNewBoard)
XCTAssertEqual(firstNewBoard[0], TileState.playerA)
XCTAssertEqual(firstNewBoard[5], blankBoard[5])

Since makeMove() returns a new array of TileState, our blankBoard is never mutated and can be used as a reference point against any board that is generated by makeMove(). Since I have generated a new board called firstNewBoard that should be different from blankBoard, I want to verify that they are in fact different. I also want to verify that the item I mutated in the function call actually changed to what I expect. Finally, I want to verify that nothing else changed. I didn’t write a test case for every element, so I chose one to test. I feel this is good enough and I don’t really want to write a billion tests around this when I feel reasonably sure this works as it should with a random sample. Next, I want to do the same using Player B:

// Player B move
let secondNewBoard = makeMove(tile: 2, currentPlayer: playerB, board: blankBoard)
XCTAssertNotEqual(blankBoard, secondNewBoard)
XCTAssertEqual(secondNewBoard[2], TileState.playerB)
XCTAssertEqual(secondNewBoard[8], blankBoard[8])

This code looks substantially similar to the Player A code, but I did want to change the tiles with the moves and the random check just so I wouldn’t accidentally have an edge case that happened to pass my tests. I have done this before and it makes you feel rather silly.

So far I have tested both Player A and Player B with a blank board. I would like to now write a few tests that simulate an actual game to verify that this works out of isolation:

// Moves by both Player A and Player B
let firstMove = makeMove(tile: 4, currentPlayer: playerA, board: blankBoard)
let secondMove = makeMove(tile: 0, currentPlayer: playerB, board: firstMove)
let thirdMove = makeMove(tile: 2, currentPlayer: playerA, board: secondMove)
XCTAssertNotEqual(firstMove, blankBoard)
XCTAssertNotEqual(secondMove, firstMove)
XCTAssertNotEqual(thirdMove, secondMove)
XCTAssertEqual(thirdMove[4], selectedA)
XCTAssertEqual(thirdMove[0], selectedB)
XCTAssertEqual(thirdMove[2], selectedA)

I simulated a game through the first three moves. I used the previous move’s result as the parameter for the next move’s function. The tests I wrote were to verify that the board does in fact change after each method call. I am also running tests on the final board to verify that a move made in the first board continues to be passed down through each successive move.

Finally I am adding my sanity check that if I am passing in a not playing state that the board does not change:

	// Not Playing move
	let notSelectedBoard = makeMove(tile: 5, currentPlayer: notPlaying, board: blankBoard)
	XCTAssertEqual(notSelectedBoard, blankBoard)

I am not testing this case as rigorously because I don’t anticipate it ever happening. Also, if it does, it shouldn’t really change much of anything.

This test also passed without issue. (Note: I am writing this blog post and my tests in parallel. Had something failed, I would have left the previous code as is and would include the test failure and explain why. These tests have been passing because the functions were designed very simply, making it easier to write good test cases, which was kind of the point going in.)

Test Win Game

I’m finally testing my monster function that includes all the various ways a turn can end. I am sure everyone is thrilled about reading two thousand words on doing repetitive unit testing logic, so I broke my tests up on this method to allow me to explain them without repeating myself a billion times.

First I will check for the diagonal win conditions, mainly because there are only two of them and that gives you the general idea about how the rest of the tests would be set up for vertical and horizontal wins. Again, I start with my game objects:

// Objects
let playerA = GameState.playerA
let playerB = GameState.playerB
let playerAWin = GameEndState.playerAWin
let playerBWin = GameEndState.playerBWin
let blankBoard = resetBoard()

The checkForWin() function returns an optional game end state. It’s optional because it’s possible that there are still moves to be make and no one has won yet. Since I am checking for wins here, I made objects for win conditions. When I test for other conditions I will create different objects.

Here are my tests for an upper left diagonal win:

// Check upper left win
let upperLeft1 = makeMove(tile: 0, currentPlayer: playerA, board: blankBoard)
let upperLeft2 = makeMove(tile: 4, currentPlayer: playerA, board: upperLeft1)
let upperLeft3 = makeMove(tile: 8, currentPlayer: playerA, board: upperLeft2)
let checkForUpperLeftWin = checkForWin(currentPlayer: playerA, board: upperLeft3)
let notAWinYetUpperLeft = checkForWin(currentPlayer: playerA, board: upperLeft2)
let wrongPlayerUpperLeft = checkForWin(currentPlayer: playerB, board: upperLeft3)
XCTAssertEqual(checkForUpperLeftWin, playerAWin)

I generated a not quite accurate game board by simply giving Player A a win without letting Player B have any turns because I am a bad person. I look at this data and see a few places we can test to verify that this code works. We test the actual win condition to ensure that a win is returned. I also tested the move before the win to verify that the GameEndState returns nil. Finally, we are checking whether the current player has won or not, not if a win exists on the board. Even though there should be a win on the board, it is not for Player B, so this should come back nil as well.

I did the same code pretty much for the upper right win case and ran the test. It passed, so now I am moving on to testing for a draw.

A draw uses some different cases from our state objects than a win, so I need to create some new object instances:

// Objects
let playerA = GameState.playerA
let draw = GameEndState.draw
let selectedA = TileState.playerA
let selectedB = TileState.playerB
let notSelected = TileState.notSelected

Since I don’t really care about checking for wins, I just created one player instance for game state, but more importantly I included the draw state that I didn’t include in the last batch of tests. I created instances of tile state so that I could easily construct boards to test for various conditions:

// Boards
let drawBoard:[TileState] = [selectedA, selectedA, selectedB,
			     selectedB, selectedA, selectedB,
			     selectedA, selectedB, selectedB]
let blankBoard = resetBoard()
let nonBlankBoard:[TileState] = [notSelected, notSelected, notSelected,
				 notSelected, selectedA, notSelected,
				 notSelected, notSelected, notSelected]

(Trying to purposely construct a non-winning draw board is kind of a pain in the butt!)

I want to test three different scenarios:

  • There is a draw
  • The game has just begun
  • There has only been one move

One cardinal rule of unit testing is to test for failure conditions. In this context, anything where the game should continue is a failure condition. I am not checking with a win here because I am already checking for that in my other unit tests.

Here are my final tests to verify my draw condition works:

// Test variables and assertions
let drawCondition = checkForWin(currentPlayer: playerA, board: drawBoard)
let startGame = checkForWin(currentPlayer: playerA, board: blankBoard)
let firstMove = checkForWin(currentPlayer: playerA, board: nonBlankBoard)
XCTAssertEqual(drawCondition, draw)

The draw tests also passed. I originally was going to test to ensure that the game continues if there isn’t a draw or a win, but that functionality is already being covered in both of those unit tests, so I don’t feel I need to create an entire function around it.

Ensuring Code Coverage

I’ve written what seems like an excessive number of unit tests, but how do I know I actually covered every failure case?

Starting in Xcode 7, Apple introduced a code coverage feature that is able to generate a report telling you how much of your code base is being touched by unit tests.

To enable this feature, you need to edit your target scheme:

Next, choose the option in Debug to enable code coverage data to be gathered:

Be sure to show the test bundle and check the code covered by the test bundle rather than the one that shows up by default. In this screenshot you see that the top bundle shows 0% test coverage of the State Utils class when that is basically the only thing being tested so far in the application.


The sample code so far for this project can be found here.

I know this wasn’t the most exciting post in the world, but there are a few take aways from this. One reason these tests were so easy to write was because I designed the code to be easy to test. How many of us have gone to work on a legacy code project that is impossible to update because there are vast multitudes of side effects and something completely unrelated to your feature breaks because of unnecessary dependencies?

I had some concerns about my very large function checking for win conditions and how I feel comfortable that my conditional logic will work as I intend. When I begin plugging this into the UI, if something isn’t working properly I will know that it’s an issue with the UI code and not with my game logic.

Speaking of UI, my next few posts will revolve around setting up the user interface and the interactive components of my game. I will be treating these separate from my game logic and as self contained units of functionality. Stay tuned!

Tic Tac Toe: Rules and Conditional Logic

The next bit that I am doing in my Tic Tac Toe game is putting in place the game rules and conditional logic around the actual game mechanics. I am saving the UI code for another time because that will be far more intensive than laying out the rules.

One of my goals with my code is to make it completely testable. One way of doing that is to create stand alone functions that can be tested outside of the game scene. Rather than creating a large nest of mutating side effects, I would like to take in parameters and return parameters, thus keeping all of my changes safely within a testable function. This will likely go through some refactoring in the future as I think about the best way of doing things. I know when I tried this before I had a lot of people yelling at me about the way I chose to write my code. It’s my code and my codebase, so I will write it however I please.

Board Properties

Tic Tac Toe is a fairly simple game. It is a board of nine squares. It has two players. On each player’s turn, they choose a square that has not been chosen yet. If there are three squares in a row, that player wins. If there are not, then the next player goes. This continues until either someone wins or all of the squares have been chosen.

This means that we need to have some kind of structure to represent the board state and we need to keep track of the current player:

var board:[TileState] = []
var currentPlayer:GameState = .notPlaying

I’m opting to use an array of tiles to represent the tile state. If this were a more complex board I would opt to do a different data structure and lay out actual rows and columns. However, since there are only nine tiles to keep track of and I am planning to number them when I set up the UI, I am opting for the more simple route and hard coding my logic. I know this is making people pull their hair out and scream, but I want to try and keep things simple. The rules haven’t changed in however many years this has existed, so the likelihood I will need to update requirements is minimal. I may change my mind, but that is for refactoring, not prototyping.

I also need to have a mutating variable to track the state of who is the current player. Since the game begins without a current player, the state is initialized as .notPlaying.

Setting Up the Board

The board is represented by a set of nine tiles. These tiles will be selected by the two different players, but not initially. When the board is initially laid out, it will be completely unselected. This can be represented by a function:

func resetBoard() -> [TileState] {
	var board = [TileState]()
	for _ in 0...8 {
		let tile = TileState.notSelected
	return board

This function returns an array of nine tiles that are all in the unselected state. These can be accessed by their index, which is how I will make moves and how I will check for wins.

Switch Players

When I was going to school for programming, my teacher told us that if you are describing what a function does and you have to use the word “and,” then you need another function. Each function should do one and only one thing. These functions can call other functions that take care of that functionality for you, but a function should be an encapsulated piece of code that does one thing.

In that spirit, I am adding a function to switch the current player:

func switchPlayer(currentPlayer: GameState) -> GameState {
	switch currentPlayer {
	case .playerA:
		return GameState.playerB
	case .playerB:
		return GameState.playerA
	case .notPlaying:
		return GameState.playerA

I am making the determination in this game that Player A always goes first. You can do Rock Paper Scissors Lizard Spock to determine which player is Player A, but within my game logic Player A always goes first. In my exhaustive switch statement, I am checking to see what the current game state is. If the current player is Player A, then it is now Player B’s turn. If the current player is Player B, then it’s Player A’s turn. If this is the beginning of the game and the current state is Not Playing, then by default it will be Player A’s turn because Player A always goes first.

Making a Move

Beyond the UI, what goes into making a move? Making a move means selecting one tile within the array of tiles and changing its state to reflect which player you are. To keep this functional, you need to take in a board state, a current player state, and the index of the tile whose state needs to change. You then return a brand new board state based on the changes taken in by the function:

func makeMove(tile: Int, currentPlayer: GameState, board: [TileState]) -> [TileState] {
	var newBoard = board
	switch currentPlayer {
	case .playerA:
		newBoard[tile] = .playerA
	case .playerB:
		newBoard[tile] = .playerB
	case .notPlaying:
		newBoard[tile] = .notSelected
	return newBoard

I do not believe that the final .notPlaying state will ever be called, but to ensure an exhaustive switch statement and to make sure the application doesn’t crash, it seemed logical to just include that as a case. It would not impact the game in any way to just keep the tile unselected in case something goes off the rails.

Checking for a Win

The final stand alone function I want to create is the function that checks for a win. As anyone over the age of six can tell you, most Tic Tac Toe games end in a draw. So when checking for a win, you must also consider the possibility there are simply no more moves to be made and the game ends unceremoniously.

To this end, we need another state enum to check for ending the game:

enum GameEndState {
	case playerAWin
	case playerBWin
	case draw

The game can end in one of three states:

  • Player A wins
  • Player B wins
  • Stalemate

To check for a win, you need to know the current player and the current state of the board. Since it’s possible that the game hasn’t entered one of these states yet, you need to make the return type optional:

func checkForWin(currentPlayer: GameState, board: [TileState]) -> GameEndState? {
	var requiredState:TileState
	var gameEnd:GameEndState
	if currentPlayer == .playerA {
		requiredState = .playerA
		gameEnd = .playerAWin
	} else if currentPlayer == .playerB {
		requiredState = .playerB
		gameEnd = .playerBWin
	} else {
		return nil

In order to satisfy the compiler’s type safety, you need to create a conversion between the current player being passed in and the states you are checking. You can’t just compare the board’s TileState directly against the current player because they are of different types even though their members have the same name.

There are eight possible win states in a game of Tic Tac Toe:

  • Three across the top
  • Three across the middle
  • Three across the bottom
  • Three down the left
  • Three down the middle
  • Three down the right
  • Three diagonally from the upper left
  • Three diagonally from the upper right

I am checking each of these based on the index of the position in the array of tiles. If you count the tiles starting from the upper left and continuing to the right and down, they have a predictable index. The upper left tile is represented as index 0 and the lower right tile is represented by index 8. We can use the indices to check for the various win conditions. Let’s start with the across win checks.

	// Three across the top
	if board[0] == requiredState && board[1] == requiredState && board[2] == requiredState {
		return gameEnd
	// Three across the middle
	if board[3] == requiredState && board[4] == requiredState && board[5] == requiredState {
		return gameEnd
	// Three across the bottom
	if board[6] == requiredState && board[7] == requiredState && board[8] == requiredState {
		return gameEnd

These checks are checking for contiguous tiles that all match the current player state. If any of these conditions are satisfied, the current player wins the game and the rest of the logic is never executed as it’s unnecessary. Next, we do something similar with the vertical win conditions.

	// Three down the left
	if board[0] == requiredState && board[3] == requiredState && board[6] == requiredState {
		return gameEnd
	// Three down the middle
	if board[1] == requiredState && board[4] == requiredState && board[7] == requiredState {
		return gameEnd
	// Three down the right
	if board[2] == requiredState && board[5] == requiredState && board[8] == requiredState {
		return gameEnd

These are slightly more complicated as the indices are not contiguous. I made a diagram of the correlating tiles to ensure that my hard coded values were correct. Yes, I know hard coded values are evil. Bite me.

Finally, we check for the two diagonal win conditions.

	// Three diagonally from the upper left
	if board[0] == requiredState && board[4] == requiredState && board[8] == requiredState {
		return gameEnd
	// Three diagonally from the upper right
	if board[2] == requiredState && board[4] == requiredState && board[6] == requiredState {
		return gameEnd

If none of these win conditions have been satisfied, that means that the board is in one of two states. Either we are still playing and the game should continue, or there are no more moves to be made an no one can win. The easiest way to check for a continuing game is to check if there are any unselected tiles still on the board:

	// Draw
	for tile in board {
		if tile == .notSelected {
			return nil
	gameEnd = .draw
	return gameEnd

If there is even one tile that isn’t selected, the game continues. By making the game end state optional, we are allowing a scenario where you return nil if the game is not in fact at its end state.

If you have exhausted all of these options, where there isn’t a win state and there are no more tiles to be selected, then the game has concluded in a draw. You set the game end state to a draw and return that at the very end if there has not been any scenario where the method can end differently.

By far the largest and most involved function I have in this application is the checking for win function. I am not super happy with how long this turned out, but for the time being I can’t really think of a better way of doing this. There is a lot of conditional logic in here that is specific to the game, so there is going to be a lot of code, I just don’t know if there should be this much. I will ponder in the future if there are ways of cutting down on this.


You can access the current version of the code here.

This isn’t necessarily the way someone else would set up their application, but there isn’t a right or a wrong way to do anything. There are matters of personal preference. There is probably a way to make this code less complex, which I hope to figure out later. One thing that frustrates me about talking to other people about code is this idea that code is written in stone and can never be changed. This isn’t the case at all.

It’s better to just get something done and to refactor it later. Otherwise, you stare at a screen and nothing gets done. When I worked for Brad Larson on our rewrite of his robotics software, he regularly refactored his code. He would notice he was doing something over and over again and that it could be pulled out as a stand alone function. The process of writing the code base informed his refactoring decisions.

You can’t just go into a code base knowing all the challenges you will encounter. You learn that by working with it. My code will probably look significantly different than this when it’s done because I will figure out better ways of doing things and I will refactor the code base. This is how you should be approaching your code.

So this is all well and good to have these disparate stand alone functions, but how can we tell if they actually work or not? In my next blog post, I will set up unit tests to prove that these work as designed.

Augmented Reality: ARKit and SceneKit

One of the most exciting new frameworks announced at WWDC 2017 was ARKit. Virtual reality has been fairly hot the last few years, but in my opinion augmented reality has a better future. Both are garnering a lot of attention so I am writing this post about what augmented reality is and the easiest way to natively integrate it into your applications.

What is Augmented Reality?

Virtual reality is the creation of a totally immersive experience. Think of the holodeck from Star Trek. The characters enter a room and the computer creates a completely immersive simulation. The characters can explore cities and planets or go back in time. Like the TARDIS, the holodeck seems bigger on the inside. It theoretically is indistinguishable from the real world.

Stepping back in time virtually.

Augmented reality is different. Augmented reality doesn’t seek to immerse you in another world, but rather exists to add to the world around you. The best known example of this is Pokemon Go. Pokemon Go overlays Pokemon characters within the real world to emulate the experience of being a Pokemon trainer and going out to capture Pokemon. This allows players to experience what it would be like to live within the game.

This distinction is one reason I feel AR has a brighter future than VR. One reason that people got into Harry Potter is partially embedded in the idea that this is a hidden aspect of the real world. It’s the idea that somewhere in London you can find a hidden neighborhood where you can buy magic wands or that you could receive an acceptance letter to Hogwarts. It’s a distinction between total escapism and having the idea that there is magic hidden within the real world.

Augmented reality was possible on the iPhone before ARKit was introduced. I found a book on how to implement AR going back to iOS 5. Pokemon Go predates ARKit. What ARKit does is wrap a lot of complexity within a few easy abstracted methods and classes.

Augmented reality requires three different functionalities:

  • Tracking
  • Registration
  • Visualization

Tracking is the ability of the application to detect surfaces and know what objects exist in space. In Pokemon Go, tracking is used to ensure a Pokemon appears on a road or sidewalk as opposed to inside of a tree.

Registration catalogs and keeps track of areas and objects of interest. In the Pokemon Go example, registration is used to keep track of which Pokemon exist in the area and where those Pokemon are supposed to appear. If you move your phone away from the Pokemon and then come back to it, the Pokemon should still be there, unless someone else captured it.

Visualization encompasses everything that you see in the scene. This is where the Pokemon’s mesh is loaded, shaded, and rendered. This is the main point in the process that people are most aware of because it’s the thing they see directly.

What Does ARKit Do For You?

ARKit is not a very large framework. It has fewer than ten classes and those classes do not have a lot of methods in them. The reason for this is that ARKit only handles two of the three requirements for augmented reality: Tracking and registration.

Tracking and registration are pretty straightforward conceptually without a lot of special modifications. Nothing about these tasks are going to fundamentally change very much between applications. An AR measuring tape is going to function the same way in respect to these tasks as a game or a portal to another dimension. That makes it a prime candidate for a Cocoa framework. It wraps a lot of boilerplate code in some friendly and approachable Swift code.

This small framework is deceptive in how much it actually does. The vast amounts of machine vision being done under the hood is astonishing. If you were responsible for setting up the real time video analysis and image filtering for object detection on your own, it would take a research team and five years.

What ARKit Doesn’t Do For You

ARKit does not handle the most visible step in the process, which is visualization. Just knowing the ten or so classes in ARKit doesn’t really get you a working augmented reality application. This is similar to learning CoreML. Both of these frameworks wrap a bunch of boilerplate code around a complex but relatively similar pipeline so that you don’t have to worry about the ins and outs of how the camera is capturing frames. You just have to worry about telling it what to do once the frame is captured.

ARKit in a Nutshell

I mentioned earlier in this post that ARKit isn’t a very large framework. There are only three broad categories of object you need to be familiar with. Within these three categories are three classes, so about nine classes total.

ARKit Foundational Structures

The first category of object are what I call ARKit’s foundational structures. These are objects that manage ARKit in your application and talk to other things on your behalf.

These classes are:

  • ARSession
  • ARConfiguration
  • ARSCNView/ARSKView

If you’ve done any work with AVFoundation, you should be familiar with sessions. ARSession is a shared object that manages the camera and motion processing needed for augmented reality experiences. You can’t have an AR application without an ARSession. It’s the project manager of the AR functionality.

ARConfiguration is an abstract base class that has a few different subclasses depending upon what you need from your application. ARWorldTrackingConfiguration is the most comprehensive and highest quality tracking configuration. It allows plane detection and hit testing. Not all devices support world tracking. For those devices you need to offer AROrientationTrackingConfiguration, a more limited configuration. Finally, If you’re only working with facial data, you would use ARFaceTrackingConfiguration.

The final set of classes are the views. Both ARSCNView and ARSKView inherit from their respective 2D or 3D frameworks. They are subclassed to respond to ARKit events like hit testing. You will need to create an instance of the ARSCNView at the top of your class:

var sceneView: ARSCNView!

If you create your application from the Augmented Reality template it will automatically configure the session for you:

override func viewWillAppear(_ animated: Bool) {
	// Create a session configuration
	let configuration = ARWorldTrackingConfiguration()

	// Run the view's session

The session has to be set to both run and pause. The pause is set when the view disappears:

override func viewWillDisappear(_ animated: Bool) {
	// Pause the view's session

Now that a session is in place, you need to add some ARKit objects.

ARKit Real World Representations

In order to place virtual objects in the real world, you need a way to understand where in three dimensional space the object should be rendered. Our eyes and brains recognize objects and can remember where books and pictures are when we leave the room. The program has to be able to do the same thing. There are three main objects ARKit uses to analyze the world and persist objects:

  • ARAnchor
  • ARPlaneAnchor
  • ARHitTest

ARAnchor instances represent real points in space. They are used for placing objects in the augmented reality scene. If you wanted to place a virtual pug in the middle of a rug, you would create an anchor in space to tell the renderer where to draw the pug. ARPlaneAnchor is similar but deals exclusively with flat surfaces.

ARHitTest instances are information about a real-world surface found by examining a point in the device camera view of an AR session. These include:

  • Feature Points
  • Estimated Horizon Plane
  • Existing Plane

If you want more information about these types, you can access it here.

Camera and AVFoundation Wrappers

One difficult thing in iOS development is pulling camera frames from the camera and doing something with them. If you’ve ever mucked around with AVFoundation, you know what a pain in the neck it is. A lot of classes are incredibly long and have very similar names. ARKit takes these tasks and abstracts them away from you so you don’t have to worry about them. These classes are:

  • ARFrame
  • ARCamera
  • ARLightEstimate

The ARFrame is a video image and position tracking information captured as part of an AR session. Properties you can muck around with on this object include the depth data and the time stamp. The captured image is a CVPixelBuffer which allows you to process this as you would a frame of video (because that’s exactly what it is).

The ARCamera contains information about the camera position and imaging characteristics for a captured video frame in an AR session. This includes the tracking state and the orientation of the camera. You also have access to the camera geometry, which allows you to perform matrix transforms.

Finally, the ARLightEstimate estimates scene lighting information associated with a captured video frame in an AR session. This primarily involves the intensity and color temperature. You can use these to incorporate into your lighting shaders to get the virtual objects to match the ambient lighting in the scene.

By this point, you’ve basically covered everything you need to understand about ARKit, but you still don’t see anything on the screen. From this point, you will need to work with a renderer.

ARKit with SceneKit as the Renderer

ARKit has several options for both native and non-native renderers for ARKit. Both Unity and Unreal plug into ARKit, allowing you to harness the power of those game engines to do some truly astonishing things. Alternately, you can use the native SpriteKit and SceneKit frameworks to do some cool stuff as well. SpriteKit as a renderer is somewhat limited, so for the rest of this post I will be creating the simplest SceneKit integration with ARKit that I can, which is to create a box that is anchored in space.

I used
Mohammad Azam’s
Udemy ARKit course as a basis for this sample project. I highly recommend the rest of his course if you want to get more in depth with ARKit.

Augmented Reality has its own template. It isn’t under Games.

The following code is the only code I had to add to this project. Everything else was already set up by the template. The template provides a scene already, but I want to render a box rather than the built in ship asset:

// Create a new scene
let scene = SCNScene()
let box = SCNBox(width: 0.2, height: 0.2, length: 0.2, chamferRadius: 0)

SceneKit has a large library of built in primitive objects. It has a surprising amount of built in functionality that allows you to make a lot of progress fairly quickly.

The box requires some surface customization. The surface texture and color is determined by it’s material property. This material can be an image that is mapped onto its surface, a color, and a degree of shininess. There is a lot of customization you can do to an object’s material property, but for our purposes we’re just making it purple for now:

let material = SCNMaterial()
material.diffuse.contents = UIColor.purple

We have created a box and a material, but these variables are not yet associated with one another. These are going to be properties of a SceneKit object called an SCNNode. SceneKit, like SpriteKit, is completely composed of graphs of nodes. If you want something to appear on the screen, you need to set properties on it and add it to a node:

let node = SCNNode()
node.geometry = box
node.geometry?.materials = [material]
node.position = SCNVector3(0, 0.1, -0.5)		

Finally, you need to commit the scene to the view:

// Set the scene to the view
sceneView.scene = scene

This isn’t much, but it’s pretty impressive for fewer than twenty lines of code. Having spent a hundred lines of code trying to render triangles with no lighting to the screen, this is magical voodoo to me.

Current ARKit Limitations

ARKit impressed me with the degree of simplicity it was able to accomplish for the boilerplate operations around capturing frames. Like most Apple frameworks in their initial release, ARKit does have a few weak points that should be improved over time. These primarily include:

  • Bad Lighting
  • Excessive Motion
  • Limited Features

If you don’t have good lighting, it’s difficult for ARKit to pick out features in a dark room. Similarly, it’s difficult for the camera to keep track of points in space if you’re waving the camera around a lot. It’s using machine vision algorithms that don’t do well with motion blur. Additionally, as you run your ARKit application, the program will keep analyzing the scene and the points may change over time.

Currently, the only objects that ARKit works well with are flat surfaces and horizontal planes. The framework isn’t equipped to recognize three dimensional objects. You can’t create a virtual cat that will recognize a chair in a scene and hop onto it. It would recognize many flat surfaces and may wind up on a table or the TV. This may be closer to how cats behave in real life, but you probably want a little more control over your virtual cats.

Final Thoughts

You can access the sample code for this blog post here. I intend to add to this repository over time.

If you’re serious about working with augmented reality, I strongly suggest learning a rendering engine like SceneKit or Unity.

For me, the limiting factor in ARKit is the same one I have for SpriteKit and SceneKit. Programmatically you can do a lot of cool stuff, but unless you have access to diverse and well done graphical assets, what you can do on your own is pretty limited. SceneKit compensates with its primitive library, but if I want to create a game about pugs I need to either find an artist to create those assets for me or I have to learn how to create them myself.

A lot of people are interested in AR for real world applications, like medical imaging. Myself, I am interested in using it to create immersive real world experiences that you can’t get any other way. I feel that this could be used as a tool for engagement. Rather than staring at our phones while blocking out the world around us, we can use them as a way to more deeply explore the world outside our devices.

Tic Tac Toe: Game State Setup

One concept that I find interesting about game development is the concept of state. When I first got interested in OpenGL, someone told me that OpenGL is simply a “state machine.” I didn’t really grasp what he meant by that, so it’s something I wanted to make sure I had a good handle on by working through these projects.

It’s a concept that I am sure is fairly straightforward but I have never heard it explained super well. Basically, in games there are aspects of the game that change. A simple example of state is if you’re playing a multiplayer game. It can only be one player’s turn at a time. That means that if you are programming a game where people take turns, you need a way to keep track of whose turn it is at any given point in time. That is your state. Additionally, it’s possible that it’s no one’s turn if the game is over. You don’t want someone to take a turn when the game has concluded. So your game has a few different states it can be at at any given point in time.

Since tic tac toe is a two-player game, I need a way to track which player is the current active player. I also need a way to indicate is the game is in a state where no one is the active player. Back in the dark ages (pre-Swift), there wasn’t a good way of tracking state, so Apple introduced GKState in their GameplayKit framework. This allowed you to build state machines to track state in your game. However, with the advent of more powerful Swift enums, it’s far simpler to just create an enum to contain and switch your state.

Creating state machines in Swift is easy and powerful. Enums are an “or” type, which means that a Swift enum can only have one and only one value at a time. Which means if you need to keep track of state, they work very well. Let’s look at the example of keeping track of the current state of the game. We’ve already determined that the game can have three different states:

  • No Game Active
  • Player A’s Turn
  • Player B’s Turn

These conditions can be directly mapped to an enum:

enum GameState {
    case notPlaying
    case playerA
    case playerB

This enum is named GameState, making it easy to remember what it is tracking. You can initialize this game state as a variable in your main program:

var currentPlayer:GameState = .NotPlaying

You initialize currentPlayer as not playing because this is the default state you will find yourself in until you initialize a game. Once a game begins, the currentPlayer state will change to either currentPlayer.PlayerA or currentPlayer.PlayerB. There will never be a situation where this state is blank or where there will be more than one valid case. It is exclusive.

The only other state I have to track in this simple game involves the state that any individual tile is in. The tiles can have three possible states:

  • Not Selected
  • Player A’s Tile
  • Player B’s Tile

This again maps very easily to an enum:

enum TileState {
    case notSelected
    case playerA
    case playerB

This takes care of all of the state I need in the game. It isn’t much, but it’s a solid start to the foundation of our game. Most of the non-UI code I need will revolve around checking and transitioning this state. You can check the code so far here. Next, I need to set up the conditional logic and rules of the game.

Game Dev Journal: Project 1 Planning Session

Begin at the beginning and go on till you come to the end; then stop.
– Lewis Carroll

My friend Brian Hogan wrote a book a few years ago called Exercises for Programmers. The gist of the book is that it gives you a list of simple exercises that get progressively harder that can be done in about an hour. One doesn’t get better at anything without targeted practice and one way to practice is to work on solving a simple problem, but doing that consistently every single day.

Many of his challenges can be done simply in a few minutes, but you can add complexity to them, especially with iOS. If you write unit tests around your solution and create a UI for them that requires AutoLayout, you add significant complexity to the challenge. This also treats the challenge as you would a project you would create in the real world. Instead of just getting practice with simple conditional logic in something like Swift, you are getting practice working with Apple’s tools and aspects of the UI that you will only create once in a real project that may take a year to ship.

I am taking this approach with my first foray into games. The simplest game I can think of to create is tic-tac-toe. I worked through a C Plus Plus book that implements tic-tac-toe as one of the first projects and does so in about a hundred lines of code. If you’re just trying to get something done as fast as possible, then this isn’t really the best learning project.

However, I want to treat this like it’s an actual game I would ship. I want decent graphics. I want an interactive UI. I want different game scenes. There is a lot to learn to make this look like a real game. All of these nice peripheral things are features I want to include in actual apps I want to ship. By learning them on this throw away project, I should be able to develop this faster for future projects.

When learning something new, it’s important to simplify things as much as you possibly can. Constraining the number of new things you have to learn is vital if you want to make any progress. If you can narrow 50 things down to five and build on from there, by the time you get to the last ten things, you should have a solid foundation built upon repetition.

In that spirit, I have broken down creating this as a serious project into a series of achievable tasks that I intend to blog about over the next few weeks:

  • The Game Logic: The backbone of this project is setting up all the conditional game logic. This includes checking for a win and switching players. I want to write this functionally so that every aspect of the game logic can be tested.
  • The UI: In tic-tac-toe, you have nine squares that can be selected. I need to find a way to set these squares up and have them respond to user interaction. I also have to determine how to disable interaction once a square has been chosen. I also want to create animations to make the game feel more natural and responsive.
  • Game Scenes: One aspect of modern games is the idea that you have more than one game scene. You start on a main menu. You can look at a leader board. There is another scene once the game is over and you win or lose. I would like to set this up as a “real” game with all of these transitions.
  • Game AI: I want you to be able to play by yourself, so it’s necessary to program an AI to play against. This takes advantage of Apple’s Gamplay AI framework.
  • Game Actions: One thing that confounded me about SpriteKit was trying to figure out if you could use Core Animation with it. I recently discovered that much of Core Animation has been adopted as the SKActions framework. I want to animate the sprites that represent the squares in some way and this promises to make that an interesting challenge.
  • Graphics and Sounds: Even though this isn’t going to be a particularly complex game, I would like to use nice graphics and sound effects for it. Since there are a limited number of elements, this gives a good intro to thinking about what one needs to make a game look polished and not like developer art. For better or for worse, graphics are the thing people notice and it’s important to find ways to differentiate yourself from everyone else. I also studied audio engineering and understanding how to put together a unique soundtrack quickly can be a valuable skill.

I’m going to use SpriteKit for this project. My goal by the end of the year is to ship a game to the App Store in SpriteKit, so this is practice for the game I want to ship. I don’t know how many prototype games I should do in SpriteKit, but I do want to work through at least one. I know SpriteKit isn’t cross platform, but I don’t really want to deal with figuring out how to ship to another platform. I want to get more comfortable with shipping through iTunes Connect and with Swift, so it makes more sense for me personally to do this is SpriteKit instead of something like Unity. I want to get to Unity/Unreal later this year (or earlier if I am bored and want to procrastinate).

My goal over the next few weeks is to make steady progress on this project. I plan to post at least one blog post a week for this entire year. I am doing this as a nights and weekend project, so it could take a while to finish. The goal isn’t speed so much as consistency. I know that it’s important to have deadlines or else you don’t ship anything, but deadlines cause me severe amounts of anxiety. I have goals about how long I want this to take, but life happens and I don’t want to assume this can be done over a weekend if it will actually take me a month because I don’t know what I am doing.

Again, the point of this project isn’t to build a tic-tac-toe game. The purpose is to use a simple problem as a foundation for figuring out design patterns in the most straightforward way possible. This may feel like overkill for something that isn’t particularly interesting, but I think practicing on this will make the next game easier. I also believe there are probably things in this process that I don’t know I need to do until I do it, so I want to uncover all the bodies before I start on a project I care about.

Goals for 2018

I find that making goals for myself helps me stay focused on what is important. If you don’t have a plan about what you want to accomplish, then you don’t really go anywhere.

One goal I have had for a few years was to publish my first app to the App Store. Every time I think I have some time to work on this goal, life gets in the way. I got an amazing job a few years ago that was stimulating but mentally exhausting, leaving me no mental energy to work on anything else. I took another job that gave me a nervous breakdown. I went through a divorce. I spent a year writing a book.

Each year the amount of complexity and polish required to publish an app increases. I always feel like everything is six months out of reach. By the time I finish an app, it will require another six months of work to be viable. Part of this was because I was a beginner. When everything is new, it takes longer. Once you understand the fundamentals and they become intuitive, then development speed increases dramatically.

While I was finishing up the book, I tried to do some research into game development because I wanted to hit the ground running when it was over. I wanted to get the long hard work of just learning the patterns and frameworks out of the way so that when I did sit down to write a game it would be easier.

I want to publish a game this year. I am tired of putting this goal off indefinitely because I keep getting offers to do other things. I don’t regret doing those other things, but I worry if I don’t make this a priority I will never do it.

Along with my goal to publish a game is to learn both Unity and Unreal. I know that these engines take a while to master, but I have seen many examples of people becoming proficient in them in as little as a month. I would like to have a better understanding of where people who use these engines are coming from. One impediment I had in learning graphics was a lack of familiarity with concepts like texture mapping and object imports. I think that having a better understanding of engines will be quite useful moving forward.

Another goal I have for 2018 is to do more work with graphics. I spent a year working on a graphics book, but I don’t feel I got to delve into it as deeply as I wanted to. Graphics is a complex topic. I feel like I finally established a foundation of my understanding that I can build off of. I worry if I don’t practice my new found knowledge that I will lose and forget it.

I’m very grateful to have a job that affords me enough time to pursue my passion projects while also being able to cover my bills. I am also incredibly grateful for my supportive boyfriend who wants to see me succeed with my special interests. Having been in a relationship with someone who actively discouraged my interests and interfered with my work, I know the value of having a supportive partner in crime. After a few years of instability, I am hoping that 2018 proves to be relatively quiet.

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, RedQueenCoder.com 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 RedQueenCoder.com.

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 RedQueenCoder.com. 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 RedQueenCoder.com 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.