Game Structure

When you create your game, you can use pretty well any organizational structure you like. Your game will comprise script program modules, graphics images, 3D models, audio files, and various other data definition modules.

The only real limitation in how you structure your game folders is that the root main module must reside in the same folder as the Torque Engine executable, and this folder will be the game root folder.

The least you should do to sensibly organize your game folders is to have a subtree that contains common code, code that would be essentially the same between game types and variations, and another subtree that would contain the control code and specific resources that pertain to a particular game, game type, or game variation. GarageGames uses these two basic subtrees, common and control, in its sample games, although the company uses different names (such as fps, rw, racing, and show) for variations of the control subtree. See Figure 4.1 for a simple breakdown diagram.

Figure 4.1: General game folder tree.

In the game we are creating, we will call the control subtree control.

Source files for Torque Script have the .cs extension. After the source files are compiled, they have an extension of .cs.dso. There is no way to convert a .cs.dso file back into a .cs file, so you must make sure to hang on to your original source files and back them up regularly.

When you launch TGE, it looks for the module main.cs located in the same folder (the game root folder, shown below, which shows the general tree format used for the Emaga set of tutorial sample games used in this book) as the TGE executable. In this chapter we will be using a simplified version of this tree. In the distribution of TGE you receive with the CD, the executable is called tge.exe. The particular main.cs file located in the game root folder can be thought of as the root main module. This expression is useful for distinguishing that particular main.cs module from others with the same name that aren't in the game root folder.

 emaga (game root folder)    common    client       debugger       editor       help       lighting       server       ui          cache    control       client          misc          interfaces       data          maps          models             avatars             items             markers             weapons          particles          sound          structures          docks          hovels          towers       server          misc          players          vehicles          weapons 

These other main.cs modules are the root modules for the packages in the game. Although it isn't explicitly designated as such, the root main module functions as the root package of the game.

It's important to realize that the folder structure outlined above is not cast in stone. Note that although it is similar, it is still not exactly the same as the format used in the Torque sample games. As long as the root main module is in the same folder as the tge.exe executable, you can use whatever folder structure suits your needs. Of course, you will have to ensure that all of the hard-coded paths in the source modules reflect your customized folder structure.

Figure 4.2 shows the simplified folder tree we will be using for this chapter's sample game, Emaga4. The rectangles indicate folder names, the partial rectangles with the wavy bottoms are source files, and the lozenge shapes indicate binary files. Those items that are not in gray are the items we will be dealing with in this chapter.

Figure 4.2: The Emaga4 folder tree.

Packages, Add-ons, Mods, and Modules

If you find the terminology confusing, don't fret—it is a little bit less than straightforward at first blush.

The first thing to understand is that the term Mod is an abbreviated, or truncated, form of the word modification. Mods are changes that people make to existing games, customizing the games to look or play differently. The term is often used in the independent game development scene. The word Mod is often capitalized.

What we are doing when we create the Emaga game is in many ways similar to creating a Mod— much like a certain kind of Mod that is often called a Total Conversion. Torque, however, is not a game, it is an engine. So we are in reality not modifying an existing game, but, rather, we are creating our own.

Also, there is a bit of an extra wrinkle here: When we create our game, we are going to provide some features that will allow other people to modify our game! To avoid total confusion, we are going to call this capability an add-oncapability rather than a Mod capability. And we'll refer to the new or extra modules created by other people for our game as add-ons.

A module is essentially the melding of a program source file in text form with its compiled version. Although we usually refer to the source code version, both the source file version and the compiled (object code, or in the case of Torque, byte code) version are just different forms of the same module.

A package is a Torque construct that encapsulates functions that can be dynamically loaded and unloaded during program execution. Scripts often use packages to load and unload the different game types and related functions. Packages can be used to dynamically overload functions using the parent::function() script mechanism in the packaged function. This is useful for writing scripts that can work with other scripts without any knowledge of those scripts.

To replace the graphical Help features in the Torque demo, for example, you could create one or more source code modules that define the new Help features and that together could compose a Mod to the graphical Help package and that could also be considered a Mod to the Torque demo game as a whole.

Clear as mud?