Elements of a 3D Game

The architecture of a modern 3D game encompasses several discrete elements: the engine, scripts, GUI, models, textures, audio, and support infrastructure. We're going to cover all of these elements in detail in this book. In this section I'll give you some brief sketches of each element to give you a sense of where we are going.

Game Engine

Game engines provide most of the significant features of a gaming environment: 3D scene rendering, networking, graphics, and scripting, to name a few. See Figure 1.10 for a block diagram that depicts the major feature areas.

Figure 1.10: Elements of a game engine.

Game engines also allow for a sophisticated rendering of game environments. Each game uses a different system to organize how the visual aspects of the game will be modeled. This becomes increasingly important as games are becoming more focused on 3D environments, rich textures and forms, and an overall realistic feel to the game. Textured Polygon rendering is one of the most common forms of rendering in FPS games, which tend to be some of the more visually immersive games on the market.

By creating consistent graphic environments and populating those environments with objects that obey specific physical laws and requirements, gaming engines allow games to progress significantly along the lines of producing more and more plausible narratives. Characters are constrained by rules that have realistic bases that increase the gamer's suspension of disbelief and draw him deeper into the game.

By including physics formulas, games are able to realistically account for moving bodies, falling objects, and particle movement. This is how FPS games such as Tribes 2, Quake 3, Half-Life 2, or Unreal II are able to allow characters to run, jump, and fall in a virtual game world. Game engines encapsulate real-world characteristics such as time, motion, the effects of gravity, and other natural physical laws. They provide the developer with the ability to almost directly interact with the gaming world created, leading to more immersive game environments.

