The Torque Game Engine

I've mentioned the Torque Game Engine several times already. I think now would be a good time to take a little deeper look at the engine and how you will be using it.

Appendix A provides a reference for the Torque Game Engine, so look there if you really need more detail.

Descriptions

The following descriptions are by no means exhaustive, but a cup of coffee would go well with this section. Go ahead and make some—I'll wait. Black with two sweeteners, please.

Moving right along, you should note that the main reason for including this section is to give you, the Gentle Reader, the right sense of how much behind-the-scenes work is done for you by the engine.

Basic Control Flow

The Torque Game Engine initializes libraries and game functions and then cycles in the main game loop until the program is terminated. The main loop basically calls platform library functions to produce platform events, which then drive the main simulation.

Torque handles all of the basic event procession functions as follows:

• Dispatches Windows mouse movement events to the GUI

• Processes other input-related events

• Calculates elapsed time based on the time scale setting of the simulation

• Manages processing time for server objects

• Checks for server network packet transmissions

• Advances simulation event time

• Processes time for client objects

• Checks for client network packet transmission

• Renders the current frame

• Checks for network time-outs

Platform Layer

The platform layer provides a cross-platform architecture interface to the engine. The platform layer is responsible for handling file and network operations, graphics initialization, user input, and events.

Console

The console library provides the foundation for Torque-based games. The console has both a compiler and an interpreter. All GUIs, game objects, game logic, and interfaces are handled through the console. The console language is called Torque Script and is similar to a typeless C++, with some additional features that facilitate game development. You can load console scripts using a command from the console window as well as automatically from files.

Input Model

Input events are translated in the platform layer and then posted to the game. By default the game checks the input event against a global action map that supersedes all other action handlers. If there is no action specified for the event, it is passed on to the GUI system. If the GUI does not handle the input event, it is passed to the currently active (non-global) action map stack.

Platform-specific code translates Win32, Xwindows, or Mac events into uniform Torque input events. These events are posted into the main application event queue.

Action maps translate platform input events to console commands. Any platform input event can be bound in a single generic way—so in theory, the game doesn't need to know if the event came from the keyboard, the mouse, the joystick, or some other input device. This allows users of the game to map keys and actions according to their own preferences.

Simulation

A stream of events drives the game from the platform library: InputEvent, MouseMoveEvent, PacketReceive-Event, TimeEvent, QuitEvent, ConsoleEvent, ConnectedReceive-Event, ConnectedAcceptEvent, and ConnectedNotifyEvent. By journaling the stream of events from the platform layer, the game portion of the simulation session can be deterministically replayed for debugging purposes.

The simulation of objects is handled almost entirely in the game portion of the engine. Objects that need to be notified of the passage of time can be added to one of the two process lists: the global server or global client process list, depending on whether the object is a server object or a client ghost.

Server-side objects are only simulated at certain times, but client objects, in order to present a smooth view when the frame rate is high, are simulated after each time event.

There is a simulator class that manages all of the objects and events in the simulation. Objects are collected in a hierarchy of simulator classes and can be searched for by name or by object id.

Resource Manager

The Torque Engine uses many game resources. Terrain files, bitmaps, shapes, material lists, fonts, and interiors are all examples of game resources. Torque has a resource manager that it uses to manage large numbers of game resources and to provide a common interface for loading and saving resources. Under the auspices of Torque's resource manager, only one instance of a resource will ever be loaded at a time.

Graphics

Torque does not perform its own graphics rasterization; instead, it uses the OpenGL graphics API. Torque includes a utility library that extends OpenGL to support higher-level primitives and resources.

Torque has a collection of utility functions that add support for complex primitives and resources like fonts and bitmaps and that add simple functions for more easily managing textures and 2D rasterization.

Torque includes a texture manager that tracks the loading and unloading of all textures in the game. Only one instance of a texture is ever loaded at a given time; after loading it is handed off to OpenGL. When the game switches graphics modes or video devices, the texture manager can transparently reload and redownload all the game's textures.

