Refactoring code

This past month the IndieZen crew has been busily refactoring a few of our open source libraries and frameworks.

The Physics framework in Zen Engine has been getting a huge revamp. "Az", one of the colorful developers working on the project, has taken the original version, which was mostly just a thin wrapper over Newton Game Dynamics and turned it into something more akin to Physics Abstraction Layer.

I looked long and hard at PAL before deciding not to use it. PAL is well written, has a great license, and as far as software goes, there's nothing wrong with it. It just didn't fit well within our architecture.

The IndieZen coding style outlined by our architectural documents states that all public interfaces must be pure abstract classes without any leakage of implementation details.

We also have a great plugin system based loosely on Eclipse.

I wanted our physics framework to follow this, so instead of using PAL and/or writing a new facade for it, we decided we'd take our "Newton-esque" design and revamp it so that it would fit with using a variety of physics libraries.

The refactored code takes advantage of the Zen Core plugin system, and uses the same high-quality software design, style and architecture of the rest of the IndieZen code.

The refactor is still ongoing and will likely take another month or two, but in the end, we'll have support for Newton 2, Bullet, PhysX and ODE on a variety of platorms (Linux, Mac OS X, Windows).


The next major refactor area has been the Scripting framework which is part of Zen Core. While no new functionality has been added, this refactor is making it significantly easier to expose C++ classes to scripting languages.

Boost Python was my inspiration while tackling these new templates, but since it targets our scripting framework instead of directly using Python, this gives us the added advantage of being able to write one binding and target Lua, Python and Tamarin without needing to recompile. The scripting engine is loaded as a plugin at runtime.

As we add support for other languages as plugins (AngelScript, GameMonkey, Squirrel, etc), the same bindings should still work.


We've also made some enhancements to our Event system, adding support for multi-threaded events and event queues and providing a mechanism to marshal the events to specified threads... script events are only handled by scripting thread, render events are only handled by rendering thread(s), etc. We still have more features to add (prioritized event queues, and event queue templates that can handle a variety of payloads), but that will be another iteration.

The Event system enhancements will greatly simplify the use of multiple threads in both the game engine framework as well as the IDE shell.


The final enhancements has been part of Zen Enterprise, our enterprise application stack. Mostly the enhancements have been related to making it easier to specify message handlers.


I'm finding that while using pure abstract classes as the "API" portion of the framework, when I end up making "helper classes" that ease the use of the API, I'm using a whole lot of generics / templates.

The scripting enhancements used some of the fancier techniques available in C++, including templates, partial specialization and type traits. It's actually quite magical if you've never seen something like it before.

I'm looking forward to our next iteration... I'm not exactly sure what we'll be doing but I'm sure it'll be something along the lines of more integration with Ogitor. As another art pipeline we're also considering GameKit / OgreKit... either integrating with it or modifying it so that it uses our framework or... well, as I said, I'm not sure yet. I'll see it when I get there.

Thanks for reading!