≡ Menu


I got my first game programming gig in May of 2003 at Blue Fang Games (RIP). I left the game industry in 2012 after the death of 38 Studios (RIP). That means I programmed games professionally for just under a decade. That’s a long time, I must have learned something right?

Here’s a list of some things I’ve learned off of the top of my head:

SYSTEMIC: Problems are systemic

I’ve worked for a number of different companies, and have seen the same pain points crop up again and again all over. Different people, different products, different publisher, different console, different target demographic, different management different companies… same exact problems.

I think this means that a lot of the difficulties and pain faced when trying to ship a game are largely inherent to our current understanding of the development process, and don’t generally reflect the implementation details in particular. Different management teams can help or hurt a bit here and there, but it takes a ton of effort to truly fight the system.

BLAME: Be careful with the blame game

Related to SYSTEMIC above, it’s often very tempting to throw blame around from your personal viewpoint. “If person X hadn’t done Y then everything would be perfect!” I’ve personally been guilty of this type of thing in the past, but in retrospect it was never really productive at all. Most of the time the person easiest to blame is just a symptom and not the actual underlying problem.

Publishers are the #1 most blamed entity in game development, listening to some people you’d think that everything to ever go wrong in every game’s development is the fault of the publisher. Now I’m not saying that publishers are blameless (the developer-publisher relationship is completely degenerate), but they are too easy of a target. I’ve worked on several projects with no publisher at all, guess what? All of the problems that people on past projects blamed on the publisher were still there.

Blame, blame, blame.

MISTAKES: I make tons of mistakes

Programming is really hard, and I make tons of mistakes. I think everyone does, but a lot of people don’t seem to want to admit it (consciously or subconsciously).

As a programmer, the counterattack is to use the computer to help you catch your mistakes. Aggressive use of unit tests, static code analysis, interactive testing, etc. These can help to catch a lot of the mistakes I make before they get out into the wild and cause other people pain.

In the past I have been surprised many times by programmers who do not take full advantage of these resources, especially on projects with full testing frameworks.

Here’s a conversation that should never happen:

Developer A: “Hey, when I boot up the game everything crashes immediately. I’m pretty sure it was your change c12345 that caused it.”
Developer B: “That change shouldn’t have caused a crash.”
Developer A: “Did you try launching the game?”
Developer B: “No, it shouldn’t be causing a crash.”

Here’s another conversation that should never happen:

Developer A: “Hey your change c12345 is breaking this unit test.”
Developer B: “Hmmm… I’m not sure why that change would break that test.”
Developer A: “Did you run the tests?”
Developer B: “No, it shouldn’t break any tests so I didn’t bother.”

These are pretty much word-for-word conversations that I’ve actually had. My advice is that instead of thinking hard and theorizing about if a change will crash the game on boot or break a unit test, just launch the game and run the tests.

Also to be clear, I’m not saying that I’ve never caused a crash or broken a test before – but I can say that I’ve always at least put in a decent effort to make sure that I’m not checking in code that’s going to break the product for everyone.

SCHEDULES: It’s hard to get value from a schedule

Creating accurate schedules is extremely hard, and they’re often wrong. The best explanation I’ve seen for why is this post here. In my experience this is sort of just the reality of the situation: making schedules is hard and time consuming, and they’re usually not very good or accurate. It’s a bummer.

Even with all of this effort going into creating a schedule, I haven’t really worked on a project where the schedule was used to make important decisions or really taken seriously at all. Most often a lot of energy went into creating a schedule, and then everyone would just sit around and get frustrated as we fell behind without really doing anything about it.

Actually, something was typically done about it: initiate crunch mode. Then we would just fall farther behind. More on that later.

FEATURES: Lots of features will be cut, even if nobody will admit it

Related to SCHEDULES above, cutting features seems to be one of the most difficult thing to make happen in any game development process. Nobody ever wants to do it, it’s like pulling teeth! But here’s the thing: Features will be cut. Has a game ever shipped with every desired feature? You can either proactively cut features and craft your game accordingly, or you can try to do everything and run out of time.

