Jon Blow on Indie Game Programming

Posted by Rampant Coyote on June 24, 2011

Apparently I’m appealing to programmers this week, talking about source control and rapid indie game programming. My apologies to the coders out there, but sometimes we code-monkeys need to yap.

Today, Jonathan “Braid” Blow talks about how to program indie games. He’s talking to a bunch of computer science students, and what he says might amount to heresy in many areas of academia. It’s pretty much the opposite of what I was taught, yet it’s entirely inline with what I’ve learned “the hard way,” especially thanks to working in an Agile Development environment.

For a while, I found myself feeling guilty, especially when I was working alongside some young programmer fresh out of school who immediately wanted to talk about multi-threaded AI or elaborate data structures for handling level data. I was like that too. In fact, it took a long conversation one day at a (non-gaming) job and weeks of having it proven to me by experience that often writing nice, general-purpose, reusable code like I’d been taught at school (that was a big part of the reason for object-oriented programming, after all, which was the hot paradigm when I was a student) was often NOT the best answer.

Blow talks about optimizing for life – which I would also suggest means “optimizing for schedule.” Getting stuff done of reasonable quality and performance as quickly as possible. This really comes down to the KISS principle. Most of the time, it is still the best approach. So I guess I no longer have to feel embarrassed that 95% of my “data structures” are simply arrays of structures / objects. Or that most of the remaining 5% are likewise very basic things like linked lists.

To beginner programmers: This is a good news / bad news situation. The bad news is that a lot of this efficiency and understanding of the “right thing” as he is talking about only comes from experience. There are no shortcuts there, but doing a lot of programming will get you there faster. But the good news is that a lot of the fancy-schmancy advanced techniques that you might hear about but not understand are probably not essential, or even all that useful. They are good to know, eventually, because of their rare practical usage or (more likely) because being familiar with them will help suggest approaches to solving problems even if you don’t implement that particular concept or pattern. But what you really need to know is pretty basic.

I didn’t listen to the entire Q&A session. But his main talk is worthwhile listening if you are a programmer.

How to Program Independent Games

Filed Under: General - Comments: 11 Comments to Read

jzoeller said,

Good post with a lot of truth. There is a very big difference between software engineering and general application development.
WhineAboutGames said,

I tend to feel embarrassed if anyone calls me a programmer precisely because I know what a nightmare my code is compared to the sort of thing I was supposed to do back when I was taking computer science at university.

I take every possible shortcut, I use tools and helpful programs and reuse bits and borrow bits and jam globals all over the place… but I can prototype at a speed that makes my pet linux geek weep. 🙂

Of course, if there’s anything even vaguely risky or security-related, I pass it off to him and don’t touch it myself.
Maklak said,

What he talks about bit me hard in my second job. Instead of digging through tutorials till I learned something, and then doing the right thing I was supposed to quickly do the thing that worked. This meant:
*) Implement required functionality.
*) The smaller diff the better.
*) Do the simplest sensible thing that works.
*) Don’t implement elaborate mechanisms unless you don’t know how to do it simpler.
*) Only do what you are told to do. Additional / better functionality is not always better and means more code. +20% functionality and +80% code is not good enough. Don’t get any brilliant ideas, and certainly don’t implemet them before talking to superior.
*) Remove code when possible without breaking anything.
*) Do it fast. Preferably a few patches a day.
*) Don’t use comments. Well written code is self documenting. Reverse-engineer (just read the code, really) when you need to know how parts of the system that you need to touch work.

It was quite a shock. I argued with my boss about this philosophy, but their system works, and I don’t know how. It also aligns somewhat with what I read on extreme programming, tough we used ‘peer review’ of diffs and manual testing rather than unit tests.
LateWhiteRabbit said,

I find this the truth about a lot of school training versus actual on the job application.

In boot camp in the Marines we learned a very particular and detailed way of doing everything by the rules, then when we actually went out to do the job for real we were told to discard most of that learning. Some of it was impractical, some looked great on paper but was inefficient in practical use.

