The cornerstone of any project is having a reliable build process[0]. For a game this includes the code as well as any art assets that need processing. The goal of the build pipeline is to build everything the same way on everyone's machine every time. In order to get this to happen the build pipeline must properly check dependencies and there can't be any user intervention during the build process.
If the build process fails to check dependencies or requires additional user steps then it's possible to throw your code & assets into an undefined state. This is Bad. Bad like using variables before setting them. Bad like driving your car while blindfolded.
Tracking down a bug that's only there because Joe Beanbrain clicked the wrong button during the art build only serves to waste the time of the development team. What's just as bad is if Joe Beanbrain clicked the wrong button and a bug doesn't show up until much later when the problem is harder to track down and correct.
Even worse is if the dependencies are improperly detected and bugs are introduced that go undetected because assets weren't rebuilt when a file changed. Typically these bugs are tracked down late at night while looking through source control logs after discovering new ways of arranging four letter words in conjunction with the name of someone who left hours ago and is now unreachable.
I've had good luck setting up build pipelines using gnu make under cygwin. I've talked with some people who have had good luck using perl scripts for asset processing. Some tools are not well suited for use with make and so using perl (or python, or ruby, or whatever) might be a better choice. The point is that you need that reliable build process.
Now, assuming you have that reliable build process that works without assistance, you suddenly have the option of doing automated builds late at night. On my last project our night build was set up to modify a .h file to increment a build number[1], wipe the directory tree[2], build everything for all platforms, and then put .zip files up to the network. This lets everyone run with latest assets and it produces a series of snapshots that allow for fast rollback testing to determine when bugs were introduced.
So, please, take the time to make that build pipeline work correctly. It prevents developers from trying to kill each other.
[0] Technically, having electricity and non-collapsing floors might be more critical, but I'd categorize those as "management problems".
[1] Having on screen build numbers eliminates 75% of phantom bugs from QA.
[2] This helps to track down problems where files had been deleted from source safe were still lingering on local drives.
The build process becomes even better when some of the involved tools over which you have no control do not generate repeatable output.
We built a decent automation system with cygwin, perl, some custom stuff... But when it came to exporting data from 3DSMax, it was different (via a binary diff) every single freakin' time. Probably some stupid date or something. It also didn't help that things got corrupt when exporting from the server.
God, I *love* 3DSMax.
Posted by: Matthew at May 15, 2003 10:45 PMExporting data from modeling packages is always a pain. I've completely sworn off of writting modeling exporters after the last time I had to write one. The exporter worked fine but it was supposed to have a secondary munge process that generated track data (it was for a racing game) based off the geometry and naming conventions of the model.
Posted by: Matt at May 17, 2003 01:19 PM