The Campaign

I'm at the stage of personally begging people to help fund this project. At $750 total, with only $200 remaining, we'd be crazy not to push it over the line somehow. I guess this is coming a little late, at 5 hours before the campaign closes, but frankly, I thought we as a community would have pulled together before now.

I'm not sure why people haven't been funding the project. It seems to me there are two potential reasons. The first being they don't know about it. I can't really help that, beyond posting the campaign in a couple of places I frequent. The second is that people don't understand what a component/entity system is or why it'd be beneficial to Torque. That, I can try to do something about.

So, without further ado: three reasons why T3D needs this upgrade. I'll be basing most of this post on this excellent article by Mick West that introduced me to the component/entity model.

1. T3D is falling into the blobject trap

Okay, I don't think anyone else calls it blobject - it's technically known as a blob anti-pattern, god object or god class. It means a single class that accumulates a bunch of different functionality, becoming incredibly bloated and difficult to maintain. Sound familiar? Spoilers: ShapeBase matches this definition exactly, and Player is also a good example. Here's what Mick has to say about blobjects:

Quote:Even fairly simple objects such as rocks or grenades can end up with a large amount of additional functionality (and associated member variables, and possibly unnecessary execution of member functions). ... Functionality now becomes compartmentalized, so that only the objects specifically programmed for that particular functionality can use it. Programmers often duplicate code to mirror functionality already implemented in a different object. Eventually messy re-factoring is required by re-structuring the class hierarchy to move and combine functionality.

To paraphrase slightly, when the blobject appears, it makes the engine less flexible (because functionality is compartmentalised), less performant (because of classes derived from the blobject that don't need all its features), and more difficult to fix later (because code inside the blobject tends to be tricky to unravel).

2. T3D is FPS-focused

I'm not going to beat about the bush. You can make any type of game you want in T3D. Heck, you could rewrite the entire engine so it's identical to idTech 4. But the reason people use a game engine is so they don't have to do that. The question is not whether you can make any type of game in T3D, it's whether you'd want to. Because if you wouldn't, you move on to another engine that doesn't require lots of C++ hacking and workarounds.

Where I'm going with this is that T3D is not conducive to creating new styles of gameplay. It makes lots of assumptions and optimisations for FPS/TPS games, which were obviously necessary and desirable in Tribes 2, but aren't in a general-purpose game engine. A good example that's bitten me recently is the way tabled Player action animations interact poorly with custom ones. This is a useful paradigm if you want your code to be stable and efficient when using those tabled animations, and you don't use the untabled ones for anything significant. But for me, it was just an impediment to making the specific custom animations I wanted for my little AI men.

Here's Mick again on the benefits they discovered after implementing their component/entity model:

Quote:We created a system of data-driven object creation, so that entirely new types of object could be created by the designers. This proved invaluable in the speedy creation and configuration of new types of objects.

Sound like something you'd like T3D users to be able to do? Does to me.

3. T3D is difficult to add on to

(I mean the scripts, mostly - the engine code itself I can forgive a bit more.)

Partly because of the way the script templates are organised, and parly because of the deep class hierarchy, it's not extremely easy to go about adding changes to T3D. Add-ons, even script-only ones like the UAISK, typically require detailed installation instructions that have many points of failure for inexperienced (and even experienced!) users, and need to change with every new version of the script templates.

For example, my script addon might want to do something every time a character dies. Like make a burst of confetti. This requires adding code to the Armor::onDeath (or whatever it's called) function, modifying the existing code, which has to be done by the user (unless they've made no changes of their own to the scripts). Assuming they're even using the default script template!

With a component/entity system, adding this functionality would be a matter of defining a new component in an entirely separate file that can be added to anybody's project, and then, with Jeff's editor plugin, modifying the object template to include the new component. And if I wanted the same effect to happen when vehicles are destroyed, I add the component to the Item template, rather than duplicating the code, or adding it to ShapeBase and having it apply to Vehicles when I don't want it to.

So please,

Support this campaign. I'm imploring you. If you haven't pledged yet, now is the time. If you have, and you can spare a few more dollars, IGG allows you to pledge multiple times!

The Campaign