Game Development Community

Using Torque objects and components

by Rich Marinaccio · in Torque X 2D · 07/16/2007 (7:34 am) · 2 replies

I'm sort of new to the aggregation method of programming. My question is, is there an advantage down the road to using TorqueObjects and TorqueComponents for every bit of C# code in my game, or should I only use that for things that will be directly on screen?

For example, when I'm coding purely abstract things like strategic AI and factions that have nothing to do with graphics, can I just do it the way I'm used to doing it in C# separate from the Torque library, or will I potentially be missing out on some of Torques strengths? I'm not yet sure if my project will be purely single player or allow multiplayer.
NextNext Thread
PrevPrevious Thread
More from Torque X 2D


Torque Owner Dan Maruschak
#1
07/16/2007 (9:39 am)
The decision about what is best for you is going to depend a lot on what works for you as a developer, but I'll try to give you some insight into why we like the aggregation model. We find that in games, it's a lot more comment to want to reuse "chunks of functionality" rather than to reuse complete objects. For example, it's far more likely that you'd want to reuse the "pathfinding" from an existing strategy game in a new RPG game than it is to want to reuse a "tank". With the traditional hierarchical inheritance model of programming, it's very easy for that "functionality" to have elements that exist in multiple levels of the class hierarchy, so it's harder to rip out and reuse for other objects in the same game or even in a different game. Using the hierarchical inheritance model, it's also common to get either class bloat or code duplication in order to achieve the needs of your game, since rearchitecting the class hierarchy can be a lot of work when you make decisions about functionality late in the process (which is common with games, since finding "fun" frequently requires experimentation, and you'll often drift quite a bit from your original design). With the aggregation model that components provide, we think it will be more common to code these "chunks of functionality" in a reusable way, since it's more "natural" to code components to be self-contained, and focused only on their slice of functionality.

Now, that's not to say that the traditional approach is worthless -- there are places where traditional hierarchical inheritance makes more sense, and we ourselves use inheritance in some places. We also believe that the most important thing is making progress and completing games, so you need to do what is going to be right for you.

Torque Owner Rich Marinaccio
#2
07/16/2007 (11:07 am)
I have found that, with the stuff I do, the inheritance model entails huge chunks of time redesigning things over and over to prevent things from getting ugly and confusing. I'm liking what I'm hearing so far with this aggregation thing.