Torque supports several bitmap file types: PNG, JPEG, GIF, BMP, and the custom BM8 format, an 8-bit color texture format used to minimize texture memory overhead.

The GUI library manages the user interface of Torque games. It is designed specifically for the needs of game user interface development. The Canvas object is the root of the active GUI hierarchy. It dispatches mouse and keyboard events, manages update regions and cursors, and calls the appropriate render methods when it is time to draw the next frame. The Canvas keeps track of content controls, which are separate hierarchies of controls that render from bottom to top. The main content control is a screen in the shell that can be covered by any number of floating windows or dialog boxes.

A Profile class maintains common instance data across a set of controls. Information such as font face, colors, bitmaps, and sound data are all stored in instances of the Profile class, so that they don't need to be replicated on each control.

A Control class is the root class for all the GUI controls in the system. A control can contain any number of child controls. Each control maintains a bounding rectangle in the coordinate system of its parent control. The Control class processes input events, rendering, and mouse focus, and coordinates automatic sizing.

3D Rendering

The Torque library has a modular, extensible 3D world rendering system. Game subclasses first define the camera orientation and field of view and then draw the 3D scene using OpenGL drawing commands. A class manages the setting up of the viewport, as well as the model view and projection matrices. A function returns the viewing camera of the current control object (the object in the simulation that the player is currently controlling), and then the engine calls the client scene graph object to render the world.

On the client, a scene graph library is responsible for traversing the world scene and determining which objects in the world should be rendered given the current camera position, while on the server, it determines what objects should be sent to each client based on that client's position in the world. The world is divided into zones, which are volumes of space bounded by solid areas and portals. The outside world is a single zone, and interior objects can have multiple interior zones. The engine finds the zone of a given 3D point and which object owns that zone. The engine then determines which zone or zones contain an object instance. At render time the scene is traversed starting from the zone that contains the camera, clipping each zone's objects to the visible portal set from the zones before it. The engine also performs the scoping of network objects, deciding whether a given object needs to be dealt with by a client.

Every world object in the scene that can be rendered is derived from a single base class. As the world is traversed, visible objects are asked to prepare one or more render images that are then inserted into the current scene. Render images are sorted based on translucency and then rendered. This system permits an interior object with multiple translucent windows to render the building first, followed by other objects, followed by the building's windows. Objects can insert any number of images for rendering.

Terrain

The terrain library deals with objects that render a model of the outside world. It contains a sky object that renders the outside skybox, animates and renders cloud layers, and applies the visible distance and fog distance settings for when the world as a whole is rendered. The sky object also generates the vertical fog layers and sends them into the SceneGraph object for rendering. The TerrainBlock class provides a single 256 256 infinitely repeating block of heightfield terrain. Heightfield data is stored and loaded by the resource manager so that a single terrain data file can be shared between server and client.

The terrain is textured by blending base material textures with program code into new material textures and then mapping those across multiple terrain squares based on the distance from the square. The Blender class performs the blending of terrain textures and includes a special assembly version to speed things up when executing on x86 architectures.

Water is dynamically rendered based on distance, making nearby water more tessellated and detailed. Water coverage of an area can be set to seed fill from a point on the surface, allowing the water to fill a depression to form a lake without leaking outside the corners.

Interiors

The interior library manages the rendering, collision, and disk-file services for interior objects, such as buildings. An interior resource class manages the data associated with a single definition of an interior, and multiple instances may exist at any one time. Interiors manage zones for the scene graph and may have subobjects that render a mirrored view. A light manager class generates lightmaps for all currently loaded interiors. Lightmaps are shared among instances whenever possible. Interior resources are built and lit by an interior importer utility. The source files are Quake-style .map files that are little more than lists of convex physical constructive solid geometry "brushes" that define the solid areas of the interior. Special brushes define zone portal boundaries and objects like lights.

Shapes and Animation

A library manages the display and animation of shape models in the world. This library's shape resource class can be shared between multiple shape instances. The shape class manages all the static data for a shape: mesh data, animation keyframes, material lists, decal information, triggers, and detail levels. An instance class manages animation, rendering, and detail selection for an instance of a shape. The instance class uses the thread class to manage one of the concurrently running animations on an instance. Each thread can be individually advanced in time or can be set on a time scale that is used when all threads are advanced. A thread can also manage transitions between sequences.

