2) The build system. Just like you do for your code, you create a type of "makefile" for your assets, often for a custom built build-system, but possibly also for an off-the-shelf one (e.g. XNA uses msbuild). Whenever you've updated some assets (e.g. saved/edited them, or updated SVN, etc) you run your build-script, which uses timestamps/hashes etc to only recompile the necessary files. The game doesn't contain any parsing/compilation code (just simple binary loading code); all the parsing/compilation code is pulled out into separate tools that are used by the build system.If you want to support modding, you can also ship the build system.
This seems very straightforward, and it will almost certainly make disk IO the loading bottleneck - which I can handle with overlapped reads.
3) The persistent build system. As above, but the build system sits in your system tray all day and watches your source asset directory. Whenever you change a file, it automatically recompiles it in the background. If the game is running, then when it's complete, it sends the game a message telling it to reload the modified file.
This seems very fancy Is there a preferred way of the directory watcher communicating with the game? My first thoughts would be some kind of shared Win32 event, or a named pipe. Or perhaps the game listening locally on UDP?
Thanks again.