Friday, December 05, 2003

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.*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!)

Wednesday, December 03, 2003

I like 'skill plateaus'

Ok, I read the comments. 'Skill plateaus' is the winner. Forget 'local minima'.

Andrew Rollings and Ernest Adams said that Valve's Cabal system was not the way to manage game development, because Valve had a highly skilled, veteran team that could handle it, and you don't. This is an example of skill plateaus in the game development game. The question: can you make a game the quality of Half-Life if you don't master that higher plateau?

I had another example of skill plataeus in the game development game but it's slipped my mind now. Brain cloud. And I have to go the gym. To be continued.

If you look at the word 'plateau' too long it looks really funny.


Props to Rafael for pointing out that there actually were comments on the last entries. Arg. The lure of typepad gets stronger. Also, he doesn't like 'local minima', for pretty good reasons...the 'local minima' aren't the expert, finesse strategies; they're the lesser, seemingly good strategies you find on the way to the absolute minimum.

BTW, yesterday we were discussing whether to change Spider-Man 2 to eliminate one of our local minima (although we didn't call it that), and James Chao pointed out that the tactic in question was like training wheels on the way to the best tactic. We're leaving it the way it is. Which is good; it's nice when decisions you make early in a project stay should take a landslide of approval from the team to reverse those decisions.

But maybe that's a way in which local minima can appeal to the mass market; as training wheels.

Must read those comments now.

Tuesday, December 02, 2003

I thought I invented that

Speaking of coining terms, I could of sworn I invented this years ago: heisenbug. Either:

a. It was so obvious somebody else came up with the same thing.

b. I heard it somewhere, forgot I heard it, and then mistakenly thought I coined it.

c. The people I used the term with thought it was so cool they spread it like a virus.

I'm going to choose to believe the last one, because that's the sort of arrogant, egocentric guy I am.

And back to "local minima": if people start using this as a game design term, remember who invented it. That's right: me, baby. Me. Yeah.