"How to program independent games" - John Blow

http://the-witness.net/news/2011/06/how-to-program-independent-games/

I’m sorry if this has been linked in the past, but for the fact that I haven’t seen this until now and it really is one of the best videos I’ve seen for aspiring indie game design, so I thought I’d link it again. The actual video’s only about 30 minutes, but his biggest point is so counter-intuitive, yet so basic that it’s hard to miss – as programmers, we have this habit of “optimize optimize optimize, generalize generalize generalize”, when in fact 95% of all the ‘optimizations’ we make have negligible effects on the user-end, and they just complicate the code – and more importantly TAKE TIME TO DO – for no return. We, as aspiring developers looking to release, should spend our time making it work, then at the end if there are performance issues go back and optimize, not in the middle. “Yeah yeah, step three is make it fast. We know.” But he gets into a lot of things, it’s really just a fantastic video and has completely changed my approach to coding now. So maybe he will help out someone else, too.

I won’t be able to watch the video until later, but one of the comments (and yours) on this article really struck me.

At my last job, we focused on the simplest approach to make something work. Optimizations, “supposed” features people might want or need, anything like that weren’t even worried about until it was a problem or truly needed.
Granted…if you KNEW in advance that something was going to be a problem, of course you dealt with it then.
Aesthetics took a waaay lower priority than functionality.

Now…this was new project…a business program. Presentation was a much, much lower priority than functionality.

To me, game development is more artistic, and the -presentation- is VERY important. It’s why angry birds made mega money, and crush the castle is a game few people have heard of. It’s why iPhones are so popular imo.

Overall, my general approach is

  1. get it working
  2. refactor - To me, refactoring means is the code CLEAR? It is a good design? Does it “feel” like a good design, or does it feel wrong somehow? (Code Smells). Are any obvious bad choices in there that might affect functionality, performance, or presentation?
  3. Test it. Does it do what is expected?
  4. Use it. Is it intuitive? Does it make sense in how it use to be used by people? I want my systems to actually be pleasant to work with, instead of “I don’t care”, “meh”, “could be better” or “how do I use this?”
  5. Then, if on down the road I find an area needs performance, that’s when I’ll focus on optimization the area that needs it.
  6. Make it looks as nice as possible…talking about artwork here. Textures, etc.

Also, at least every few days I go over different areas of my code…it is amazing how often I find system that just aren’t as elegant as I would like. They seemed fine at the time, but after a few days somehow my brain has an idea of how to put in a much better design.

And your code is the house you live in. If your code is a mess, hard to maintain, and nasty…so will your life in that project be.

It’s a fantastic video. Jonathan Blow is a great speaker and a great designer.