It was roughly two years ago, when Phil Carlisle told me about the Component Architecture and how he uses it in his game project. The idea literally exploded in my Mind and I had to try it. So I forked out a vanilla copy of Torque 3D (1.1 beta 3, later upgraded to 1.1 final), did some research and got cracking. At first it was just an experiment, and the source still resides in the “experimental” branch, but since then it has grown and after it compiled and rendered again, it was fabulous. The more I worked on it, the more it became clear that it didn’t take much to make this a great tool and made it much easier to use Torques potential, so I decided to see this through and build that engine mod to completion.
The name came to me while coding on it and while I don’t remember in detail how I actually came about that name, it seemed fitting. Heka is the ancient Egyptian god of magic and creation. And what better name for an engine (mod) that gives you easy, flexible and powerful tools to create worlds?
Unbeknownst to me, Unity went down a similar path, actually using similar and sometimes the same names and concepts for similar components. While this at first made me think “Oh great, I reinvented the wheel. Again.” some research showed that I already implemented some features that aren’t present/possible without modifications to Unity. Also, given the limited budget of our project, Torque still is a valid and viable choice.
If you still ask yourself “What’s so great about Components?” let me use some well sounding words to pitch this to you.
Components work like a wrapper for individual object features. The base container for components in this case is a lightweight object containing spatial information. Imagine it like the very idea of A piece of space defined by position, rotation and extent. You then add the components that represent the features you want that object to have. E.g. you want it to have visible geometry, so you add a component holding model or terrain information, a component tying it into the rendering process and a component to enable collision checks for raycasts. If you want it to be fance, add a component that implements the physics features of the object. And voila. While this looks a bit over the top for objects that already did this wrapped into a single class in vanilla Torque, it gets really handy when you want to do anything beyond that, which required either a lot of scripting or even a change in the source. In the component model, you simply add more components or remove those that you don’t want. E.g. if nothing (not even raycasts) is meant to hit your object, remove those components. If you don’t need the model to be animated, leave away the animation component. Or if you want some special kind of animation, add the corresponding component.
So this not only enables you to create objects as slim and flexible as possible, but also as specific as necessary. You can have components that implement a feature in a basic or much more advanced way, whenever you need it. It also ensures compatibility among the same component type, independent of the other feature components added to the base object.
The base objects themselves have some noteworthy features. Since the base object (like currently all components) derives from a SimGroup (a container class for SimObjects, the basic console-trackable class in Torque), you can add those base objects into each other like any other type of component. Since those base objects are spatial components, they inherit their spatial attributes from their respective parents. This means, the child object will stay in the relative position towards its parent, no matter the actual rotation and position of the parent. This way, you can define subspaces on an object. Examples for the use of such subspaces are mount points, additional lighting, attached objects or chain-like combined objects. Since the spatial components that are linked that way actually behave like nodes on a rigged model, you can actually animate them, making it possible to build big, animated structures out of them.
It will also greatly improve the flexibility and customization options of AI, since you only need to add a corresponding AI component to the mix to make it behave. And I’m not only talking autonomous AI, but also AI enhanced user controllers. The interaction of AI controllers with the game world is also greatly enhanced by components, since it doesn’t have to check for explicit types, but only the presence of certain necessary components in the object it wants to interact with.
The transfer to components also had the more than welcomed side effect of fully implemented and unified physics. In vanilla Torque, there’s at least three different system responsible, in one way or another, for physics simulation. Heka only uses the actually linked physics engine (primarily Bullet, but with the Physics Abstraction Layer still intact to allow for implementation in PhysX, too) for all physics purposes, including vehicles of all sorts (wheeled vehicles, boats, helos etc). So you only have two representations of geometry, one for rendered (complex) geometry and one for physical (simplified) geometry.
The component approach is also a blessing for small teams with few to no programmers, since new features will be most likely achievable by recombining certain components, which in a more traditional architecture would have called for a source modification. This shifts the responsibility, but also general ability to create new features and implement the game world more towards designers.
Besides the obvious changes that components introduce, I also changed little and big things all over the place to make using the engine even more intuitive and accessible. It is no longer possible to run a client and a server in the same instance of the program, hence eliminating a lot of duplicated code and features and generally unifying data management.
While the initial design of Heka is geared towards Singleplayer, the necessary ties for networked use are still in place and will be reactivated later.