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 (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 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. [...]... string contains a tuple indicating where to place the enumed property in 3D world space (alternative) If "x y z" isn't used, then this is a tuple indicating where to place the audio object in 3D world space Note: These are three numerics, not a string! nothing Sets the ALenum to value for the listener (the player, who "hears" a sound) alListener3f("AL_GAIN_LINEAR", $pref::Audio::masterVolume ); AllowConnections(switch)... nothing Stops the playback on all registered channels alxStopAll(); Backtrace() Parameters: Return: Description: Usage: none nothing Enables echo of script call stack to console Backtrace(); Team LRN 675 676 Appendix A ■ The Torque Game Engine Reference BuildTaggedString(string, format) Parameters: Return: Description: Usage: string Normal string to be added format Format specifying string string Builds... objects to find point Location of container x,y,z Numeric bounds of container specified Not a string numeric Handle of object found Finds objects of type within the box specified with x,y,z at the given point Returns the handle of the first object found %objectHandle = ContainerFindFirst(type, point, x, y, z); ContainerFindNext() Parameters: Return: Description: none numeric Handle of object found Find the... found Find the next object in the container specified by immediately previous call to containerFindFirst, and get its handle Usage: %objectHandle = ContainerFindNext(); ContainerRayCast (start, end, mask, [exclude]) Parameters: Return: Description: Usage: start Starting coordinate tuple end Ending coordinate tuple mask Object type mask exclude List of handles string Hit list Finds a list of objects of... Return: Description: text String string The resultant string Escapes all of the escape characters in text For example, \n becomes \\n In this case the \n would be printed to the console instead of the new line it would otherwise cause Usage: %extext = ExpandEscape(%text); ExpandFilename(filename) Parameters: Return: Description: Usage: filename String containing file name string Obtains the actual OS-specific... FileExt(filename) Parameters: Return: Description: Usage: filename String containing full file name string String containing extension Gets the extension of the file specified by filename %name = FileExt("script.cs"); FileName(filename) Parameters: Return: Description: Usage: filename String containing full file name string String containing the name Gets the name of the file specified by filename %name... renderer AllowOpenGL true or false allowD3D true or false preferOpenGL true or false nothing Stores certain aspects of a video card for later usage AddOSCardProfile(%vendor,%renderer,true,true,true); AddTaggedString (string) Parameters: Return: Description: Usage: string Normal string to be added numeric The tag Adds a string to the tagged string list (NetStringTable) %tagname = AddTaggedString(%name);... filename String containing file name nothing Dumps memory statistics to the file DumpMemSnapshot("dump.txt"); DumpNetStringTable() Parameters: Return: Description: Usage: none nothing Dumps the NetStringTable stats to the console DumpNetStringTable(); Team LRN 683 684 Appendix A ■ The Torque Game Engine Reference DumpResourceStats(); Parameters: Return: Description: none nothing Dumps texture information... Torque Game Engine Reference alxSource3f(handle,ALenum, [ "x y z" ] | [ x,y,z ] ) Parameters: handle ALenum "x y z" x,y,z Return: Description: Usage: Handle to audio object The enum string Choices: "AL_VELOCITY" "AL_POSITION" "AL_DIRECTION" String containing a tuple indicating where to place the enumed property in 3D world space (alternative) If "xyz" isn't used, then this is a tuple indicating where... current container search radius distance %rad = ContainerSearchCurrRadiusDist(); ContainerSearchNext() Parameters: Return: Description: Usage: none numeric Gets the next object in a container search %nc = ContainerSearchNext(); CreateCanvas(title) Parameters: Return: Description: Usage: title String containing title of the window numeric 1 = success, 0 = fail Creates a graphics canvas in a window %result . Torque Game Engine Reference676 BuildTaggedString(string, format) Parameters: string Normal string to be added. format Format specifying string. Return: string. 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.