Animation sequences can be composed of node/bone animation (for example, joints in an explosion), material animation (a texture animation on an explosion), and mesh animation (a morphing blob; note that most mesh animations can be accomplished with node scale and rotation animations). Animations can also contain visibility tracks so that some meshes in the shape are not visible until an animation is played.

Networking

Torque was designed from the foundation to offer robust client/server network simulation support. The networking design of Torque was driven by the need for superior network performance over the Internet. Torque addresses three fundamental problems of real-time network programming: limited bandwidth, packet loss, and latency. For a more detailed, if somewhat outdated, description of the Torque network architecture, see "The Tribes II Engine Networking Model," an article by Tim Gift and Mark Frohnmayer, at the GarageGames site (http://www.garagegames.com). An instance of a Torque game can be set up as a dedicated server, a client, or both client and server. If the game is both client and server, it still behaves as a client connected to a server, but the netcode has a short-circuit link to other netcode in the same game instance, and no data goes out to the network.

Bandwidth is a problem because of the large, open terrain environments Torque supports, as well as the large number of clients Torque can handle—up to 128 or more per server, which means that there is a high probability that many different objects can be moving and updating at the same time. Torque uses several strategies to maximize available bandwidth.

• It sends updates to what is most important to a client at a greater frequency than it updates data that is less important.

• It sends only the absolute minimum number of bits needed for a given piece of data.

• It only sends the part of the object state that has changed.

• It caches common strings and data so that they need only be transmitted once.

Packet loss is a problem because the information in lost data packets must somehow be retransmitted, yet in many cases the data in the dropped packet, if sent again directly, will be stale by the time it gets to the client.

Latency is a problem in the simulation because the network delay in data transmission makes the client's view of the world perpetually out of sync with the server. Twitch-style FPS games, for which Torque was initially designed, require instant control response in order to feel anything but sluggish. Also, fast-moving objects can be difficult for highly latent players to hit. In order to solve these problems, Torque employs the following strategies:

• Interpolation is used to smoothly move an object from where the client thinks it is to where the server says it is.

• Extrapolation is used to guess where the object is going based on its state and rules of movement.

• Prediction is used to form an educated guess about where an object is going based on rules of movement and client input.

The network architecture is layered: At the bottom is the OS/platform layer, above that the notify protocol layer, followed by the NetConnection object and event management layer.

Using Torque in This Book

As you've seen, the Torque Game Engine is powerful, feature rich, flexible, and controllable. What we will do in this book is create all of the different elements of the game that we'll need and then write game control script code to tie it all together.

All of the program code, artwork, and audio resources you will need are included on the companion CD, along with the tools needed to manipulate them and create your own.

At first glance that may not seem to be too daunting a task. But remember, we will be wearing all of the game developer hats. So we will be creating our own models (players, buildings, decorations, and terrains), recording our own sound effects, placing all of these things in a virtual world of our own fabrication, and then devising game rules and their scripted implementations to make it all happen.

Daunted yet?

Hey, it's not going to be that hard. We've got Torque!

The CD

There are several different setup options available from the CD. The simplest and most complete is the Full Install. The most minimal installation will install the Torque Engine Executable and the appropriate file paths for a sample game, with supporting scripts.

Installing Torque

If you want to install only the Torque Game Engine, without the various chapter files, extra utilities, or demo games, then do the following:

1. Browse to your CD in the \Torque folder.

2. Locate the Setup.exe file and double-click it to run it.

3. Click the Next button for the Welcome screen.

4. Click the Next button for the Destination screen, taking the default program group location.

5. At the Select Components screen there is a Full Installation drop-down menu. Select this menu by clicking in it, and change it by selecting Custom Installation. Then click the Next button.

6. From the Components list, select Torque and click the Next button.

7. Select the defaults for the remaining screen, clicking Next for each one.