3D Game Programming All in One- P26

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.

659
The End Game
chapter 24
B
y now you've worn many hats, as programmer, 2D artist, 3D modeler, sound engi-
neer, and level designer, to mention just the big ones. It should be fairly evident
that each of these specialties has a great deal of depth, and it is hard to do justice
to any one of them in a book like this.
However, it should also be apparent that you can make complex and feature-rich games
without the need for million-dollar budgets. In this chapter we'll look at some of the
things that didn't quite fit as topics in the earlier chapters.
A great deal of the work is done for us by the Torque Engine, but that's just where the
process starts—the end is wherever you want it to be. There are other game engines out
there, ranging from free to expensive, but the relationship between the end result and the
price of the engine is not a linear one. The result is dependent on the amount of effort and
inspiration you bring to the table. Making successful games is about transforming a great
idea into a great game, and that operation can't be bought with mere money.
If you are going to put together a small team to develop a game using Torque, I would sug-
gest you fill the artistic slots first—at least sign up a dedicated 3D modeler. You will also
need one programmer to manage your script work. Finally, you need someone responsi-
ble for doing map layout, creating game rules, and managing the relationship between the
models and the code. This makes a three-person team, which is probably as close to an
ideal size as you're going to get for a small, low-budget development team. If you have the
luxury of adding another team member, make sure you give him the sound-engineer
responsibilities.
Team LRN
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Testing
To properly test your game you are going to need to go back to your requirements and review
them. For each specific requirement you have to decide what procedure someone else would

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

■
The End Game660
Team LRN
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Play Testing
You will also want to enlist a bevy of play testers because there can be more wrong with
the game than simple (or not-so-simple) bugs. You need to ensure that the game is fun to
play, and you need to ensure that the things you can do in the game have the effect you
want them to have. If your game features an Easter egg hunt, you want to make sure that
the players can actually find the hidden items. At the same time, you will probably want
to make sure that the items aren't too easy to find. Achieving the balance in game play is
why you want to use play testers.
When you and members of your development team are testing the software, this is usual-
ly referred to as the alpha test phase. Alpha testing can be considered complete when the
development team's own testing is no longer finding problems. This, however, doesn't
mean that testing is finished! You will eventually need to use people who have not been
involved in the creation of the game for testing. Once you start letting outsiders play-test
your game, you are now in the beta test phase. If the game is fun (and it will be, right?)
then you should not have much trouble interesting people in being beta testers. And this
will introduce a problem (it's a problem you want to have, but still a problem), which is
that many beta testers will be playing the game and not testing it. While it is good for them
to be enjoying themselves, you need them to take notes and record problems, issues, and
general feelings about the way the game is played. You need these notes in order to know
what to fix and what to change or add.
Test Harnesses
You should also consider creating test harnesses to use in your testing. These are programs
that are designed to provide the inputs that will cause the various features of the game to
be exercised. The testing software should log its output to a file, automatically take screen
shots, or record whatever else that is needed so that you can review the results.
For example, you could create a special version of the client that will automatically run

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.

Dedicated Servers
Some games, especially those that offer persistent role-playing style features, are hosted on
dedicated servers only. The game's developer, or a service company that represents the
developer, usually operates these servers. These games generally offer virtual environ-
ments where hundreds or thousands of players connect to the same world and interact in
varying ways. This usually presents bandwidth and CPU costs well beyond the abilities of
casual players and hobbyists looking for an evening's entertainment.
These sorts of "big iron" servers are often hosted on clustered servers at dedicated hosting
service companies with battery-backup systems and racks and racks of computers.
This does not mean that you shouldn't offer your users the ability to run a dedicated serv-
er. There are many 16- or 32-player first-person shooter games on the market that have
hordes of fans that run permanent 24/7 servers. Offering a dedicated server mode allows
your users to run the servers on computers with less capability than they might otherwise
use as their game-playing computer. That is to say, dedicated servers are an ideal way for
users to utilize that two-year old computer sitting in the corner gathering dust!
FPS Game Ideas
You might be tempted to think that all the great first-person shooter ideas have already
been done to death. I doubt that's true. There are a few ideas that have been tried and have
not been terribly successful—that doesn't mean that they can never be successful. Maybe
Chapter 24
■
The End Game662
Team LRN
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
with a bit of tweaking, you could make a successful version of a game that previously
bombed. That's an important concept to keep in the back of your head.
One such example that immediately comes to mind is the Western—you know, the Wild,
Wild West. There have been a ton of successful Hollywood Western movies. But there
haven't been any equivalent games. That's an assignment for someone out there, and if it
is ever going to be fulfilled, it will likely be an independent like you that does it.

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?

Other Genres
If you now shift a little to encompass third-person perspective play, the horizon opens up
yet again. Almost any sport you can think of can be simulated from this point of view:
bullfighting, surfing, rugby, and sailboarding, to name a few.
One that I would like to see is a mountain-biking game. I'd especially like to see one that
accepted input from a stationary bicycle! Imagine being able to ride single-track trails at
Moab while buried under three feet of snow in Ontario! That would be cool. In fact, I
Other Genres 663
Team LRN
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
think there is an untapped market here: hooking up the various machines in a gym to
computers running games that people can play, using the exercise machines as the input
devices. Exercise equipment manufacturers have put out some weak attempts at this, but
there could be so much more—especially in the online multiplayer realm.
Instead of running on a treadmill hooked up to a computer with software that simulates
running on a trail in Oregon, how about using the treadmill to provide motive input for
your player as a rifleman in World War II Online? In fact, there is hardware that hasn't even
been designed yet that could probably be used in this way.
Modifying and Extending Torque
If you sign up with GarageGames and buy a developer's license for their Torque Game
Engine, you get all of the source code. Every single bit of it.
Stop and think about that for just a minute. Not only do you get the capabilities already
described in this book—features you've been learning how to use to make your game—
but you also get the access to the core engine code, with the right to change it as you like
to make your game do absolutely whatever you want it to do!
Earlier I'd pointed out that Torque is not really designed for massively multiplayer games.
With access to the source code, you could change that, adding the missing bits and mod-
ifying the existing bits to accommodate your needs.
How about huge, I mean gigantic, game worlds? You could do this by modifying the Terrain
Manager code to accommodate paging terrain, where the game only loads the terrain in the

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

being afraid of wasting years of your life finding out that an idea didn't work.
Now you can "waste" a few weeks finding out that an idea doesn't work, and then spend a
few more weeks to refine it, some more weeks to tweak it, a few months to build on it, and
finally, come up with something that might really fly.
Well, we are at the end of our journey. I hope you have enjoyed it as much as I have. I think
the key thing to come away with is this: Believe in yourself.
Go For It 665
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.
667
The Torque Game
Engine Reference
Appendix A
Torque Console Script Command Reference
activateDirectInput()
Parameters: none
Return: nothing
Description:
Activates direct input device polling.
Usage:
activateDirectInput();
activateKeyboard()
Parameters: none
Return: numeric
1 = success, 0 = fail.
Description:
Enables

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

or
false
subImage
true
or
false
fogTexture
true
or
false
noEnvColor
true
or
false
clipHigh
true
or
false
deleteContext
true
or
false
texCompress
true
or
false
interiorLock
true
or
false

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.

Usage:
addMaterialMapping("sand", "sound:0", "color:0.3 0.3 0.5 0.4 0.0" );
Team LRN
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.