Category Archives: Game Development Journal

Game Development Journal 2: Getting Stuck in Boxes

This post isn’t specifically about the project I outlined in the first post, but it is a persistent problem I keep running into, even though I know the problem is there.

I am working on a tutorial for Ray Wenderlich and I have been running into issues with it.

My issue is that I have program-specific logic. I am creating a very simple game, but one thing I didn’t think about was the fact that you have to explain every little thing to the application. There are so many connections your brain makes automagically that a computer doesn’t know. You have to figure out how to tell the app how to think. This is the underlying issue in machine learning, but on a much larger and complex scale.

One reason I wanted to do a game application over a more useful type of application is because of application specific programming logic.

One thing I find frustrating, that is actually a feature of iOS, is how many frameworks there are. Sometimes I feel like when I am writing an app that you are choosing a framework, reading the documentation, and then just setting a few properties on that framework to make your app do something. So like, if you are doing something in SpriteKit, you’re choosing the image for the sprite, then you choose where it’s boundaries are, and you set a bunch of properties on the SKSpriteNode.

I have found that I get into a mindset where I feel like the only tools I have in my toolbox are ones that are pre-baked by someone else. If there is’t a framework for it or a property for it, it doesn’t occur to me that it can be done. The app is basically a giant state machine where your Swift/Objective-C code is just some glue holding together a bunch of pre-baked parts.

Whenever I am presented with a problem that requires a lot of program specific logic, my brain freezes up. It gets used to the idea that I just go pull a piece of code out of a box and it does what I want it to do. When I have to actually engage my brain in figuring out what my application has to do it’s like exercising a muscle I forgot existed. It’s incredibly weird.

I know that all of programming is supposed to be about figuring out what you want the application to do, but most of us don’t think that way. There are so many fucking blog posts by people trying to come with convoluted reasons to create hieroglyphic looking Swift closures that you need a Rosetta Stone to interpret. Most blog posts and tutorials are around talking about the components of a framework and not what you can do with it. Every game development book I see talks about how to use the tools of something like SpriteKit or Unity, but not how to think through how you would solve a problem.

The thing that prompted my last blog post was my expressing frustration that programming books talk about tools but not how to use tools to solve problems. I got a bunch of sanctimonious assholes telling me that if I read a book on algorithms it would somehow magically solve all my problems and telling me that if I read a half dozen different books that somehow I could cobble together all of the stuff I need to do what I want.

I think there is a better way.

I feel very frustrated that we, as a community, don’t talk more about how to think through how to solve a problem. Yes, there are multiple ways of solving a problem. So why not talk about it? Talk about how you tried a few different ways and you ultimately chose one specific way because it was the shortest or the most maintainable or the most reusable, etc…

We don’t do this because it’s hard.

It’s a lot easier to write a blog post saying you did something simple with SpriteKit that looks super impressive but doesn’t give anyone a visceral understanding of what they can do with it.

One reason I am running into problems learning Metal is because I don’t know what I am supposed to do with it. Almost anything I need to do in Metal can be done with something like SceneKit. I keep trying to learn the framework with no context as to why it’s important and what problems it solves. I get people hassling me by telling me it’s up to me to figure out why it’s important and that’s bullshit.

Programming isn’t an objective thing where every single app is a special snowflake. They all require us to think through why we’re doing what we are doing. I have fallen into a pit the last year where I have just automated that process in my brain where if I encounter a situation that doesn’t fit into a neat box my brain can’t deal with it. That’s fine for most of what most employers need, but I don’t want to be like this anymore.

I miss thinking about how to solve problems. I miss working on a portion of a project where I actually get to touch things and see how they connect rather than being told to pay no attention to the man behind the curtain because the code base is so fucking massive and poorly documented that no one knows how it works.

I am trying to shake away my mental cobwebs and remember that programming doesn’t have to be an automated process or something where you get into a pissing match with other people to make the most convoluted code you possibly can without breaking the compiler.

One of the goals with this series of blog posts is to explain a problem I am trying to solve and walk people through my thought processes in the hope that we, as a community, put more effort into talking about how we approach problems rather than seeing who can be the first person to get something running on the Apple Car, whenever it comes out.

Game Development Journal 1: Planning Stage

I find myself with a period of time when I do not have large-scale immersive projects for other people that are absorbing all of my time and energy. For the last two years I have perpetually been working on a book, or trying to finish a project for someone else. As soon as I am done with one project, another one pops up. Work is like oxygen, it will fill every space in a room.

I have been dealing with some anxiety the last few weeks because as of right now there are no projects popping up immediately after I finish this current one. I am realizing that this is actually an opportunity to do something I have not done before, which is actually spearhead and complete a project of my own.

I keep meaning to work on my own projects, but then something amazing will come up and I will feel I can’t say no. Then I work too hard and get burned out and have no time for projects of my own. I feel like I can’t say no to amazing (paid!) opportunities working with amazing people for a gamble on a personal project.

There has been a lot of doom and gloom about how you can’t make a living as an app developer anymore because the market is too crowded and people don’t buy apps anymore, but I am realizing there are a lot of long term benefits to taking a few months to do an app.

Project Organization

One of the biggest complaints I have about working for other people is that they seem to not really know what they want. I have had a number of projects come to a grinding halt because the product owner keeps changing their mind about what they want. There is no point in implementing something if you’re just going to change it tomorrow anyway.

This also leads to project bloat. Once you start changing things or don’t have a plan in place to begin with, it’s really easy to add just one more thing. That “just one more thing” eventually becomes an endless laundry list and nothing ever ships.

I wrote a blog post recently about how this mentality completely destroys my mental health. I like to break my projects up into manageable tasks and I like to have an end, success goal when the thing is done.

