- I have a family with three kids.
- I am on the board of a local pre-school.
- I volounteer in the classroom of a local public school.
- I spend 60 hours a week on my work.
- I'm even remodeling my house right now, taking on a steep second mortgage for the enjoyment.
- What free time I have, I spend as much in online forums as in creating game code.
The only thing I could cut out of that list to add more time to creating a game, would be the online forums. All the other things on the list are more important. And perhaps I will cut that out.
Clearly, time is a precious resource. Even more precious than money, to some extent (I have some play money each month, but it's not substantial).
I've tried a number of existing game engines, both free and pay-for (I seem to collect licenses :-). Maybe I'll write a review sometime later. For now, let's short-list them:
- Torque Game Engine 1.4.2 -- too buggy
- Torque Game Engine 1.5 -- too buggy, and too slow
- C4 Engine -- too immature
- Nebula2, Irrlicht, Delta3D, etc -- all have various problems
- XNA -- mostly just a rendering API
I typically end up trying an engine, finding several bugs in the first evening, spending some time fixing two or three of them, and then giving up in disgust. The reason to use an engine is to not have to write, and thus debug, a bunch of code.
However, some libraries stand out as better performers than others, mostly because they are more solid. Among these are the ODE physics library, the LUA scripting language and the Ogre 3D graphics library. Actually, Ogre3D still has warts, but at this point, I've decided to live with them rather than find bliss somewhere else.
Curiously, the part where I find the most problems is in the art path. I'm not even an artist, but I believe that you should be able to develop an animated character in 3ds Max, and export it out, and use it in an engine, without any of the following problems:
1) crashes in the exporter or importer (way too common)
2) incompatibility with current tools (3ds Max 9 has been out for half a year now)
3) weird limitations on scale or orientation of the model (Torque's 1 unit == 1 meter with no scaling comes to mind)
4) art that mysteriously morphs when moving through the pipeline (I found this with Collada/C4)
I am the author of the kW X-port 3ds Max X file exporter, which solves a bunch of problems found in the DirectX SDK exporter or PandaSoft exporter. However, even that exporter has problems; some are known bugs in the 3ds Max 3DXI API which I'll have to work around, and some are me just not being able to figure out the interaction between Physique, the X file writing API, and the X file loading API -- neither of which documents any of the important inner details for things like coordinate reference frames, etc.
I almost turned the RayCar demo into a working game engine, but I don't want to write an engine; I want to write a game.
I almost wrote a working game engine on top of XNA, but again, I don't want to write an engine (and the lack of animation support in XNA doesn't help -- more of the same as I already have in the X exporter)
So, to create a game (not an engine), I will make this pledge:
1) Time is precious
2) I will not re-invent the wheel
3) Using existing libraries is always a win
4) Warts have to be accepted
I'll start with Ogre3D version 1.4rc1. I won't even get the source -- when I have the source, my inclination is to fix it (I have contributions in Ogre already), and I don't want to spend time fixing source.