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 3D game 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 3D, I would suggest you fill the artistic slots first—at least sign up a dedicated 3D modeler. You will also need at least one programmer to manage your script work. Finally, you need someone responsible for doing map layout, creating game rules, and managing the relationships 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.
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 investigate at least these two aspects of 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 these 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 called 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 at times be quite extensive.
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 promises to be fun (and it will do that, 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 screenshots, or record whatever else 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
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 3D; in fact, the Torque 3D Tools Demo as created by Torque has a checkbox to provide this capability out-of-the-box.
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, “big-pipe” network connections, 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 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 five-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, but that doesn’t mean they can never be successful. Maybe 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. Hollywood has produced a ton of successful Western movies. But there haven’t been very many equivalent games. Call of Juarez: Bound in Blood is the only recent one that comes to mind, and a large chuck of that is more of a Civil War game. 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 could 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 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 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 multi-player 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 Torque and buy a professional or studio license for their Torque 3D game engine, you get all 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 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. After all, Minions of Mirth is an MMO made with Torque!
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 website (http://www.garagegames.com) and browse the various menus, 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 DVD for this book. At the GarageGames website forums, you will see the developers of these games in continuous conversation with people designing and making their own games—most 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 3D game 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 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 information from this book, you can afford to try out your ideas 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, several more weeks to tweak it, and a few months to build on it, finally coming 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.