I understand that as an app developer your code is never done as there are changes in languages and frameworks, but to me maintenance is different than active development. Adding a feature is another separate project apart from initially shipping.

By running my own project, I can control the features and the development schedule. I can firmly decide what features I want to have and prevent the project bloat. I can also figure out which tasks need to be done first and how to build upon those.

I want to avoid this situation. I like the idea of Agile, but in practice it’s usually terrible. I am really bad at reading other people’s minds about what they want and most people are really bad at expressing what they want. It’s like truthiness. It’s a feeling more than a concrete set of goals.

I am hoping that by actually setting out goals for a project and completing it I can help clients in the future focus their goals into something that has a chance at success. If I fail then I hope to at least get a perspective about why most projects seem to degenerate into chaos.

Why a Game?

I am choose to write a game. No, I do not plan to earn a dime from my application.

I am choosing a game because it seems to be more immune to the issues I talked about earlier. It has a set of rules. It has limited stuff that can be tacked onto it without fundamentally changing the nature of how it works.

I also want to dive more deeply into the Apple game frameworks and some of the Apple frameworks in general.

When you’re looking for a small, self contained project, it’s really easy to pick something that only uses UIKit, like a todo app or a Twitter client. A lot of companies want you to have knowledge of Core Data, but most don’t really seem to use it.

I want to get more comfortable with diving into an unfamiliar set of frameworks and getting something working. I could probably do this faster in something like Unity, but I would like to stick to the Apple frameworks. I might port it to Unity in the future as another project, but it’s not the goal for this one.

Godori

I am not going to be designing a game from scratch. That alone would take a lot of time. So I am going to implement an already play tested game I am familiar with.

I never was into video games, but I did very much like turn based games. I liked board games and card games where you had to think through things.

I used to play chess as a kid, but I really got bored with it because there were no random elements. It was possible to play the same game over and over again. That got boring quickly and I got into games with some more random elements.

There was a shareware game I played a lot as a kid called “War of Flowers.” I did some research on it over the last few years and found it was an implementation of a Korean card game called Godori.

Godori is like Korean poker, to the best of my understanding. The rules are somewhat simple. It uses a flower deck rather than a traditional playing card deck. The flower deck has twelve suits with four cards in each suit. Each card has specific aspects associated with it that affect scoring.

You also have the option to continue playing if you think you can accrue more points before the end of the hand.

This affords a decent amount of complexity and strategy without getting overly bloated. It has set rules it must comply to in order to work as designed. I don’t need to play test the rules because the game has been around for a really long time.

Components

I sat down and made a list (no specific order of importance) of all the parts I think I need to create to make a polished, nice application:

  • Game Logic
  • Artwork assets
  • Card Objects (the list of attributes and values for each individual card)
  • Playing Area
  • Setting up Game Center for people to play one another
  • Game AI if you want to play by yourself
  • Animations, sounds, and various polish
  • Cross Platform compatibility for at least iPhone and iPad

Some of these components build upon one another. It would be stupid to try and set up card animations before making sure the game logic works.

By trying to lay out concrete components that I expect the application to have I am hoping to avoid adding bloat to the project. I am also hoping to focus myself so that I don’t get overwhelmed worrying about how I will get the animations and stuff working before I even get the base programming logic in place.

Learning and Developing

I have a slightly tricky path I want to walk here. I have not really worked with SpriteKit or GameplayKit. My iOS experience is all over the board.

I know I tend to fall down rabbit holes and I am afraid I will get so absorbed in learning everything about SpriteKit that I will never get anything done.

I think I need to dedicate a certain amount of time to learning new stuff. I think that the entity-component system is probably the best way to implement the different values of each card, but I have not used it before. If I was just doing it in Swift I would probably have an enum or a protocol, which might work better, but I don’t know. I would like to have information about all of the tools I have available out of the box before I waste a bunch of time rolling an implementation that I didn’t have to.

I am planning, at this point, to alternate between working on tutorials/research and active development. I want to try to alternate days until I exhaust the tutorials and research. Then I might replace it with generating the art assets.

Long Term Strategies

One reason I want to alternate things is because I feel I have a crop rotation mentality for doing work. If I work on one type of thing too long my brain burns out. I need to have some variety in what I do in order to keep from exhausting the part of my brain that does code.

One issue I have had with contracting is that everyone only wants you to do the most labor intensive aspect of software development. There is no ability to stagger tasks with less demanding ones so you have a chance to recover. It’s like sitting there during a workout and doing only bicep curls. There are a limited number of bicep curls you can do. I would like to do my bicep curls, then go for a jog and then work on my legs. There should be a way of setting this up with programming jobs, but no one wants to do that. They want to force you to do the difficult stuff constantly until you burn out, then they replace you with someone else. Or even worse, you never get to work with anything because you’re too busy talking about what you would do if you did work with something.

I want to see if it’s possible for me to work in the way that is best for me and still earn enough money to support myself. That is the long term goal. I do not want to burn out after five years and then get promoted to management because I hate code and never want to do it again. I don’t think this game will earn me a dime, but I am hoping the professional things I learn from doing it will help me develop long term career strategies.

I hope to document every aspect of this on the blog. I want to explain how I solved various problems and implemented various parts of this application. This is probably overly optimistic, but I would like to to complete this in two months. I hope to not get derailed by mental health issues or just plain getting distracted by shiny objects.

If I work consistently for two months on this and it doesn’t get done, I am okay with that. I just want to develop a work ethic and strategy where I get things done every day without hurting myself.

My “official” start date on this project is September 19th. I am finishing my project tomorrow, but I am traveling to Tennessee for Indie DevStock. I also have a short contract after that and a tutorial to complete. So not completely free, but significantly less busy.

If you have been through this process and wish to share advice, I would welcome it. Get ‘er done.