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.