As mentioned earlier, this book will employ the Torque Game Engine from GarageGames (http://www.garagegames.com). The Torque is included on the CD with this book. Later on we will discuss Torque in more detail—and you will understand why Torque was chosen.

Scripts

As you've just seen, the engine provides the code that does all the hard work, graphics rendering, networking, and so on. We tie all these capabilities together with scripts. Sophisticated and fully featured games can be difficult to create without scripting capability.

Scripts are used to bring the different parts of the engine together, provide the game play functions, and enable the game world rules. Some of the things we will do with scripts in this book include scoring, managing players, defining player and vehicle behaviors, and controlling GUI interfaces.

Following is an example of a Torque script code fragment:

 // Beer::RechargeCompleteCB // args: %this      - the current Beer object instance // %user            - the player connection user by id // // description: //   Callback function invoked when the energy recharge //   the player gets from drinking beer is finished. //   Note: %this is not used. function Beer:: RechargeCompleteCB (%this,%user) {       // fetch this player's regular recharge rate       // and use it to restore his current recharge rate       // back to normal       %user.setRechargeRate(%user.getDataBlock().rechargeRate); } // Beer::OnUse // args: %this      - the current Beer object instance //     %user        - the player connection user by id // // description: //   Callback function invoked when the energy recharge //   the player gets from drinking beer is finished. // function Beer::OnUse(%this,%user) {    // if the player's current energy level    // is zero, he can't be recharged, because    // he is dying    if (%user.getEnergyLevel() != 0)    {        // figure out how much the player imbibed        // by tracking the portion of the beer used.        %this.portionUsed += %this.portion;        // check if we have used up all portions        if (%this.portionUsed >= %this.portionCount)        {           // if portions used up, then remove this Beer from the           // player's inventory and reset the portion           %this.portionUsed = 0;           %user.decInventory(%this,1);        }        // get the user's current recharge rate        // and use it to set the temporary recharge rate        %currentRate = %user.getRechargeRate();        %user.setRechargeRate(%currentRate +%this.portionCount);        // then schedule a callback to restore the recharge rate        // back to normal in 5 seconds. Save the index into the schedule        // list in the Beer object in case we need to cancel the        // callback later before it gets called        %this.staminaSchedule = %this.schedule(5000,"RechargeCompleteCB",%user);        // if the user player hasn't just disconnected on us, and        // is not a 'bot.        if (%user.client)        {           // Play the 2D sound effect signifying relief ("ahhhhh")           %user.client.play2D(Relief);           // send the appropriate message to the client system message           // window depending on whether the Beer has been finished,           // or not. Note that whenever we get here portionUsed will be           // non-zero as long as there is beer left in the tankard.           if (%this.portionUsed == 0)               messageClient(%user.client, 'MsgBeerUsed', '\c2Tankard polished off');           else               messageClient(%user.client, 'MsgBeerUsed', '\c2Beer swigged');        }    } } 

The example code establishes the rules for what happens when a player takes a drink of beer. Basically, it tracks how much of the beer has been consumed and gives the player a jolt of energy for five seconds after every mouthful. It sends messages to the player's client screen telling him what he's done—had a sip or polished off the whole thing. It also plays a sound effect of the player sighing in relief and contentment with every drink.

Graphical User Interface

The Graphical User Interface (GUI) is typically a combination of the graphics and the scripts that carries the visual appearance of the game and accepts the user's control inputs. The player's Heads Up Display (HUD), where health and score are displayed, is part of the GUI. So are the main start-up menus, the settings or option menus, the dialog boxes, and the various in-game message systems.

Figure 1.11 shows an example main screen using the Tubettiworld game. In the upper-left corner, the text that says "Client 1.62" is an example of a GUI text control. Stacked along the left side from the middle down are four GUI button controls. The popsicle-stick snapper logo in the lower right and the Tubettiworld logo across the top of the image are GUI bitmap controls that are overlayed on top of another GUI bitmap control (the background picture). Note that in the figure the top button control (Connect) is currently highlighted, with the mouse cursor over the top of it. This capability is provided by the Torque Game Engine as part of the definition of the button control.

Figure 1.11: An example of a main menu GUI.

In later chapters of this book we will spend a good deal of time contemplating, designing, and implementing the GUI elements of our game.

Models

3D models (Figure 1.12) are the essential soul of 3D games. With one or two exceptions, every visual item on a game screen that isn't part of the GUI is a model of some kind. Our player's character is a model. The world he tromps on is a special kind of model called terrain. All the buildings, trees, lampposts, and vehicles in our game world are models.

Figure 1.12: A 3D wire-frame and textured models of an old-style helicopter.

In later chapters we will spend a great deal of time creating and texturing models, animating them, and then inserting them into our game.

Textures

In a 3D game, textures are an important part of rendering the models in 3D scenes. Textures (in certain cases called skins—see Figure 1.13) define the visually rendered appearance of all those models that go into a 3D game. Proper and imaginative uses of textures on 3D models not only will enhance the model's appearance but will also help reduce the complexity of the model. This allows us to draw more models in a given period of time, enhancing performance.

Figure 1.13: The textures used as the skin of the old-style helicopter.

Sound

Sound provides the contextual flavoring in a 3D game, providing audio cues to events and background sounds that imply environments and context, as well as 3D positioning cues for the player. Judicious use of appropriate sound effects is necessary for making a good 3D game. Figure 1.14 shows a sound-effect waveform being manipulated in a waveform-editing program.

Figure 1.14: A graphical view of a gunshot sound-effect waveform.

Music

Some games, especially multiplayer games, use little music. For other games, such as single-player adventure games, music is an essential tool for establishing story line moods and contextual cues for the player.

Composing music for games is beyond the scope of this book. During the later chapters, however, I will point out places where music might be useful. It is always helpful to pay attention to your game play and whatever mood you are trying to achieve. Adding the right piece of music just might be what you need to achieve the desired mood.

Support Infrastructure

This is more important for persistent multiplayer online games than single player games. When we ponder game infrastructure issues, we are considering such things as databases for player scores and capabilities, auto-update tools, Web sites, support forums, and, finally, game administration and player management tools.

The following infrastructure items are beyond the scope of this book, but I present them here to make you aware that you should spend time considering what you might need to do.

Web Sites

A Web site is necessary to provide people with a place to learn news about your game, find links to important or interesting information, and download patches and fixes for your game.

A Web site provides a focal point for your game, like a storefront. If you intend to sell your game, a well-designed Web site is a necessity.

Auto-update

An auto-update program accompanies your game onto the player's system. The updater is run at game start-up and connects via the Internet to a site that you specify, looking for updated files, patches, or other data that may have changed since the user last ran the program. It then downloads the appropriate files before launching the game using the updated information.

Games like Delta Force: Blackhawk Down, World War II Online, and Everquest have an auto-update feature. When you log in to the game, the server checks to see if you need to have any part of your installation upgraded, and if so, it automatically transfers the files to your client. Some auto-updaters will download a local installer program and run it on your machine to ensure that you have the latest files.

Support Forums

Community forums or bulletin boards are a valuable tool for the developer to provide to customers. Forums are a vibrant community where players can discuss your game, its features, and the matches or games they've played against each other.You can also use forums as a feedback mechanism for customer support.

Administrative Tools

If you are developing a persistent online game, it will be important to obtain Web-based tools for creating and deleting player accounts, changing passwords, and managing whatever other uses you might encounter. You will need some sort of hosted Web service with the ability to use CGI-, Perl-, or PHP-based interactive forms or pages. Although this is not strictly necessary, you really should invest in a database to accompany the administrative tools.

Database

If you intend your game to offer any sort of persistence where players' scores, accomplishments, and settings are saved—and need to be protected from fiddling by the players on their own computers—then you probably need a database back end. Typically, the administrative tools just mentioned are used to create player records in the database, and the game server communicates with the database to authenticate users, fetch and store scores, and save and recall game settings and configurations.

A common setup would include MySQL or PostgreSQL or something similar. Again, you will probably need to subscribe to a hosted Web service that offers a database.