Game Development Journal 3: Learning to Embrace Higher Level Abstractions

For the last few months I have been working on a project that required me to write a simple game and apply Gameplay Kit AI to the project. I chose a simple tic tac toe game because it’s simple. It’s tic tac toe. Three year olds play this game. It should be easy to implement, right?

Wrong.

I have been bashing my head against this stupid game for months because I was trying to figure out how to do it in Sprite Kit. (To be fair, I have also been rather burned out and little things have been incredibly difficult for me to deal with. Please do not judge me.)

Sprite Kit is good for a lot of things. It’s good if you are doing a platformer game like Super Mario Brothers or if you’re creating an endless runner. Sprite Kit is not as good at doing things like tic tac toe or card/board games. I was looking through my books and tutorials to try to figure out how to tell the app that a square area of the screen represented a specific square of a tic tac toe board. Most materials are glorified rewritten documentation or they focus on the easiest examples they can possibly figure out, which includes spawning enemies and having sprites removed from the screen when they collide with one.

This was driving me batty. I knew there had to be a way to do this, but I felt like I was fighting the framework because the framework wasn’t designed to do what I needed it to do.

This problem was completely roadblocking me. I couldn’t think about how to write the programming logic until I figured this out. I knew I should worry about the UI after I got the logic finished, but this thing was completely blocking my ability to conceptualize how to approach this problem. I was incredibly upset because I knew there should be an easy way to do this but I couldn’t find it in any Sprite Kit examples I was seeing.

My mental block finally crumbled a few days ago when I realized I should not be using Sprite Kit for this project. I should use UIKit. Instead of trying to figure out how to programmatically tell the app that a square area on the screen represents a square on a tic tac toe board, I should just create nine buttons.

In Paul Hudson’s Hacking with Swift book, he recreates the Four in a Row Gameplay Kit example with Swift. I looked at the Apple example and found it incomprehensible, so I was incredibly happy to find he walked through how to implement and design that example more clearly.

One thing he did in that example was he did his entire user interface in UIKit with stack views. One thing he showed that I didn’t know you could do was to create a tag for each button in the stack view and connect all of the buttons to the same outlet and action.

I have my name on books. I speak at conferences. I have worked for some fairly prestigious places. For the last year or so I have let my pride get in the way of me doing things I need to do to be a better developer.

I do not have a lot of experience. I was at Indie DevStock this weekend and I heard most of the other indie developers I look up to had 15-20 years of programming experience. I have three. I think I am a pretty good programmer for only having three years of experience, but I know that I could be a lot better than I am right now.

I have tried to find a normal job so that I can pay my dues and learn from people with more experience than I do, but with one exception, that has not happened. I encounter other people who are like me. We feel like we need to pretend like we know what we’re doing rather than acknowledge that we need to work on our fundamentals and that working on fundamentals honestly takes a lot of time. If you’re working at a company that expects you to work sixty hours a week and you have to spend all your time pretending like you know everything, you don’t have enough mental or emotional energy to go and learn stuff that you may have known at some point in the past but you don’t remember now.

Also, honestly, we feel intense amounts of pressure to convince everyone that we’re a programming ninja. No one can just be a good, solid developer. Everyone has to be a 10x engineer. Everyone has to be a ninja. We’re all competing with one another to prove that we’re hot shit and that attitude is actively stunting the growth of members of our engineering community.

When I first started out, no one knew who I was or anything about me. I knew I could not get a decent job if people didn’t know who I was. I went to a lot of effort to network and make connections. I wanted to attend a lot of conferences, but couldn’t afford to go. So I needed to find a job so that I could make enough money to attend conferences to find a job. That didn’t work. There was a work around, which was to be a speaker.

I didn’t want to be the dumb-ass pitching beginner talks to conferences on stuff I figured everyone already knew anyway. I decided to go big and started talking about GPU programming with Metal and GPUImage. I had some grasp of how these things worked, but I couldn’t think of anything I could do with them. I just wanted to know them.

I tried to learn these things without any real context for where they should be used. This is not a good way to learn something. It’s mentally exhausting and draining. You feel stupid and your mental state deteriorates. You feel like a failure but you can’t give up because you want to prove that you deserve to be around everyone else.

I recently had a conversation with Warren Moore where I told him I wanted to learn Metal better but I couldn’t think of a project to do in Metal that I couldn’t do in Scene Kit. He told me that was the point. They weren’t intending for everyone to jump into OpenGL or Metal. Scene Kit was designed to do almost everything you need to do and only once you exhaust what Scene Kit can do should you drop down to Metal.

I felt like this was the most obvious thing in the world and I have no idea why it took me two years and a few nervous breakdowns to finally figure that out.

I have been so obsessed with trying to convince everyone that I deserve to be here that I have been focusing on the wrong things. I make things more complicated than they have to be. I don’t look for the simplest solution. I jump into the most complicated thing I can so that I can find an excuse to learn something that may not be the right tool for what I want to do. I do that at the expense of getting comfortable and familiar with the easy solutions that allow me to get things done more quickly.

I have been on a path that leads me to places I don’t want to go. I want to be a great programmer. Knowing how to render a triangle to a screen in Metal does not make me a great programmer. It makes me a clever programmer. Writing clean code that anyone can read and understand at the highest abstraction level makes me a great programmer. Knowing the higher level abstractions well enough to know what they can and can’t do and when to drop to a lower abstraction makes me a great programmer.

Right now I am not a great programmer. I am a good programmer. I can do 90% of what most jobs need me to do, but I want to work towards being someone who is respected in the community for being able to solve problems.

I don’t want to keep seeking out really low levels of abstraction and create convoluted reasons regarding why I am using them when I could do things much easier in another way. That’s just stupid and I am not doing it any more. That path leads to mental ruin and despair.