In art school we learned very detailed methods of creating art, and the steps and planning we should do for commercial jobs or projects. Well, I just started working with a Visual FX studio doing work on major films, and I find few of those steps apply. The name of the game is efficiency and speed and “good enough”.

That “game” applies to all things – in schools we learn the ideal way to do things in a perfect world where deadlines and budgets don’t exist. In the real world though, perfect is impractical and expensive. Plus, the final result is all that counts. If you can create a beautiful spectacle for all to behold, be it a game, piece of art, or film effect, who cares if it’s held together with duct tape and only half-painted behind the scenes? After all, nobody is getting backstage passes!

One of my favorite articles on Gamasutra was game programmers (some anonymously) who had worked on major titles telling the most shoddy, convoluted, or embarrassing way they had created code or gotten features working in major games to get them out the door on time or just plain get the feature working at all. It was funny and informative and drove the lesson home:

As a professional, you just make sure the job gets done, no matter what. That’s the real world.
McTeddy said,

I remember at my pro game job… we had one guy who had stars in his eyes about fancy, clean, optimized, super-flexible code…

When **** hit the fan the rest of us had quick, messy, “unprofessional”, situation fixes… yet he stayed true to our education.

In the end… we had fixes and he had an over-complicated mess of code.

While I still believe in proper coding standards and flexible solutions when possible… I’ve learned that that the best solution in the real world is “Whatever the hell works”.
Rampant Coyote said,

The lesson I learned somewhat later in my profession was the idea of refactoring. When you get to the point where something is messy and too hard to maintain, it’s time for a clean rewrite – with the advantage of experience and hindsight. You will probably end up with nice, clean, more maintainable, and more flexible and generic code… that’s about 10x cleaner and more useful and made in 1/10th of the time than if you’d tried to engineer it perfectly in the first place. Designing for the known is much more efficient than trying to design for the “what ifs.”
LateWhiteRabbit said,

@Rampant
We have the same policy at the studio I work at, summed up by “If it isn’t working, trash it.”

Even in art, sometimes it is just easier and faster to throw out the mess you are working on and start over than spending hours trying to fight and fix the current disaster you have.

@McTeddy
I think we are taught all the rules just so we will know when and how to break them.
Menigal said,

Wow, who would have that what I always thought was a half-assed way I taught myself to program years ago was the standard? This makes me feel better about the slightly sloppy but functional things I’ve left behind for other people to figure out. 😀
Brian said,

That’s really true when creating art resources too.

If I spend 50+ hours doing stuff ‘the right way’ say, for a uv map, I almost never actually finish. just running with it and doing things as quick as possible, however, I usually finish and get a lot of room for ‘tweaking’ and fixing stuff that looks wrong. The final result may look slightly less polished, and I might have to throw it away and start over, but it’s better to have a ‘good looking’ result in 5 hours than a ‘professional’ result in 50 hours that is unfinished.

Of course, most times after I do the quickie job, I wind up redoing it the ‘right way’, but even then the ‘right way’ winds up taking only a few hours from start to finish, still taking considerably less time than ‘doing it right’ from start to finish.
Rampant Coyote said,

Yeah, it’s not a trivial equation. There’s a point where getting sloppy will REALLY hurt you and cost you time in the long run. But there’s also the part where you are basically doing a ton of extra work for zero gain. The trick is to know which is which – where to go quick and dirty (most of the time), and where you really do need to spend a little extra attention. If you put just enough care into your quick & dirty stuff so that it’s easy to throw away later, you can wait and find out later which was which.
Gareth Fouche said,

Article really hit home for me. As a hobbiest I didn’t force deadlines on myself, a huge mistake. Because it allows your urge to create complicated systems free reign.

I’d sit and think for days about the best implementation of a quest system that could manage all possible scenarios that I could think of generically, likewise for AI and scene management and so on.

Sucks up huge chunks of your (limited) time, as opposed to hacking something together that gets the job done.