38. A 3D CG FMV CD-ROM Game
In the mid-90’s, Apple's QuickTime VR was a hot new technology. Around the same time, Myst was the hot CD-ROM game.
So of course I decided to make a CD-ROM computer game based on QuickTime VR. It would combine what we used to call FMV (full motion video) and 3D CG environments with QTVR scenes.
I wrote what I thought (and still think) was an interesting and original science fiction story for the game. The player character boards an apparently abandoned spaceship and has to figure how to bring its systems back to life by traveling between various QTVR nodes representing key locations on board the ship. As he does so, snippets of video intrude on his consciousness, which may or may not be showing him what happened to the crew. The whole thing ends with major revelations, plot twists, and bravura storytelling. Great stuff, if I may toot my own horn.
For the project, which was called “Encounter”, I teamed up with my producer friend John and we got some investment from a local Montreal production company. Enough to produce a demo of the game.
We bought a Power Mac 9500, some 3D modeling and rendering software (FormZ), Macromedia Director and got down to work.
While I spent my days modeling 3D environments based on the (very cool) concept art created for the game, John began putting together a production crew and casting actors in preparation for shooting the video footage we were going to green screen into the CG spaceship scenes.
This would be my first time directing actors. Live ones, not computer generated.
Code & Design
Warning: this post may induce (more) pearl clutching if you care about code efficiency.
I ran the profiler on the sweep-mesh-group depicted in the image above, and the results, after some minor optimizations, are listed here.
The actual scene takes about 2 seconds to update. The rest of the time is profiling overhead (probably including swap overhead and what have you). Spinning beachball action was definitely observed.
The minor optimizations resulted in about a 2x speed up, which shows that the code is (as I knew) far from being optimized. In fact as I suspected there is significant observable overhead from the point and color data structures. At least 20%, and probably more.
I could use declarations for inlining and types, as well as reduce consing. I suspect a lot of unnecessary consing is taking place because of the prevalent use of lists due to the pedagogical roots of the software. Replacing these with arrays could help reduce consing.
Finally, there is the option of implementing points and matrices as C libraries, though that will complicate memory management and result in dealing with FFI (foreign function interface) cruft. I’ll probably refrain from doing that.
In fact, I will probably defer further optimization until (someday) I reorganize the code in a major way, possibly by changing Common Lisp implementations in the process. Stay tuned.
