3D Game Programming All In One (2004)

This page intentionally left blank

Team LRN

chapter 24

The End Game

By now you've worn many hats, as programmer, 2D artist, 3D modeler, sound engineer, 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 suggest 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 responsible 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.

659

Team LRN

660 Chapter 24 ■ The End Game

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 procedure 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.

Team LRN

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 usually 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 execution modes:

■client only

■server only

■hosted server

Team LRN

662Chapter 24 ■ The End Game

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 created 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 sending 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 nightmare 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 environments 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 server. There are many 16or 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

Team LRN

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 overcome. 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 teambased 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

Team LRN

664Chapter 24 ■ The End Game

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 modifying 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 (http://www.garagegames.com) 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 continuous 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

Team LRN

Go For It 665

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 imperative 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.

Team LRN

This page intentionally left blank

Team LRN

Appendix A

The Torque Game

Engine Reference

Torque Console Script Command Reference

activateDirectInput()

activateKeyboard()

activatePackage(name)

667

Team LRN