Test Driven Development, Several Years Later - or, I'm a Big Liar

Martin's comment on an old post reminded me that I really ought to come clean. I said in that post that I was going to stick with TDD despite its unclear benefits. I didn't. Our Bejeweled Blitz: Live contract came along, and the other programers weren't into TDD - I put some tests on a few bits here and there but that was pretty much it.

So I was pretty much broken, and with sixty second shooter I didn't even bother. I just wanted to get that game done as fast as possible and was willing to do a half assed job. (BTW, I slaughtered a sacred cow there: it's generally true in our industry that polish is king and that a great, late game will do better than a game that's on time but not-fully-baked. But Farmville shows it's at least possible to ship a half-baked game and make it better afterwards.)

With both those games, by the way, I'm pretty pleased with the non-bugginess. It's hard to really tell with sixty second shooter since I didn't hire a QA team or anything, but one interesting way to tell your game doesn't have a lot of bugs is if everybody is reporting the same ones. It's a much smaller game than Schizoid or Bejeweled Blitz, but the bugs-per-capita seem great.

What I chalk that up to is not TDD but being a better programmer. Maybe not quite as sharp (Guys my age start losing their edge at chess, etc, and having kids and cats wake you up in the middle of the night almost every night doesn't help) but I'm almost religiously not cacheing state in my code these days and there's just a lot less room for bugs to creep in.

Comments

[TM]

I was really looking forward to you posting about TDD in game development when I read that announcement too. I use it every day in my web development job but it has always stymied me as far as applying it to games when I am messing around with those in my free time.

[Karim Ahmed]

The most important feature in TDD to me is the optimal protection of future changes that may break other system functionality.IMHO Systems with a lot of undefined and unrelated functionality and components with huge class hierarchies, would benefit the most from TDD because TDD will force you to organize your system in a modular testable and heavy change tolerant way. But in games the life cycle is shorter, changes are less because you have defined set of goals to achieve and if not and you are still just exploring,the changes are visible to you, TDD would be a huge overkill for things like AI and Physics because there behavior is not controlled by you and TDD requires that. Yes you can TDD the code that builds up these components but IMHO it still an overkill.
I have used TDD to write algorithms that have many changing inputs and outputs. Again it protected me from shooting myself in the leg and it worked well.

PS. I never used TDD in games or even close to ship one :))