Content Turnaround
A new episode of Manager In A Strange Land is up, and I don't remember it being that dense when I handed it in, but...there it is.
Gregg Tavares has already read it and had these points to add:
1) WAD files are only a half solution. Putting all your individual files into a wad file saves the time of opening a file which might involve a seek to the CDs table of contents but it doesn't save the all the seek time. What you really want and what most of the top console games do is make a system where you can almost load everything you need for a level in one big chuck straight out of the file, designed to be ready to use with a minimum of parsing. Instead of loading one model at a time or one texture at a time from indivudal files or wad files we load a level file (from a wad file) which has all the textures, models, sounds, need for that level or at least all the ones needed to get the level started assuming we are doing a spooling game.
2) 4 months sounds like a long time to get all your files from text to binary but I'm sure I don't know all the facts. My solution since about 1992 has been what I call a datalinker.
it's available here.
http://cvs.sourceforge.net/viewcvs.py/*checkout*/elibs/elibs/tools/mkloadob/mkloadob.htm?rev=HEAD&content-type=text/html
it takes a text readable file that has references to other files and builds something ready to be loaded. All my other tools either convert their formats to something this can parse or they convert to binary and those binaries get included in the level specification files that this linker uses to build a level file.
A big advantage is that basically there is only one format at least at a low level so there is only one low-level loading routine, one one pointer fixup routine and only one tool.
This linker was used on Gex 1 for 3DO and is also currently used at Sega of Japan. A similar linker was used for Gex 2 and Crash Team Racing for PSX.
3) Version numbers
I always put version numbers in my binary files. That way the code can check that the versions match and complain "version wrong". If I didn't do this then the game might crash trying to load an old file and it might take hours to figure out that someone just forgot to rebuild the level with the lastest version of some tools
4) Version folders
Since there are many developers working and not everybody is always using the same version of the source code a problem often appears where they are using an older version of the code and someone rebuilds the level they are working on and the version of the data for that level no longer matches the version of their code and they are not at a point that getting the lastest code is good for them
We solved that problem by having different folders for different version of the data. For example if a particular tool would normally store it's data in \\dataserver\gamex\levelbins we would instead have it use the version number of the data as a folder name so if the data was version 1.2 it would store the data in \\dataserver\gamex\levelbins\1.2\ That way, if some programmer changes the data format and changes the version number to 1.3, he can rebuild data knowing that his new data will not overwrite the data that other programmers, designers and artists are using.
I should mention that I suspect #4 may not make sense to some people. If you are making a game were building a level takes seconds or minutes then people generally build the levels on their own machine and version folders is probably not a big deal. If on the other hand you are making a game that takes hours to compute potential visible sets (ie, Jak & Daxter, Jak 2, Ratchet and Clank) then generally you have build machines that have enough memory to process levels that big and the results are stored on the net somewhere for everyone to use when they run the game. It's in that case that version folders are probably more important.
Anyway, I just thought I'd pass on those ideas. I'm sure they don't fit every project but they have worked for me up to now.
I agree with his points #1 & #3, and can only say with regards to #2 that he has no idea how many text file formats we have: patrol path, quad path, AI, entity, weapon, item, extra associated entity data, blah, blah, blah. Another team took the same engine and did a similar retrofit in a different way and it took them a similar amount of time. #4 sounds like a good idea although we aren't even at the stage where we're sharing data off the net. (But we're making steps to get there!)