Texel's Technical Tribulations Pt. 1

I've been a programmer in the Gaming Industry for a number of years now, and I have had the opportunity to work with a few engines. So I am fortunate in that now I am able to try my hand at making my own. As I develop the "Texel Engine" I will make it a point to talk about some of the decisions I've made and the benefits/consequences therein.

The first subject I would like to talk about is the notion of Reflection in modern programming languages (Wiki on Reflection). I was first introduced to Reflection when I was working on an Asp.net website back in 2002-ish. I really liked the concept, and thought it had important implications in Game Development. The largest issue I faced with it; is that C++ doesn't support this (It has RTTI, but not to the extent that I would want). I chose C++ instead of something like Mono because Apple had banned it in earlier versions of their SDK, and I wasn't sure that was entirely over. Now days, this has become more common in C++ based games. For instance, the Doom 3 Engine had a reflection like system for interfacing with their scripting system. So I did some research and this Article sums up the most common approaches to Reflection in C++. I chose option 2 the preprocessor. I figured this approach would have an initial investment that would pay off in spades later (Plus it was flexible enough to allow me to gloss over some aspects). I added some blank preprocessor defines that my reflection builder would look for, and alter its behavior accordingly. Here is an example object:

reflect class Button : public Container {

DECLARE_OBJECT( Button, Container );


Button( void ) { IsPressed = false; }

virtual ~Button( void ) { }

virtual bool Load( void );

virtual bool Unload( void );

reflect public:

script bool Press( void );

input bool Activate( InputManager* manager, const ButtonEvent& event );


reflect protected:

ScriptBlock Action;

Effect Pressed;


bool IsPressed;


So, you'll notice the keywords reflect, script, input, and InputBindings. These are preprocessor macros that are defined to be blank. The Reflection Builder looks for them and generates the necessary data (It will skip over the sections not marked as reflect). I've especially enjoyed the script and input directives because it makes it incredibly easy to hook into the various user controls, and to generate function wrappers for scripts. The last thing that's nice, is that all the names for the reflection information can be externalized into a separate file, and out of the code.