Working With Torque

Torque as a Game Engine

Game engines are designed to handle and manage a large majority of the low level requirements of complex games. They serve as an integrated environment for your games to operate within, managing many of the complex but fundamentally important requirements of any game, from basic FPS's all the way to complex RPGS. Just a few of the major systems and capabilities Torque manages for you include:

  • Memory Management
  • Object Instantiation, Referencing, Messaging, and Deletion
  • Resource Management
  • Graphics Hardware Abstraction
  • Sound Hardware Abstraction
  • Streaming, Event, and Client/Server Synchronization Networking
  • much, much more!

In addition to handling so many of the boring, low level details, Torque also provides reference implementations for more complex game structures, with many example Game Projects for study and use. It's important to understand however that these examples are for reference--every game will require additional development to implement game specific requirements, and it is fully expected that you will need to learn the underlying operation and theory of the engine to accomplish your goals.

Using a Game Engine

One of the things that confuses many people who have made games before, but not worked within an engine framework, is that many of the low level systems appear hidden, or hard to find for beginners. it's important to realize that is intentional! The biggest benefit of using a game engine instead of implementing everything needed from scratch, or from a hodge podge of external libraries, is that you can avoid having to worry about all of the hundreds, if not thousands of details that are critical, but also distract you from focusing on making your game--after all, you are here to implement your dream game, and having to worry about all the details that ultimately have nothing to do with your vision (but are required to meet your vision) isn't something you want to worry about.

Later on in this document we will be giving introductions to some of the underlying systems, but early on in your game development process, it's best to focus on learning to work with Torque, instead of trying to adapt Torque to your previous experiences. For example, if the first thing that comes to mind when getting started is "Where's the Main() loop?", then you probably want to reset your approach!

Torque is designed to provide you abstracted access to hardware, memory, input/output devices, and many other aspects of game development, isolating you from the low level details so you can focus on your game. We'll discuss concepts such as Event Driven Simulations, Interfacing TorqueScript with C++, and general game engine approaches in the sections below.

Working with an Event Driven Simulation

Sounds scary, but once you become familiar with the concept, event driven simulations are very intuitive ways to make games. The premise behind this concept is that within our game world, everything exists as an object, and these objects interact over time with each other, and the players to make things happen.

It's very much like the real world if you think about it--when we wake up in the morning, it's probably due to an alarm going off (an event), which triggers an action--we reach over and hit the snooze button (an input). The input of hitting the snooze button in turn is an event to the "alarm clock" object, and it reacts to that event by turning off the alarm noise and waiting for 9 minutes to trigger another alarm event.

This concept is how we program with Torque--we implement a set of objects, and define events that can occur for those objects, and then implement handlers (called Callbacks) to manage the events as they come.

In effect, we give up direct control over the game itself, and instead design each object to interact and react with the objects around them, as well as inputs from the players, as well as time passing within our world. This style fits very well within the concepts of Object Oriented Programming, and allows us to achieve very complex interactions very easily.

Layers of Game Development

Torque is designed to operate at 3 different levels:

  • Systems Management--the engine taking care of business for you
  • Object Implementation--code you have written (or derived from the Game Examples) to implement capabilities for objects
  • Gamplay Implementation--code that uses capabilities you have implemented to describe game play

At the systems management level, Torque takes care of all the work for you--that's all the hundreds of thousands of lines of source code that operates in the background, saving you months of development effort. As a Game Developer, you should probably not need to deal with the Systems Management layer very much at all.

However, even though the various Game Examples demonstrate many complex and cool capabilities, Torque does not do everything that you will want your game to do, so you will need to hunker down and get to work! This is where the Object Implementation layer comes in--you will be utilizing C++ (or in some cases, skipping directly to the Gameplay Implementation layer if the example games provide exactly what you need already) to describe and implement how your objects interact with the world.

Finally, the Gamplay Implementation layer is where you will be implementing how your game works--from spawning the player to reacting to collisions, to keeping track of teams and score, this layer is where you create your world.

The Zen of Networking

Network architecture is an incredibly complex subject, and Torque is known world wide for having one of the best networking architectures in game development. This is a great thing for aspiring and experienced game developers alike--but it adds a layer of complexity that can cause confusion and frustration for anyone first getting their feet wet with the engine, so let's discuss a few key principles of a networked engine architecture:

I'm a Client, You're the Server

There is one key principle to understand when working with Torque: No matter what type of game you are making, the stock engine expects that there will always be both a client and a server--even on a single computer!

This is a very powerful thing when it comes to game development--when a game is implemented correctly (keeping this principle in mind) with Torque, it is pretty much automatically multi-player ready! That comes at a price in some ways however in both development complexity and footprint, but for a very large majority of games today, it's well worth the extra effort.

There are dozens of reasons and benefits behind why this is a good architecture for a game engine--here are just a few:

  • Automatic Multi-Player capability
  • Built in game security (anti-hack/anti-cheat)
  • Flexible Deployment
  • Adaptable Gameplay

As mentioned however, there are some costs associated with this architecture, including:

  • Larger game footprint for single player games
  • Coupled object implementations (physics and networking tightly tied together)
  • Somewhat more complex implementations for certain tasks

Network Architecture Modes

There are three primary modes of Client/Server Interaction:

  • Single Player--the server and the client exist in a single executable, sharing memory
  • Hosted Multi-Player--the server shares an executable (as above) with one client, and other clients connect via a network
  • Dedicated Server--the server stands alone, and all clients connect via a network

Each of the three modes listed above have different primary uses, and as your game evolves you will select the most appropriate mode.

Who does what, when?

Since all games developed with Torque will have both a client and a server, it's important to understand what each is responsible for, and where you should implement a particular capability for your game. Whenever you are thinking about an aspect of your project, you should always be asking yourself, "Should that happen on the client, or the server?"--and in the situations where the other side of the architecture needs to be aware of something happening elsewhere, how to communicate between the two.

  • Server Roles--Anything that affects the game world should happen on the server, and communicated to clients as appropriate
    • Physics
    • Collision
    • World Object Manipulation
    • World State Management
  • Client Roles--Interactions with the player should happen on the client, and communicated with the server
    • Input
    • Rendering
    • Sound
    • Graphical User Information

Torque provides a variety of ways to communicate between the server and the client (and the reverse), including automated client synchronization, real time streaming networking, and a variety of network events all wrapped by a UDP based network protocol.

To script or not to script, that is the question...

Torque provides two primary ways of implementation for your game development, and in many cases the choice of implementation strategy can be confusing. In general, Object Implementation (the second layer) is performed in C++, while Gameplay Implementation (the third layer) is performed in TorqueScript, but this is only a rule of thumb, and different games (and different game developers) will require different strategies.

Generally speaking, TorqueScript is an excellent choice for most Gameplay implementation, and can also be used for initial prototyping of most Object Implementation. Generally speaking however, before you release a game to the public, you will want to re-implement your Object Implementation in C++ for speed and efficiency.