Glenn LaBarre

Home | Blog | @gwlabarre

Keep going

September 29th, 2018

I was very wrong about how this year would turn out.

A year ago, I set out on an adventure to make my own video game. Shortly thereafter, life became significantly more demanding. For reasons that I won't belabor here, it became almost impossible to work on my game for the past nine months. Unexpectedly, this experience has made me incredibly grateful and I feel far from frustrated. Like a plant that is belligerently growing from inside a crack in a bit of concrete, I am surprisingly still making games.

It has been good to realize that I want to develop games enough that I am willing to keep going in the face of setbacks and failure. Everything else I truly love requires effort and now I know that game development is no different. I have also been learning some important lessons along the way. Well - writing that I have "learned" the lessons might be overstating it a bit. Let's just say these things are making an impact on my thinking today:

My first project was waaaaay too big

But it was not too big because my game idea was overly ambitious. It was too big because my game idea was not narrowly defined enough. Having a rough idea can be great for getting started, but keeping it undefined as you go along can also lead to an immense amount of scope creep. Much like this quote from Tom Francis, I found my time wasted on possibly unnecessary features:

"Every hour you spend working on something before you have the core part of it playable is an hour that might be wasted."

My first project got stuck in the deepest part of the weeds

And as if an enormous amount of scope creep wasn't bad enough, I also found myself polishing code instead of making progress most weeks. This is an all too familiar trap for programmers. Instead of worrying about my core game, I was obsessing about the efficiency of my home-brewed AI waypoint system. Perfecting code is an insidious killer: it feels like real progress, but it isn't.

My first project was expensive to test

Prototyping inside of your game development environment is not always the best idea. Even simple ideas can require a huge amount of objects and functions in order to test. Taking a page from my day job as a web developer, I am re-learning to prototype my game ideas outside of code:

dining room table prototype

This endeavor cost me thirty minutes plus some dining table real estate and saved me two years of working on a bad idea. After even just five minutes of gameplay and feedback, I was immediately convinced that this idea was no good.

The new rules

With all of the above in mind, I'm moving forward on my project and taking to heart some new rules. I gathered these from a talk Tom Francis gave at the GDC after launching his fantastic game Heat Signature. And although that game is one of my favorite games of all time, Tom has been the first to admit just how difficult it was to develop and how that challenge has produced these guidelines:

  1. Choose an idea that's quick to prototype
  2. Prototype the important parts
  3. Decide what should be the core
  4. Creep as far as you like in that direction

As far as I am concerned, I think he is onto something: I've made more progress in the past three weeks than I have in the past four months.