next »

[dmoonfire]

There is always a trade off of speed of development verses using formal methods. I mean, most of us probably don't use flowcharts or document our code in UML (I *said* most ), but for larger projects, that is pretty much one of those universal things. A small project won't use use cases, but a larger one might actually do it.

One of the key points is numbers. When you have 1 developer, its pretty easy just to move forward and write things as you go. When you don't really have a deadline, you don't really need a schedule to move forward. So, you can work fast and just get it done. When you have 2-3 developers, you need to start planning out more and if you have 10+, a design methodology is pretty much a requirement. Doesn't matter if it is TDD, Agile, X, or waterfall. You just need something to work with, otherwise the anarchy slows everything down.

I use TDD in most of my development because it fits with my methods of development. I like to test my stuff heavily, simply because I made rather complicated systems and I like single-function models with graphics in front of them. That comes from the Unix philosophy: many small tools, each does one thing well. I also make stupid mistakes. I'll repeat that a lot, I make a LOT of stupid little mistakes.

I don't bother with TDD for views but I'll consider it for controllers. I feel that having automated test suite is very useful also when you are bouncing between projects, as I frequently do, and also when you want to get a feel for how the code is actually going to be used. I also use the tests for example snippets, they have enough multiple uses to justify doing TDD.

TDD by itself won't make a great product, just as MVC or AOP coding won't. Instead, it is just a framework for developing and to give structure. I think the structure works out well for larger projects but I also sketch out UML in my notebook when I'm coming up with programs.

Most of the buzzwords are more applicable with larger projects and larger teams. Or, more accurately, the extra effort for the cruft to maintain and develop them becomes less significant as the scope, complexity, and resources increases. At least, that is how I see it. I just happen to use it to keep my skills up for my professional life and also because it helps reduce the context switching I go through.

Regardless of how you write it, you still need a good goal of where you are heading. A specific game or end result. Making it flexible and updating frequently (agile development) is just another way of handling changes and "we can't plan for everything" that always happens. You can do the same with monolithic development, it just requires a different culture and skill set.

EDIT: Lots of little bugs in what I said.

[Ivan]

I think for me, game programming or other sorts of graphical or "creative" programming is vastly different from traditional programming methods. It's alot more spontaneous and fluid, like most creative processes. On the other hand I am a firm believer in rigid, well organized frameworks, so my mentality when it comes to "creative" programming is to make a solid API, to which all of the normal "business" development methods apply, but when it comes to using it, its all out experimentation mode. So in my opinion,it's good to have a rigid, well organized system that helps you get things done, TDD or not, but only for the base framework, leaving you to sketch and branch out in random tangents when you're doing the actual game/graphics code, because I think thats where good ideas are often born.