Project Z is a term i came up with to describe my activities related to the Z game development library, the Z "game engine", and other related technologies.
All programmers start to build up a library of useful code over time. its their "bag of tricks".
Mine originally evolved as a collection of useful routines that could be used again and again to build games. Things like a function that implements rolling dice, and high precision timers. It was originally written in pascal, and DOS was the OS at the time.
I used to sell my library for use with Borland Pascal 6 and 7, and Borland C 4.0. When i switched to Watcom C for speed, i ported the library to Watcom, but never released it again. It later grew to include a complete 3d poly engine, as well as support for midi and cd quality digital audio.
I got out of game development for a while. When i got back into it, the library was re-written from scratch to work with windows and directx.
I got out of game development again. When i got back into it, the library was re-written again from scratch to use the latest version of DIrectX. At this time i used it to write a prototype game engine that was called the Z engine. Although it was just an in-house R&D project, it was good enough that the artist i was working with at the time could use it to build a shooter.
I got out of game development a THIRD time! When i got back into it again (this time) the library was once again re-written from scratch. But i didn't know what to call it. It hadn't had a name other than "my game library" since it was sold under the titles BP60LIB, BP70LIB, and BC40LIB. since i need a name of some sort just for file naming, i chose Z, from the name for the old prototype engine. Since the library was being written to work with direct3D, the library ended up being called Z3D.cpp and Z3D.h, even though its much more than just 3D graphics code.
I now use the current version for building games and for experimenting with game code architecture.
in its current form, the library consists of one .cpp file of about 5600 lines of code. Its currently designed to work with directX 9.0c fixed function pipeline as that's sufficient for my needs at the moment. However it has also been tested with Directx 11, and a prototype of a directx 11 version already exists. It includes things like data structures and functions for storing meshes, textures, materials, models, and animations in memory (asset managers? or "databases" as i call them), and a render queue with state manager built-in. Its also implements a wide variety of useful functions for timers, file i/o, string conversion, etc. it also includes a rigid body modeling and animation system.
there is a second module to the library. its the modeling and animation editor for the rigid body system in the library. its a stand alone module that uses the library and can be linked into any game to instantly provide and in-game rigid body modeling and animation editor.
recently i stared working on a generic "active entities list" for the library. This quickly evolved into a test bed "engine" which i'm now using to experiment with game engine design and to explore just how generic an engine / library system can be.
Another related technology is CScript, a macro processor / code generator for C++. Its designed to help speed up coding. its lets you enter code using a "shorthand" syntax. it then translates the "shorthand" code into ready to compile C++ source code. You can freely mix CScript and C++ syntax in a CScrpit source file. So using CScript with existing game code is as simple as making a copy of your .cpp file with a .cs (for CScrpit) extension. You can then immediately start coding in the Cscript file using BOTH CScript and C++, as you prefer. CScript doesn't make you give up C++ or anything in it. It simply augments it with shorthand syntax designed to reduce keystrokes.