Wrong.net

Recently, I’ve been finding myself spending way too much time thinking about tools for game development, and not doing enough game development.  So, after I get through the current crunch state I’m in, I think I’m going to set a goal for myself to write a game in a week, no matter how small in scope.

When you have no timeframes and no set deliverables, it’s easy to get lost in theory-land, or what-is-the-best-way-to-do-this-land, or this-tool-isn’t-quite-perfect-land, or any number of other traps.  A hard deadline of a week seems like a great way to force myself past those.

The rules will be simple.  I will set a start date.  Seven days from then, I am done.  Anything not completed, is not completed.

The basic plan I have is to have a minimal basic idea of gameplay, and incrementally develop it primarily using TDD.  I am going to focus on a minimal, complete game before I focus on adding a ton of features.  The hope is that by doing so, I’ll have a game that’s ready to “ship” early on, and additional features will just be that.

I’m allowing myself the time before I start to investigate tools and think of gameplay ideas.  I will not be using the time before the “official” start to write code/do spikes/etc.

I’m looking forward to this.  It’s a chance to look at several of my development theories, and see how they pan out.

OTOH, I don’t think I’ll repeat it indefinitely.  There’s stuff I want to do that’s definitely not possible within a week.

A lot of people have probably heard of test-driven development, and the buzz around it.  There’s evangelists and zealots, frameworks (unit tests and mock objects and acceptance tests, oh my!), and a lot of heated discussion.

What I don’t see a lot of is the basic ideas of test-driven development, distilled and put into a form that most programmers can relate to.

A typical pattern that I’ve seen is the creation of separate applications or workspaces to isolate a component while you’re developing it.  If you were to do that with a stack, it might look something like this:

static public void main(string[] args)
{
   Stack s = new Stack();
   s.Push(”foo”);
   s.Push(”bar”);
   string test = s.Pop();
   System.Console.WriteLine(test);
}

In some cases, you’ll write this before you even write the stack class, as a way to define your API in an outside-in way.

After you’ve written your Stack class, and you get the results you want, you’ll probably look at the insides of it to optimize it, or make it designed better.

If you’ve done this, congratulations, you’ve used test-driven development.  No, really.  Everything else surrounding TDD is nothing but tools to help write and run these types of testbed or sandbox programs.  For an experienced developer, it really is much ado about nothing.

A couple of thoughts I’ve had on the TDD process that may not be inherently obvious.

1. If you already have a complete spec with all of the API, and cannot deviate, you are not doing TDD.
2. When writing the test first, the failed compile is a good thing. This helps prove that you don’t have any kind of strange name overwrites that you’re unaware of. The value of this, of course, depends on language.
3. Once the compile errors are fixed, the failed tests tell us that the component isn’t “accidentally” doing what it needs to be. If it is, we need to figure out in what circumstances, or why.
4. One of the big problems people seem to have with TDD is not refactoring. Refactoring is, in my opinion, the most important step. Without refactoring, using TDD, you will have garbage code (though it’ll probably have a nice API).
5. People seem to balk at the idea of writing the minimal code to get the test to pass.  They somehow think that this is supposed to be final code.  It’s not (necessarily).  The point is to allow you to enter the “green” (refactoring) phase earlier and with less work.  When possible, we want to be in the “green,” so that we know if we do something that causes a break.  If we try to write our ultimate design up-front, that just means that a lot of code is being written at one time without any assurances that it works.
6. If you find that you need to refactor to make a test work, comment out the test first, and then do the refactoring. Always refactor when green. Otherwise, you’re getting into the trap of refactoring while changing functionality, and that’s a slippery business.
7. People think TDD means no design. I don’t agree. Generally, you start with a class, which implies a certain amount of design. But TDD folks think about design, a lot. They just don’t think about design a huge amount up front, except for high-level architectural decisions, and they retain flexibility to change the design in case they were wrong.

And a final though: Since adopting TDD, I find development without it to be somewhat weird. Just as non-TDD’ers think we’re weird for writing tests first, I think what they’re doing is strange.  To me, writing tests last (or not at all!) is essentially writing a bunch of code, and then trying to figure out what it does.  It just feels very unsafe, and I just get a weird feeling when doing it.

I don’t know how valid that is, or if I’ll think I’m an idiot in five years for thinking like this.