What is Torque X?
Torque X is a game engine. A game engine is a set of tools to make
game development easier. When you start developing your game, you have
the choice of writing all your code from scratch, or building it on top
of someone else's work. Writing a game from scratch can be a good option
for experienced developers, since you have maximum control over the
architecture of the code you develop.
But it will take even an experienced developer a while to implement all
the needed code, because there is a lot of work that must be done to
build a modern game. It is also the case that technology developed for a
specific game is often tied to the design of that game, and the work
done is not easily reused for other game types.
In Torque X, we have abstracted out some of the key problems of game
development and come up with solutions for them. Problems such as, how
do I put objects into my scene? How do they interact with each other?
How do the player(s) interact with the objects and each other? How do I
extend the objects to give them new behavior?
Whether you use Torque X or not, you will have to confront these
problems. By using Torque X you can take advantage of the fact that we
have already thought about these problems and come up with good
solutions for them. This means you can spend more time working on your
actual game and less time working on the plumbing. A big cause of game
projects never getting finished is developers who are obsessed with
Use Torque X and you will be able to work on the meat of the game,
gameplay, a lot sooner than you would if you started from scratch. This
is one big advantage of using it. Another big advantage is that once you
have completed a game, you are more likely to be able to reuse that
work for future games, so you'll be able to develop those games faster
than your first game.
There are many other advantages too. For example, since you are working
with a standard engine -- Torque X -- you'll be able to attract other
developers who have also used Torque X, and they will be able to get up
to speed on your project faster since they don't have to figure out a
custom system that you have built.
Another advantage is that you've essentially "outsourced" the engine
development to the Torque team: while you are working on your game,
we'll be working on improving the engine and adding features that you
can take advantage of in future games. There are a lot of other
advantages, but you get the idea.
Torque X makes game development easier than ever. We've combined
several high level ideas into one engine. One of the primary roadblocks
one runs into in game development is what is often referred to as
Frankenstein game classes. This can lead to some awkward code sharing in
the base class and some "copy-paste" code sharing in the derived
classes. This is a common experience when using an inheritance model for
In Torque X we have moved toward aggregation rather than an inheritance
model. What this means is that instead of putting functionality in a
common base class, game objects share common components which provide
that functionality. If your object needs animation you add an animation
component, if you need a specialized animation system, write a component
for that and add that component, if your object needs a jet pack add
it, if not don't add it. Aggregation leads to much more code re-use and
less "copy-paste" code sharing.
Another important concept that Torque X has embraced is the ability to
deserialize objects from xml, allowing easy editor integration. Because
Torque X is written in C# it has superior reflection methods at it's
disposal, so deserializing doesn't generally require any special code.
Our xml deserializer also allows objects to reference other objects, so
complex links between objects can be supported (e.g., you can associate a
projectile defined in the xml with a gun defined in the xml so that
this instance of the gun will fire that projectile type). Because of the
flexibility built into our component system, one can often deserialize
objects from xml without needing any special coding for that object.
When an object is deserialized from xml, it is either added to the world
then and there (this is generally what one wants when loading a level)
or it is a template. Template objects are not added to the game, they
are simply there to be cloned (a template is essentially an object
factory). You can design your enemy types in the editor, mounting
particular weapons on them, associating specific ai, save them off as a
template and then instantiate them in the game over and over by cloning
Because XNA is a managed development environment one has to be wary of
garbage collection. If your game is allocating too much memory you may
suffer from frequent garbage collections. This can result in hitching
behavior or pauses in game play. Torque X has built in methods for
When you create an object template, you can mark it as a pooling object.
When a pooling object is removed from the game, it is added to an
object pool for that type of object so that the next time the game needs
one of those objects it won't have to allocate a new one.
Because you can turn this feature on and off selectively on objects
(rather being restricted to certain classes) you have a great deal of
control over it. Results will vary between games, but our guess is that
you will want to turn on object pooling for projectiles and explosions
and other things which are created many and often, but probably not turn
it on for game objects with longer lifetimes.
Thankfully, you'll have this level of control when it comes time to fine
tune your game for performance. A fair amount of sophistication goes
into this feature but it all happens under the hood.
Of course, Torque X also has it's share of support for rendering, sound,
input, GUI's. It provides polygon level swept collision detection and
rigid body physics, sophisticated support for shaderized sprites with a
specialized 2D lighting model.
But what really sets it apart is the framework it provides for
organizing your game data and writing your game objects and it's editor
X Object and Data Model
The central class in Torque X is TorqueObject. All game objects are
TorqueObjects. The most important feature of TorqueObjects is the
ability to add TorqueComponents, which will be discussed in more detail
below. TorqueObjects also provide some basic managerial services like
the ability to be named or looked up by name, they have an associated id
(and can be looked up by id). One can also point a TorqueSafePtr at a
TorqueObject and that pointer will be valid only as long as that object
is still alive in the game.
The lifetime of a TorqueObject begins when it is new'ed in code or
deserialized from xml. But it does not become live in the game until it
is added to the TorqueObjectDatabase. At this point the object is
registered with the scene graph (assuming it has a rendering or
collision component) and any other initialization functions that are
needed before it becomes active are performed.
When it has served it's purpose in the game it is unregistered from the
TorqueObjectDatabase, at which time any cleanup occurs and any
TorqueSafePtr which points to it is cleared out. If the object is marked
as a poolable object then it is added to the appropriate object pool.
The preferred method of creating objects in Torque X is to create a
template of the object in XML or using the editor (the object should
have the IsTemplate flag set) and to clone the template whenever an
object of this type is desired. This does mean that any data associated
with an object will be copied whenever a new version of an object is
There are certain times when this might require a lot of copying. In
those cases, it is a good idea to separate out class and instance data
(i.e., data that is constant for all objects of this type vs data that
varies by instance) and put the class data in a separate object which
can simply be referenced by the instances (so only a reference to the
data needs to be copied rather than all of the data).