Sunday, December 13, 2009

Evaluation Loop - Why build and setup times matter

Lately I've been thinking about "turn around time" and programming. I'd define this is the time it takes one a change is made to determine if it is correct. There are two parts to correctness:
  • The syntax is correct and the compiler will accept it.
  • The code "does what you want"
The most important resource you have as a developer is your attention. The shorter this cycle is, the more likely you are to not get distracted and get more work done. This is why in magecrawl, I've done what i can to make the turn around time as close to zero as possible.
  • Visual Studio will underline bad code as you type, so you don't even have to hit compile to know you forgot a ';'.
  • C# has a ridiculously short compile and build time. I can build my entire game in less than 3 seconds. 
  • The build step compiles and copies all the associated DLLs into a "dist" directory which has all the associated data files checked in. (No manual setup on new branches/machines).
  • Debug builds turn off the introduction screens, "are you sure" timers, save on closing window, and anything else that slows down testing.
There is one things I'm currently not doing which might reduce "turn around time" even more.
  • Unit and integration test the game engine and utilities module. This way, I could check common use cases with the hit of a button.
My excuse for this is lack of developer bandwidth. Ironically enough, something that could reduce my testing burden is too much of burden right now. As a developer, if other people aren't using my code, I tend to loose interest after awhile. That's why I released a tech demo of magecrawl, and want to get another tech demo finished soon, to get people to use it and keep my interest.

If you are programming at all, it might be worth investing time into making your build more automatic and faster. It's not the time savings as much as the attention savings that are paid back as dividends.


Nolithius said...

I quite liked C# the little I worked with it. Plus Visual Studio, while a giant bloated monster, does have great IntelliSense and code correction.

My current RL is in Flash ActionScript 3, for similar reasons to those you've outlined here and in your "Why your next roguelike should be in a managed language" article.

I am, however, feeling the pain of moving away from C++. While working on a managed language has its benefits, in C++/SDL I was able to redraw the entire screen, which was twice as large, in a fraction of the time and using less resources.

At least this limitation forces me to keep my project simpler!

donblas said...

I know what you mean. I was able to be much more wasteful when in came to the "drawing" of the screen, due to the speed of C/C++.

For me, the tradeoff made sense, as a few days of optimizations there have saved me mass pain in other areas of code :)