Working with the XNA GS content manager is a mixed blessing. The content manager subscribes to this philosophy:
In a perfect world, we wouldn't check in our game-ready assets. We'd check in our raw, source assets only and our build systems will build them locally using the parameters we've defined. If you want to change the compression, resolution - or even maybe the gamma ramp or color saturation! - on a texture or mesh, you just tweak a number and then everyone, on their local machines, the next time they build, get the new parameter. Also, a change in an art asset would percolate through to all the levels on which that asset is used automatically. Most importantly it insures that the source assets are actually checked in.
Sounds pretty good, right? I've even heard it said that doing it the other way, the way where you manually build some of your game-ready assets and check those in, are an "antipattern in game development."
But if that's the case, how come most of the succesful studios I know do it the "antipattern" way (anyone using Unreal with its wad files, for example) and the teams I've heard of with the big fat build systems are catastrophic?
What I've found is that in this non-perfect world we live in, computers are just too slow for the "perfect" build system. Because for every file that you need to take down the chain from raw asset to finished shippable product, you have to do a dependency check. "Did this file or its parameters change?" And the dependency check takes finite time. And on your typical big-budget console or PC title, you have tens or maybe even hundreds of thousands of files. That's if nobody changed anything. It turns out it's way too much time to do every time you hit the "build" button (which is the way it currently is with XNAGS, which would probably have to changed or worked-around if you wanted to do a big-budget game with it).
So now you've got a choice - you can provide your artists two ways to get their assets into the game (the slow way, build everything; or a back door to get an individual texture in) at which point you no longer have the perfect build system...or you can make your artists suck it and wait a few minutes every time they actually want to see one of their changes in the game.
And that's for a build where nothing has changed. Typically, you come in the morning, you do an update/get/sync (whatever your asset control system calls it) and hundreds of files have changed because you're working on a team. YMMV, but this can take up to an hour depending on how much has changed and how slow your build processes are. So you've got your artists sitting idle in the morning, waiting. If they're working together on something, and need to pass assets back and forth, then after Person A checks in his change and Person B gets it, Person B has that up-to-an-hour wait to start working with Person A's stuff.
This isn't likely to change in the near future! The size of our games seems to be increasing just as fast as the speed of our hard-drives. Maybe even faster.
Which is why on most of my last projects we didn't subscribe to the "perfect build system" philosophy, as much as we would have liked to. Artists shepherded each asset from raw to console-ready and checked everything in.
The biggest problem with this sytem - and the reason the "perfect build" is so appealing - is an artist could forget to check in the source asset. Another artist might then work on the same asset by accident, or the first artists' hard drive might crash and the source asset might get lost forever! These problems don't happen often enough to be worth the cost of the "perfect build" - and they can be solved. The first problem can be solved by setting up the asset control system intelligently - the second problem can be solved by local backups.
XNA's content manager is tolerable for us, because we only have 2000 files. On my machine a nothing-changed build takes 15 seconds, which is fine (though I'd prefer 0 seconds), and less than our load times. If we had 20,000 files it would be a problem.
So, next time you're bitching about Unreal's wad files - just remember the alternative is worse!
Now, I expect a lot of comments after this post, because this has been good holy war material in sweng-gamedev, so let's have them!