Final Change
The final, very, very last piece of code we are going to change will allow us to remain in the
program after we exit a game. Previously, when we exited a game using the Escape key, the
program quit. This final change tidies that up for us. Open the file C:\koob\control\
client\misc\presetkeys.cs and locate the function
DoExitGame()
and change it to match the
following:
function DoExitGame()
{
if ( $Server::ServerType $= "SinglePlayer" )
MessageBoxYesNo( "Exit Mission", "Exit?", "disconnect();", "");
else
MessageBoxYesNo( "Disconnect", "Disconnect?", "disconnect();", "");
}
This function now checks to see if we are in single- or multiplayer mode. It does this to
provide a customized exit prompt depending on which mode it is. In any event, the
disconnect
function is called to break the connection with the game server.
Moving Right Along
So there you have it. I hope your fingers aren't worn to the bone. You can see that there is
a great deal of power available to those worn fingertips. I'm sure that as you've progressed
through the preceding chapters, your head began to fill with all sorts of ideas about things
you might want to do. In the next and final chapter of the book, I have a few things I want
to say on that topic.
Moving Right Along 657
Team LRN
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
This page intentionally left blank
Team LRN
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

need to perform to prove to you that their software fulfilled that requirement. Write the pro-
cedure down, and move on to the next requirement. Be hypercritical, a skeptic's skeptic.
Basics
There are many formalized testing methodologies, but the basic need when testing is to
ensure at least two things about any feature:
1. Does the program feature (operation, appearance, behavior) work the way it
should, when it should?
2. Does the feature make something else not work the way it should, when it should?
Take your list of test procedures and run through your software answering those two
questions. It is certainly a lot tougher to answer the second question—sometimes you will
see something not working, only to find out later that it was some other feature that was
causing the problem that you witnessed.
You will end up with a list of problems and probably some ideas about how to fix them.
Fill your list up first before running off to repair the bugs, and then sit back and examine
the list of problems to try to identify problems that may share the same root cause. You
can possibly save much effort and time by fixing the root cause. Otherwise you might end
up with a series of individual fixes and hacks, each of which only addresses a single issue,
and each of which exposes another issue.
Regression
The phenomenon regression is caused by bug fixes that introduce new bugs or sometimes
expose hidden bugs. Some software engineers dispute the idea of referring to exposing
hidden bugs as regression, but to me it's a difference without a distinction. The result is
the same.
To deal with regression, we need to run our tests after every bug-fixing session. Ask the
same questions and look for the answers. If you have the time and patience (neither of
which is commonly overly abundant), you should run your regression test after each bug
fix. In other words, don't do your entire list of bug-fixing programming all at once and
then jump back to your regression test. If new bugs have been introduced, it may be hard
to find them, because the new code can be quite extensive.
Chapter 24

and play as if it were a real player. Then you could launch dozens of these clients in order
to simulate client loads on the server.
Hosted Servers
As you've seen with the example programs, with Torque there are three different execu-
tion modes:
■
client only
■
server only
■
hosted server
Hosted Servers 661
Team LRN
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Depending on your needs, you might want to create one monolithic program that will run
in all three modes. This is certainly possible with Torque—in fact, the Torque demo as cre-
ated by GarageGames supplies this capability by default.
However, you may want to create two or three different program distributions—one for
each mode, or one for client only, the other being one or both of the server modes. There
are some reasons for doing this, and probably the best is for server security. It depends on
your business model (if you have one). If you are planning to provide all of the server-side
hosting, then you might want a client-only version to be distributed to users. By not send-
ing out the server code, you minimize the risk of unscrupulous players hacking the game
to gain an advantage over other players in online play.
There are pitfalls to the multiple-version approach, the most noteworthy of which is the
need to maintain two or more different versions of programs. That's a potential night-
mare looking for a place to happen. Proceed with caution.
Having said all that, the distribution of multiplayer games that allow players to host other
players while they all play in the same game is a common approach. Not only do many
games offer it, but thousands of players use the capability.

One of the games I'd really like to see someone create in the FPS genre is a chess game
played out with individual battles between pieces, where you can have each player able to
engage in combat appropriate to the chess pieces as they are moved. There are game play
issues that would need to be resolved, but that's something a clever designer would over-
come. Here are some of the issues that would have to be tackled:
■
Who decides the moves if the game is team based?
■
Should each piece have different combat styles?
■
Should the standard rules of chess play (movement rules, for example) prevail?
■
Might you need to modify them slightly?
■
Should you ever have an overhead board view?
If you broaden the scope a bit and don't focus on the shooter part of the FPS genre, the
horizon starts to recede—first-person perspective play without the shooting has been
barely touched.
Firefighting is one such topic that seems like it might be ripe for a game, especially team-
based play. You could do forest fires, building fires, and so on. The biggest challenge would
be the fire-propagation algorithms, such as the following:
■
Exactly what conditions cause this item or that item to burst into flames?
■
How does smoke move through a forest, a building, and so on, and how do you
render that?
■
How do you score the game?
■
How realistic should the game be?

immediate and viewable area of the player. You would probably need to make a special
world creation tool for managing large worlds—a tool you would create with Torque.
If you go to the GarageGames Web site () and click the
Make Games button, you will find a user community that is large, active, and thriving.
Several of the retail games made with Torque are included on the companion CD for this
book. At the GarageGames forums you will see the developers of these games in continu-
ous conversation with people designing and making their own games—every one of them
an independent just like you.
As you browse around, make your way to the Resources postings, and you will find a
whole slew of code modifications submitted by members of the community to enhance
the core capabilities of the Torque Engine. In fact, you will find that a substantial number
of the features that Torque now has that it didn't have when it was first released were
added as submissions from the user-developer community.
In addition to extending the core capabilities, another reason for modifying the engine
would be to move the more CPU-intensive parts of your game scripts into the core engine
in order to improve the execution speed and sometimes even the memory footprint (how
Chapter 24
■
The End Game664
Team LRN
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
much memory your game uses). To do these things you will have to learn how to program
in C/C++ or at least obtain the services of a competent C/C++ programmer.
Go For It
As an independent game developer, you owe nothing to anyone except yourself and your
family. That being the case, there is an important and sometimes underrecognized imper-
ative for every independent game developer: Have fun!
Given that you've picked up this book, you probably already have some ideas rattling
around inside your head, and you've been thinking about making them happen. Armed
with the tools and knowledge from this book, you can afford to try them out without

DirectInput
polling of the keyboard.
Usage:
%result = activateKeyboard();
activatePackage(name)
Parameters: name
String containing the name of the package.
Return: nothing
Description:
Tells Torque to start using the package specified by name.
Usage:
activatePackage(Show);
Team LRN
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Appendix A
■
The Torque Game Engine Reference668
AddCardProfile (vendor, renderer, safeMode, lockArray, subImage, fogTexture,
noEnvColor, clipHigh, deleteContext, texCompress, interiorLock, skipFirstFog,
only16, noArraysAlpha, profile)
Parameters: vendor
Name of card vendor.
renderer
Name of renderer.
safeMode
true
or
false
lockArray
true

skipFirstFog
true
or
false
only16
true
or
false
noArraysAlpha
true
or
false
profile
Name of profile.
Return: nothing
Description:
Creates a profile of features of a video card for later reference.
Usage:
AddCardProfile(%vendor, %renderer, true, true, true, true, true, false,
false, true, true, false, false, false,"")
addMaterialMapping( material, sound, color)
Parameters: material
Name string to identify the material.
sound
Name of sound profile to attach to material.
color
Color specification to attach to material.
Return: nothing
Description:
Adds sound and dust color to specified material.