If you run out of time, then you have just cut a bunch of features at the absolute worst possible time: the end. The earlier you can cut features, the better. Every feature cut makes all remaining features a bit easier to implement. Less interaction between features means less complexity. Every cut feature helps defines the possibility space of your game, and the earlier this happens then the earlier you can enhance the positive aspects of your product.

I have found that deciding what not to do is incredibly productive.

TEAM: Multidisciplinary teams are interesting

One of my favorite parts of working in the game industry was the multidisciplinary nature of the development team. There are few jobs in the world where you can regularly work together on a daily basis with programmers, concept artists, animators, musicians, authors, screenwriters, producers, level designers, and system designers.

I always loved this aspect of the job, but it does bring a bunch of potential challenges. Crossing the divide between disciplines isn’t always easy, and it often leads to conflict. One thing I frequently noticed is conflict arriving over vocabulary. A programmer is trying to work something out with a designer and argues using ‘programmer vocab’, the designer doesn’t understand completely and gets totally defensive, the discussion goes nowhere. One piece of advice I can give when working with other disciplines is to be very careful with vocabulary, I’ve found that things go a lot better when everyone understands the words involved.

REWRITE: Don’t be afraid to rewrite

Making the decision to rewrite a system or feature shouldn’t be taken lightly, but it can be the right thing to do. There’s nothing worse than dumping time week after week into a system that hasn’t been designed correctly and needs a rewrite. I find that sunk costs are often overvalued, and the word ‘rewrite’ is frowned upon. Make an honest assessment of the situation and decide what the best course of action moving forward is. Don’t get defensive, don’t be upset that it wasn’t done right the first time – make the best decision for your product.

Rewriting isn’t something that is always done to major feature/systems, smaller code refactors are often just as helpful. Related to MISTAKES above, I often find that my initial code implementation wasn’t so great in retrospect due to unexpected usage patterns, changing surrounding code, or whatever. When I’m evaluating potential solutions to a problem, I always include “How easy will this be to refactor?” in my heuristic. Chances are it’s not the ideal solution and I’ll want to refactor it at some point in the future, so the easier the better.

Go forth young Jedi and refactor.

CRUNCH: Crunch is poison

Crunch is a horrible practice, and a terror that is damaging the game industry. The culture has been poisoned, and the antidote is nowhere in sight. Sadly, I don’t think the antidote is even really wanted.

Maybe things are different for other disciplines (art, QA, whatever), but as an AI programmer I really feel the effects. Programming is extremely difficult, and when I’m not at my best I just can’t really do it. I’ve been in ‘death march’ scenarios before, seven days a week, 100 hours per week. Not surprisingly, my production just bottoms out. Every day that passes I accomplish less and less. I get frustrated that I’m not accomplishing much, and as a result I end up sad and frustrated. The next day I accomplish even less. It’s horrible.

There are countless studies that show that crunching doesn’t increase software engineering productivity, and all of my anecdotal evidence points in that same direction. One incident I’ll always remember from early in my career is staying at work until 3AM with two extremely smart engineers working on a problem together. We came up with a great solution and went home to crash, feeling very proud of ourselves. I came in the next day and realized within 5 minutes that our solution was terrible and would obviously never work. Sure things like this also happen during ‘sane’ development hours, but during crunch it seems to happen constantly.

I honestly think crunch is now a non-starter for me. Moving forward I just can’t be involved with an industry where crunch is such an ingrained part of the culture. Since leaving the game industry I’ve had actual NIGHTMARES about being back at a game company, crunching.

SADNESS: I don’t want to do this anymore

As a child my dream job was game developer, and I really sculpted my early life to make it happen. Everything worked out according to plan, but fast forward ten years and I don’t want to do it anymore As I get older I guess I value different things. Stability is more important to me. I’m sick of every company I join ending up on life support within a few years. A lot of the cultural aspects that appealed to me as a younger man just don’t appeal to me as much.

There are lots of positives about the game industry, but for me the scales have tipped too far in the other direction. I still love working on games, and I think I’ll always be involved in some degree on a hobby-level, but unless there’s a major shift in the industry I don’t think I’ll be back professionally.

I guess that’s enough for now. I have plenty more to say, but it’s a beautiful day and I want to get out there! Maybe I’ll follow up with a second post at some point.

{ 0 comments… add one }

Leave a Comment

Next post:

Previous post: