code before the egg

it's kind of a tradition for me; for every id game that comes out, i make a map viewer for it. with each generation of id games it gets easier and easier. same thing happened for doom3 (the leak actually). the process just becomes simpler and simpler because you need to rely on less and less tricks.

so if you were to ask me tomorrow morning to make a doom3 map viewer (with lighting and characters animating) in glut, i could just about have it to you by the time i had to go to sleep, *(well.. if i let the cats watch turing). if you would of asked me the day doom3 came out, same thing. it's not like i have gained any new useful skills that would speed the process. the project is pretty much trivial.

*the shaders are actually a kinda bitch to parse 100% because they are ambiguous and require a bunch of stupid special cases

so.. how can this be? how is it possible to visually duplicate something in such a short time when it required a whole ton of research to create in the first place?

it's because the real research was all the decisions that took place to get that data on disk. millions of tiny decisions that i don't need to know or care about went into how to persist that data.

so what if we just didn't make any of those decisions? what if we just got some data (really nice, just like we want our game to look) from our various terribly commercial modeling packages and exported them into some simple file-format.

now what if we just made a 'map viewer' of that data? how long would that take? probably not very long. it might run a little slow, but so what.

what if the process was done the other way? the typical way it is done. you start with some code and you slowly build an engine and art slowly goes into the game as the code can handle it?

i guess all i am saying in this post (and my flash post from yesterday) is that designing things from the programmers side might be a mistake. in the end we just want the data, so why not start with the data and make the software to work with it.

btw. yes.. yes.. a renderer is not a game engine. however.. a content path + a renderer + a physics engine + not using a stupid scripting language is getting close.. more on that + a physics engine bit in a later post.

[holy shit.. did you notice the ; up there.. some day i'll get the hang of this english writing thing.]