The Parity Bit

My approach to creating a game is grounded in the I-don’t-know-enough-about-3d-graphics-to-design-an-engine philosophy; so, I went searching for an existing open-source engine.

I won’t hide my preference for projects which are object oriented. In fact, I’ll freely admit that I prefer object oriented solutions nearly to the exclusion of any other. I have let this preference be one of the primary guiding factors when choosing a 3d engine. In the end, I have two favorite engines: Ogre3d and jMonkey Engine.

I might as well also admit that I have a severe distaste for having to do my own memory management. Because of that loathing, I initially leaned towards the Java-based jMonkey Engine as opposed to the C++ Ogre3d. As it turns out, my choice of engines may depend on one other undecided factor: my choice of scripting language.

I simply must do my higher-level game logic and AI in some form of scripting language; everybody else is doing it – it’s the in thing to do. The way I see it, there are three reasons I might want to use a scripting language: scripting is more approachable; scripts offer on-the-fly reloading; and scripting is more productive.

As someone who has worked on game mods and level creation, I can certainly see the case for a scripting language being more approachable for modders; this extends to non-programmer content creators such as artists and level designers. Groovy is an excellent scripting language that integrates well with jME and Java, has easy-to-learn syntax and supported functionality for defining a domain-specific language. Now I want to use Groovy.

I can also see the case for on-the-fly changes — especially in light of interpreted languages that can be reloaded at runtime. It’s very exciting to think that it’s possible to write scripts in a way that allows the game actions to be recorded so when an error occurs I can stop, rewind, reload a modified script and continue from the point where the error showed up. Clearly this allows for swift bug fixes in the game and AI logic portion of the game. This blog entry about using a Lisp variant for game development highlights why this is a good thing. Now I want to use Clojure.

I readily bought into the first two reasons; it was the third reason I didn’t much understand. After all, I’m a programmer. I write code all the time and there’s nothing wrong with Java as a high-level language. How is a scripting language going to make me more productive? But as I delved deeper into information about scripting engines, I stumbled across this blog entry; although nearly three years old, the information seems to be relatively fresh. Now I want to use Stackless Python.

Because of the novelty, I think Stackless wins. In fact, its tipped the balance so much that now I’m willing to work with Ogre3d; because there isn’t an easy way to integrate Stackless with Java I’m willing to work with C++. Python integrates well with C++ and therefore with Ogre3d; in fact, there is already a set of Ogre3d bindings for Python (and therefore Stackless) in the form of the Python-Ogre project.

In the end, I want things to be simple. I love object oriented programming because it models the way the world works: we have objects, and they do things. I love the idea of modeling AI in Stackless because it allows me to make entities autonomous without the overhead of system threads and without the ugliness that comes with dealing these complicated algorithms during stolen rendering loop cycles.

This is all new to me; I’m still feeling out where the pitfalls might be. But, the way ahead looks clear for Stackless, Python-Ogre and Ogre3d – at least for proof of concept.