Jonathan Blow Talks About How to Program Independent Games

Jonathan Blow developer of Braid and currently developing The Witness gave a speech at UC Berkeley’s Computer Science Undergraduate Association.

In the beginning of the presentation Jonathan sets a perspective for the size of two projects of his Braid and The Witness. The metric used, which he mentions that isn’t a good metric but only used for helping the audience understand his points, was lines of code. Comparing to the average lines of code/year, Braid would have taken about 28 years to develop while it really took about three and a half.

Jonathan also talks a little about xbox development. Games submitted must go through a certification process which ensures that it works properly. There’s tests such as running the game for three days without crashing or having the load time not pass a certain amount. These tests ensure that the game has quality code.

A point he makes is that usually people want to optimize too early. They want to make the fastest code possible. While that’s great, many times it isn’t the best way of accomplishing things. One of the reasons is that many times when optimizing, you’ll add many constraints to the code which can possibly become hindrances in the future. Another reason is that most code is not performance sensitive, meaning that having the fastest response possible won’t matter as much.

Optimizing is generally bad. This is because most people will want to keep optimizing every code they write. If you spend more time than you should on something, this will increase proportionally and delay your schedule more than it should.

In order to deliver a lot of quality content with good code, you need to be extremely effective at getting things done on time.

Something that you should optimize is years of your life per program implementation. You should be more worried with how much time you spend actually developing the program instead of optimizing how many seconds your program takes to run or how much space in memory it takes (unless you really need to think about those things).

A good programmer within the context of creating independent games and where you’re trying to be productive is someone who can get things done and makes things simple. There’s no problem knowing a lot of advanced ideas and techniques but you need to be able to discern when is the best time to use those.

During the talk Jonathan also talks about data structures and more programmer specific subjects. If you’re interested in it, definitely take a look.

Jonathan ends his lecture trying to raise people’s awareness about how they should be focusing more on the big picture view of the project and actually getting it done instead of focusing on the tiny parts and optimizing them.