One of the main things were going to have to worry about in this project is the concept of accessing and implementing file formats. Particularly, we'll need to use some sort of 3D modeller format. We could always write our own format, being that we may want to record properties that are particular to our needs (for example, this wall is rubbery and we can bounce off of it or this character will jiggle like jello when hit). Actually, I'm quite fond of recording objects and worlds in this nature, considering both of those previous examples would require the polygons to be dynamic in terms of object interaction rather than staticly placed for the run of the game.
Even if we do choose this, we would need to write a converter utility from whatever application our 3D artists work in. Currently, Jeff Campen likes his 3D Metatools Infini-D and I'm particularly fond of Rhino since it's available on every lab computer. Also, I downloaded the Rhino source for writing a Rhino file-type plug-in from their website. Professor Wolfe gave us the URL for a great converter app. Maybe we could make use of it so we can draw i any format and do a final imput into the game in a single file type. Well, that's a question.
The next file type would be that of standard image files. Then we need to think about movie formats: AVI, MPEG, etc. For a good source on architecture and compression/decompression algs, try Codec Central. We also need to worry about sound and music further down the road.
So what does this all mean? Well, a data file is generally like this: some header info, a spacer, then the data, and it's all encoded. 3D modeller files are easier because they're generally text and can be read and understood. However, with an image, sound, or movie, we would need to learn how the file format works. Then, we would need to write a data parser and input functions to bring the file into the game and use it.
Sounds complex? It's what we live for! I've seen how these work before in a couple different places and their not deathly scary. I know a gentleman who wrote a 3D converter in three hours. The encoded data would be a little more tricky because it would require some research and careful monitoring.
Well, that's something to think about, all you programmers.
-nick