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 plumbing.

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.

Engine Overview

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 adding functionality.

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 the template.

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 handling this.

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 integration.

Torque 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 needed.

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).