Comments

I've given a fair bit of thought to TDD in games and spoken with a number of people about it. I think in general TDD is great and it would be great for games, but the conclusion I always keep coming to is: for a game, so much of the code base is focussed on the UI, which is also adapting and changing on a regular basis, so it makes it really difficult and probably not efficient to write unit tests for game and write the game in a way that you can easily isolate it test each part. Sure, if your game has a large backend component, or you're working on a large "commodity" game engine, then I could see it being very valuable, but I feel like nowadays for many games the time spent on easily testable parts is really small. If you're familiar with TDD then using it, even for the smaller parts (and then maybe in the very long-term hoping to expand that) could work, but personally I have been hesitate to take the leap with my teams. Are there many (any?) examples of game successfully using TDD, except those that could obviously benefit from it, like MMOs?

I have tried it on small parts of our codebase, the stuff that can be easily isolated out, and it really has made a difference in those areas. The ability to test those bits of code on their own, without waiting for the whole game to spin up is just huge. I also found I caught a lot of smaller issues far sooner. It kind of forces you to think of what you really need first, as well, since you're supposed to build the tests first. So lots of pluses, but yeah its usefulness definitely feels limited because of the highly complex presentation layer in games.

I'm not aware of any good test cases of TDD in games, but I haven't really looked. That's one of the reasons I thought this talk would be interesting to see :)

Huh. Trying not to have spaghetti code in game jams is an extremely surprising goal to me.

I've tended to think of game jams being like the concept art of game design. You jam for a short period for the purpose of not caring if there's spaghetti code, because knowing it only took you a short period makes it easier for you to discard the jam code, take the experience you intended, and move on with another iteration. And that if you decide to take it further, you'd presumably have a much better idea of what your game's actually about after the jam (or several jams), and are in a position to "do it properly" then.

Not having spaghetti code is a good thing, of course; but I feel like that's something that's quite valuable on a larger, lengthy project, and almost useless in the context of a game jam. I don't think it's worth optimizing for that at the potential expense of short-term creativity, flexibility and speed. And having to write tests up-front feels impossible to me, given that the game evolves as I work on it in game jams, and I sort of just follow where the fun is. You can write tests if you know what functionality you're aiming for; but I don't think you can when your aim is "Make a game about the theme 'Small World'", or "Learn this new game engine", or "Try to write an interesting narrative", or "Create a dating game that subverts rape culture". I don't think I've ever met someone who said "I want to write clean code in my 8 hour time limit."

Of course, whether TDD works in a game jam could be game jammed too... :D And if having cleaner code is the goal in the jam, then sure. I just don't understand why, and I think it'd be something worth asking them.

Have to echo @Elyaradine, that is pretty surprising! I feel like you can gain experience in how to write better code during a jam, but the best way to use that improvement in skill is to try accomplish more in the same time, not end up with cleaner code and less technical debt. I'd say that if you end a game jam with no technical debt or spaghetti code you could have spent your time better (I'd actually say that if you finish any project with zero technical debt, whether it's a jam game or a multi-year project, you wasted time reducing the technical debt).

The thought of using TDD for a game jam never even crossed my mind. I would wager that the total cost in time and effort for (game jam with TDD + continuing from the code base into production) might be higher than (hacked-together game jam + rewrite for production), and that's ignoring that the lower cost for a hacked-together game jam means you can iterate on many more ideas to select better projects to invest into with production.

Yeah as much as I'm a stickler for clean and well organized code, I don't feel like jams are the place to focus on that. Assuming of course you will actually throw that code away after the jam >.>I've worked on too many projects where the original prototype code was used to start the actual project, and hampered development down the line.