CHAPTER 1
INTRODUCTION TO 3D GAME DEVELOPMENT

Before we get into the nitty-gritty details of creating a game, we need to cover some background so that we can all work from the same page, so to speak. In the first part of this chapter, we will establish some common ground regarding the 3D game industry in the areas that matter—the types of games that are made and the different roles of the developers that make them. In the second part of the chapter, we’ll establish what the essential elements of a 3D game are and how we will address them.

Throughout the book you will encounter references to different genres, or types, of games, usually mentioned as examples of where a particular feature is best suited or where a certain idea may have originally appeared. In this chapter we will discuss the most common of the 3D game genres. We will also discuss game development roles; I will lay out “job descriptions” for the roles of producer, designer, programmer, artist, and quality assurance specialist (or game tester). There are various views regarding the lines that divide the responsibilities, so my descriptions are fairly generic.

Finally, we will discuss the concept of the 3D game engine. If ever there is going to be an area of dispute between a writer and his readers in a book like this, a discussion of what constitutes a 3D game engine will be it. I do have a trump card, though. In this book we will be using the Torque 3D game engine as our model of what constitutes a fully featured 3D game engine. We will use its architecture as the framework for defining the internal divisions of labor of 3D game engines.

THE COMPUTER GAME INDUSTRY

The computer game industry is somewhat different from other high-tech fields. With properties, producers, artists, and distributors, as well as its own celebrities, the computer game business operates more like Hollywood than the traditional commercial or industrial software development company. It is quite a bit more informal and relaxed than other high-tech fields in many ways but is quicker paced with a higher burnout rate. There are independent game developers, or indies, and big-name studios, but the computer game industry tends to be more entrepreneurial in spirit.

Just as is true of indies in the motion picture industry, an indie game developer is not beholden to other businesses in the industry that can direct their efforts. Indies fund their own efforts, although they sometimes can get funding from outside sources, like a venture capitalist. The key factor that makes them independent is that the funding does not come from downstream industry sources that would receive the developer’s product, like a major game development house, publisher, or distributor.

By the way, if you manage to find a venture capitalist willing to front you cash to develop your very first game as a start-up company, then I will recommend you for the Medal of Awesome. It’s not an easy thing to do.

Indies sell their product to distributors and publishers after the product is complete, or nearly so. If a developer creates a product under the direction of another company, they are no longer independent.

A good measure of the “indie-ness” of a developer is found in the answer to the following two questions:

Can the developer make any game he wants, in whatever fashion he wants?

Can the developer sell the game to whomever he wants?

If the answer is yes in both cases, then the developer is certainly an indie.

Of course, another strong similarity with movies is that, as I pointed out earlier, games are typically classified as belonging to different genres.

3D Game Genres and Styles

Game development is a creative enterprise. There are ways to categorize the game genres, but I want you to keep in mind that while some games fit each genre like a glove, many others do not. That’s the nature of creativity. Developers keep coming up with new ideas; sometimes they are jockeying for an advantage over the competition, and sometimes they are just scratching an itch. At other times, calculating marketing departments decide that mixing two popular genres is a surefire path to a secure financial future.

The first rule of creative design is that there are no rules. If you are just scratching an itch, then more power to you. If you are looking to make a difference in the gaming world, you should at least understand the arena. Let’s take a look at the most common 3D genres around today and a few that are interesting from a historical perspective. When you are trying to decide what sort of game you want to create, you should try understanding the genres and use them as guides to help focus your ideas.

It’s important to note that all of the screenshots in this chapter are of games by indie game developers. Some of the games are currently being shipped as retail games, and some are still in development. Almost all of them use the same Torque Game Engine we will use in this book to develop our own game.

By no means is this a definitive list; there are many genres that don’t exist in the 3D gaming realm, and the number of ways of combining elements of genres is just too large to bother trying to enumerate. If you take pride in your creativity, you might resist attempts to pigeonhole your game idea into one of these genres, and I wouldn’t blame you. When trying to communicate your ideas to others, however, you will find it useful to use the genres as shorthand for various collections of features, style, and game play.

Action Games

Action games come in several forms. The most popular are the First-Person Point-of-View (1st PPOV) games, where your player-character is armed, as are your opponents. The game play is executed through the eyes of your character. These sorts of games are usually called First-Person Shooter (FPS) games. Game play variations include Death Match, Capture the Flag, Attack & Defend, and King-of-the-Hill. Action games often have multiplayer online play, where your opponents are enemies controlled by real people instead of by a computer. Success in FPS games requires quick reflexes, good eye-hand coordination, and an intimate knowledge of the capabilities of your in-game weapons. Online FPS games are so popular that some games have no single-player game modes.

Some action games are strictly 3rd PPOV, where you view your player-character, or avatar, while also viewing the rest of the virtual world your avatar inhabits (see Figure 1.1).

Figure 1.1
ThinkTanks—a 3rd PPOV action game made by BraveTree Productions using the Torque Game Engine, a precursor to Torque 3D.

Modern Warfare 2, Quake 4, Half-Life 2, F.E.A.R., and Doom 3 are a few popular examples of FPS-style action games.

Adventure Games

Adventure games are basically about exploring, where player-characters go on a quest, find things, and solve puzzles. The pioneering adventure games were text based. You would type in movement commands, and as you entered each new area or room, you would be given a brief description of where you were. Phrases like “You are in a maze of twisty passages, all alike” are now gaming classics. The best adventure games play like interactive books or stories, where you as the player decide what happens next, to a certain degree.

Text adventures evolved into text-based games with static images giving the player a better idea of his surroundings. Eventually these merged with 3D modeling technology. The player was then presented with either a first- or third-person point of view of the scene his character was experiencing.

Adventure games are heavily story based and typically very linear. You have to find your way from one major accomplishment to the next. As the story develops, you soon become more capable of predicting where the game is going. Your success derives from your ability to anticipate and make the best choices.

Some well-known examples of adventure games are golden oldies like The King’s Quest series, The Longest Journey, and Syberia 2. Indigo Prophecy (aka Fahrenheit) and Heavy Rain are more recent examples.

Online multiplayer adventure games have not really come into their own yet, although some games are emerging that might fit the genre. They tend to include elements of action games and Role-Playing Games (RPGs) to fill out the game play, because the story aspect of the game is more difficult to accomplish in an online environment. Players advance at different speeds, so a monolithic linear story line would become pretty dreary to a more advanced player, without a lot of extra design effort on the part of the developers. An example of an online action-adventure-FPS hybrid game is Penny Arcade (see Figure 1.2), from Hothead Games.

Figure 1.2
Penny Arcade—an adventure-FPS hybrid game created by Hothead Games.

Role-Playing Games

Role-playing games are very popular; that popularity can probably find its roots in our early childhood. At younger than age six or seven, we often imagined and acted out exciting adventures inspired by our action figures and other toys or children’s books. As was also true for strategy games, the more mature forms of these games first evolved as pen-and-paper games, such as Dungeons & Dragons.

These games moved into the computer realm with the computer taking on more of the data-manipulation tasks of the game masters. In role-playing games the player is usually responsible for the development of his game character’s skills, physical appearance, loyalties, and other characteristics. Eventually the game environment moved from each player’s imaginations onto the computer, with rich 3D fantasy worlds populated by visually satisfying representations of buildings, monsters, and creatures (see Figure 1.3). RPGs are usually science fiction or fantasy based, with some historically oriented games being popular in certain niches.

Figure 1.3
Dreamlords—an online RPG made with Torque 3D by Lockpick Entertainment.

Maze and Puzzle Games

Maze and puzzle games are somewhat similar to each other. In a maze game you need to find your way through a “physical” maze in which your routes are defined by walls and other barriers. Early maze games were 2D, viewed from the top; more recent ones play more like 3D adventure or FPS games.

Puzzle games are often like maze games but with problems that need to be solved, instead of physical barriers, to find your way through.

Mazes also make their appearance in arcade pinball-style games, such as Marble Blast (see Figure 1.4) by GarageGames. It is a maze-and-puzzle hybrid game where you compete against the clock in an effort to navigate a marble around physical barriers. The puzzle aspect lies in determining the fastest (though not necessarily the most direct) route to the finish line.

Figure 1.4
Marble Blast—a maze-and-puzzle hybrid game by GarageGames using its Torque Game Engine.

Puzzle games sometimes use puzzles that are variations of the shell game or that are more indirect problem-solving puzzles where you must cause a series of things to happen in order to trigger some further action that lets you advance. Many puzzle games utilize direct problem-solving modes where the puzzle is presented visually. You then need to manipulate on-screen icons or controls in the correct sequences to solve the problem. The best puzzles are those where the solution can be deduced using logic. Puzzles that require pure trial-and-error problem-solving techniques tend to become tedious rather quickly. A historic example of a puzzle game is The Incredible Machine series by Dynamix. A recent variation of this type is the game Tube Twist by 21-6 Productions (see Figure 1.5).

Figure 1.5
Tube Twist: The Quantum Flux Edition—a puzzle game made by 21-6 Productions using Torque.

Simulator Games

The goal of a simulator (or sim) game is to reproduce a real-world situation as accurately as possible. The measure of the simulation accuracy is usually called its fidelity. Most simulators put a heavy emphasis on the fidelity of the visual appearance, sounds, and physics of the game.

The point is total immersion in the game environment, so that you get the feeling you are actually there. You may be flying a jet fighter or driving a thoroughbred Grand Prix racing car. The game mirrors the real-life experience to the maximum the developers can manage.

Simulators usually require specialized input devices and controllers, such as aircraft joysticks and rudder pedals. Many simulator enthusiasts build complete physical cockpit mockups to enhance the immersion experience.

Silent Steel, NASCAR Sim Racing, Falcon 4, and Rev (see Figure 1.6) are examples of simulator games.

Figure 1.6
Rev—a racing sim using Torque 3D from Luma Arcade.

Sports Games

Sports games are a variation of the simulator class of games in which the developer’s intent is to reproduce the broad experience of the game as accurately as possible. You can participate in a sports game at various levels and watch the action play out in a realistic 3D environment (see Figure 1.7).

Unlike the action-oriented flight and driving simulators, sports games usually have a manager or season angle. While playing the game you can also take on the role of coach, owner, or team manager. You can execute draft picks and trades or groom new players like any major league ball organization would. In a modern sports simulator you could be managing budgets, and you might play or race a regular year’s schedule, playing in different stadiums or arenas or racing on different tracks.

Strategy Games

Strategy games began as pen-and-paper games, like war games, and have been around for centuries. As computer technology evolved, computer-based tables and random-number generators replaced the decision-making aspects of strategy games traditionally embodied by lookup charts and dice rolls.

Figure 1.7
Maximum Football—a football sports game by David A. Winter, an independent game developer, and sold by MatrixGames.

Eventually the tabletop battlefields (or sandbox battlefields) with their cardboard markers or die-cast military miniatures moved into the computers as well. The early tabletop games were usually turn based: each player would in turn consider his options and issue “orders” to his units. Then he would throw the dice to determine the result of the orders. The players would then modify the battlefield based upon the results. After this the players would observe the new shape of the battlefield and plot their next moves. The cycle then repeated itself.

The advent of computer-based strategy games brought the concept of real time to the forefront. Now the computer determines the moves and results and then structures the battlefield accordingly. It does this on a timescale that reflects the action. This has given birth to the Real-Time Strategy (RTS) genre. Sometimes the computer will compress the timescale, and other times the computer will operate in real time, where one minute of time in the game action takes one minute in the real world. The player issues orders to his unit as he deems them to be necessary. Recently, strategy games have moved into the 3D realm, where players can view the battlefield from different angles and perspectives as they plot their next moves (see Figure 1.8).

Figure 1.8
Tribal Trouble—a 3D real-time strategy game created by indie-developer Oddlabs.

There are strategy games that exist outside the world of warfare. Examples include business strategy games and political strategy games. Some of these games are evolving into strategic simulations, like the well-known SimCity series of games.

Serious Games

Serious Games have much in common with many of the common game genres, but are more like simulations than anything else. Serious Games aren’t restricted to a particular mode of game play, or any particular genre rules. The driver for design decisions when creating a Serious Game is does it effectively teach or train or show what needs to be taught, trained, or shown? The general point is to use gaming technology to help people learn things.

The most significant gaming features that Serious Games can benefit from are scoring, repeatability, and invulnerability. Scoring provides feedback on progress and technique, repeatability allows players to keep tackling the same problems over and over until they get them right, and invulnerability allows players to take risks (simulated ones, that is) without fear of injury or death.

At TubettiWorld Games, we are developing a Serious Games platform called mSTREET, using Torque 3D as the game engine upon which we are layering capabilities and technology specifically geared toward creating Serious Game training scenarios, as shown in Figure 1.9. Several institutions, including the University of Ontario Institute of Technology and the University Health Network in Ontario (a consortium of hospitals) are developing scenarios using mSTREET.

Figure 1.9
mSTREET—a 3D Serious Game platform created by TubettiWorld Games Inc. showing a scene from a training scenario in Afghanistan.

Some Popular Retail 3D Games and Their Genres

---

If you are still unclear about what a particular genre is about, take a look at the following table. It is a list of current “big-name” game titles (including one or two that are not yet released). Be aware that you may find a website or magazine somewhere that classifies these games in a slightly different way. That’s cool—don’t worry about it.

---

Game Platforms

This book is about computer games written for personal computers. There are three dominant operating systems: Microsoft Windows, Linux, and Mac OS X. For some of these systems there are quite a few different flavors, but the differences within each system are usually negligible, or at least manageable.

Another obvious game platform type is the home game console, such as the Sony PlayStation 3, XBOX 360, or the Nintendo Wii. These are indeed important, but because of the closed nature of the development tools and the expensive licenses required to create games for them, I won’t be spending any time specifically addressing game development for consoles—they are beyond the scope of this book.

Other game platforms include mobile devices such as iPods, iPads, and iPhones, Android, and other phones and PDAs that support protocols that permit games to be played on them. Again, specifics about these platforms are also beyond the scope of this book.

However, if you visit the GarageGames website (www.garagegames.com), you will find that Torque supports development on the iPhone (and thus iPod and iPad as well), the Nintendo Wii, and the Xbox 360. Contact the Torque folks through the website if you are interested in console development using Torque 3D.

Now that those little disclaimers are out of the way, let’s take a closer look at the three game platforms of interest. It’s important to note that by using Torque 3D, you will be able to develop what amounts to a single code base for a game that you can ship for both Windows and Apple computers.

Microsoft Windows

Windows has various historical versions, but the current flavors are Windows 7, Windows Vista (cough), and Windows XP (still kicking around). In this book the expectation will be that you are developing on or for a Windows 7 target system, because that is the version that Microsoft is now selling to the home computer market.

Within Windows 7 we will be using OpenGL and Direct3D (a component of DirectX) as our low-level graphics Application Programming Interfaces (APIs). These APIs provide a means for our engine to access the features of the video adapters in our computers. Both OpenGL and Direct3D provide basically the same services, but each has its own strengths and weaknesses. With Torque you will have the choice of letting your end users use either API.

OpenGL’s greatest strength lies in its availability with different computer systems. An obvious benefit is that the developer can create a game that will work on most computers. OpenGL is an open-source product. In a nutshell this means that if there is a particular capability you want that OpenGL lacks, you can get access to the OpenGL source code and rebuild it the way you want. This assumes you have the skills, time, and tools necessary to get the job done, but you can do it.

DirectX is proprietary—it is the creation and intellectual property of Microsoft Corporation. Its biggest advantage is that it tends to support more features than OpenGL, and the 3D video adapter manufacturers tend to design their hardware to work with DirectX as much as they can. With DirectX you get a much more complete product with the most advanced feature set. Unfortunately, you are limited to Windows-based systems if you put all your eggs in the DirectX basket.

Torque 3D uses both APIs and gives you a rather straightforward set of techniques to set up your game with either. This means that in a Windows version of your game, you can offer your users the option of using the API that best suits their video adapter.

Linux

For most people, the single most important reason to use Linux is the price—it’s free. You may have to pay to get a distribution of Linux on DVD with manuals at a store, but you are paying for the cost of burning the DVD, writing and printing the manuals, and distributing the end product. You don’t have to pay for the operating system itself. In fact, you can download Linux from many different locations on the Internet.

Unfortunately, Torque has no firm plans to support the client portion of Torque 3D on Linux. However, there should be a server-only build of Torque becoming available in the near future that is expected to be officially supported. This means that you won’t be able to play a Torque 3D–based game on Linux, unless you use a Windows emulator like Wine, and run the Windows version.

There are two big reasons to be interested in a server-only build of Torque 3D for Linux:

Linux is a growing marketplace—slow, but still growing, and any market that is growing is a good target. Although the market is growing, it is still smaller than the Windows market. The places where Linux is growing the most are universities, colleges, and other postsecondary institutions—and this is probably where your best computer gaming audience is. However, many more regular computer consumers are using Linux as well, especially easily installed distributions like Ubuntu.

Linux offers a more configurable and secure environment for unattended Internet game servers. Linux servers can be run in a console mode that requires no fancy graphics, buttons, or mice. This allows you to utilize slower computers with less memory for servers and still get the computing power you need for your game server.

Unlike other operating systems, Linux comes in a variety of flavors known as distributions. There are many ongoing arguments about the merits of one distribution or another. Some of the more popular distributions are Ubuntu, Mandriva, Red Hat, SuSE, Mandrake, Debian, and Slackware. Although they may be organized differently in some cases and each has its own unique graphical look and feel, they are all based on the same kernel. It is the kernel that defines it as Linux.

Apple

Apple computers are used a great deal in art-related fields and in the art departments of many businesses. Although the price point might not be as good as Linux (where the OS and most software is free), the Mac OS X operating system is typically more accessible to the less tech-savvy users among us.

As with Linux, there has also traditionally been a dearth of computer games available for Apple computers. So the big-fish-in-a-small-ocean concept applies here. Go ahead and make a splash!

Note

---

One minor disadvantage of working with cross-platform software like Torque is the issue of naming conventions. In this book, wherever possible, I will head off the potential conflicts with a note that will cast a particular naming approach in stone for the duration of the book.

An example that will probably become obvious pretty quickly is the concept of directories or folders. The latter is shorter and easier to type, and the term will be used often. To save my editors the hassle, I will use folders. If you are a directories person, please just play along, okay?

---

Game Developer Roles

In the context of the game we will develop during our journey together through this book, you will wear all of the different game developer hats. The thing to remember is that oftentimes the lines between the roles will blur, and it might be hard to tell which hat you are wearing. So wear them all. Many indies wear multiple hats throughout the life of a game project, so it’s just as well to get used to it!

Producer

A game producer is essentially the game project’s leader. The producer will draw up and track the schedule, manage the people who do the hands-on development work, and oversee the budget and expenditures. The producer may not know how to make any part of a game at all, but he is the one person on a game project who knows everything that is happening and why.

It’s the producer who needs to poke the other developers in the ribs when they seem to be lagging. The producer must be aware when different members of the team are in need of some tool, knowledge, or resource and arrange to provide the team members with what they need.

Sometimes producers just need to spray a liberal dose of Ego-in-a-Can to refresh a despondent developer who keeps smashing into the same brick wall over and over while the clock ticks down.

The producer will also be the team’s interface with the rest of the world, handling media queries, negotiating contracts and licenses, and generally keeping the big noisy bothersome world off the backs of the development team.

Designer

If you are reading this, I have no doubt that you want to be a game designer. And why not? Game designers are like fun engineers—they create fun out of their imaginations. As a game designer, you will decide the theme and rules of the game, and you will guide the evolution of the overall feel of the game. And be warned—it had better be fun!

There are several levels of designers: lead designer, level designer, designer-writer, character designer, and so on. Large projects may have more than one person in each design role. Smaller projects may have only one designer or even a designer who also wears a programmer or artist’s hat! Or both!

Game designers need to be good communicators, and the best ones are great collaborators and persuaders. They need to get the ideas and concepts out of their heads and into the heads of the rest of the development team. Designers not only create the concept and feel of the game as a whole but also create levels and maps and help the programmers stitch together different aspects of the game.

The lead designer will put together a design document that lays out all the aspects of the game. The rest of the team will work from this document as a guide for their activities. A design document will include maps, sketches of game objects, descriptions of plot devices, flow charts, and tables of characteristics. The designer will usually write a narrative text that describes how all of these parts fit together. A well-written and thorough game design completely describes the game from the player’s perspective.

Unlike the producer, a designer needs to understand the technical aspects of the game and how the artists and programmers do what they do.

Programmer

Game programmers write program code that turns game ideas, artwork, sound, and music into a fully functional game. Game programmers control the speed and placement of the game artwork and sound. They control the cause-and-effect relationships of events, translating user inputs through internal calculations into visual and audio experiences.

There can be many different specializations in programming. In this book you will be doing a large amount of programming of game rules, character control, game event management, and scoring. You will be using TorqueScript to do all of these things.

For online game programming, specialization may also be divided between client code and server code. It is quite common to specify character and player behavior as a particular programmer specialty. Other specialty areas might be vehicle dynamics, environmental or weather control, and item management.

Other programmers on other projects might be creating parts of the 3D game engine, the networking code, the audio code, or tools for use with the engine. In our specific case these specializations aren’t needed because Torque looks after all of these things for us. We are going to focus on making the game itself.

Visual Artist

During the design stages of development, game artists draw sketches and create storyboards to illustrate and flesh out the designers’ concepts. Figure 1.10 demonstrates a conceptual design sketch created by a visual artist and used by the development team as a reference for modeling and programming work. Artists will later create all the models and texture artwork called for by the design document, including characters, buildings, vehicles, and icons.

The three principal types of 3D art are models, animations, and textures—and the artists who create these types of art are 3D modelers, animators, and texture artists, respectively.

3D modelers design and build player-characters, creatures, vehicles, and other mobile 3D constructs. In order to ensure that the game gets the best performance possible, 3D modelers usually try to make the least complex model that suits the job. A 3D modeler is very much a sculptor working with digital clay.

Figure 1.10
A conceptual design sketch.

Animators make those models move. The same artist quite often does both modeling and animation.

Texture artists create images that are wrapped around the constructs created by 3D modelers. Texture artists take photographs or paint pictures of various surfaces for use in these texture images. The texture is then wrapped around the objects in question in a process called texture mapping. Texture artists help the 3D modelers reduce the model complexity by using highly detailed and cleverly designed textures. The intent is to fool the eye into seeing more detail than is actually there. If a 3D modeler molds a sculpture in digital clay, the texture artist paints that sculpture with digital paint.

Audio Artist

Audio artists compose the music and sound in a game. Good designers work with creative and inspired audio artists to create musical compositions that intensify the game experience.

Audio artists work closely with the game designers to determine where the sound effects are needed and what the character of the sounds should be. Audio artists often spend quite a bit of time experimenting with sound-effect sources, looking for different ways to generate the precise sound needed. Visit an audio artist at work and you might catch him slapping rulers and dropping boxes in front of a microphone. After capturing the basic sound, an audio artist will then massage the sound with sound-editing tools to vary the pitch, to speed it up or slow it down, to remove unwanted noise, and so on. It’s often a tightrope walk balancing realistic sounds with the need to exaggerate certain characteristics in order to make the right point in the game context.

Quality Assurance Specialist

Quality Assurance (QA) is a somewhat fancy name for testing. The general field of QA is more extensive than that, of course, but in the game business game testers take the brunt of the QA load. The purpose of testing is to ensure that a finished game is really finished, with as few bugs or problems as humanly possible. QA testing requires the quality assurance specialist, or game tester, to play each part of a game, trying to flush out all glitches and bugs.

Most of the problems QA testing will find are visual or behavioral: text that doesn’t properly wrap on an edge, characters that don’t jump correctly, or a level that has buildings misplaced. Testing can find game play problems; these are usually related more to the design than the programming. An example could be that the running speed of a player might not be fast enough to escape a particular enemy when it should be more than fast enough.

QA specialists need to be methodical in order to increase the chances of finding a bug. This might mean replaying a certain part of a game many times to the point of boredom. QA specialists need to be able to communicate well in order to write useful and meaningful bug reports.

Publishing Your Game

You can self-publish, of course. Whip up a website, add a shopping cart system, get your site added to various search engines, and sit back to wait for the dough to roll in, right? Well, it might work.

If you really think you have the next killer game and want it to sell, however, you need to hook up with someone who knows what they are doing. That would be a publisher. If you are an independent game developer, you will probably have difficulty attracting the attention of the big-name publishers. They usually know what they are looking for, are normally only interested in developers with proven track records, and probably already know whom they want to deal with anyway.

But all is not lost—there are options available for the indie. The one I recommend is GarageGames (www.garagegames.com). Besides offering competitive publishing terms for indie developers, GarageGames also created Torque 3D, which it has graciously agreed to allow me to include on the DVD for this book. Torque is the technology behind the popular and successful Tribes series of games, and a raft of other more recent commercial games that you can find by browsing the GarageGames website. I’m going to help you learn how to use Torque 3D as an enormous lever in creating your game.

But wait—there’s more! If you really need to, you can buy a license from Garage-Games for Torque 3D that will give you (under the terms of the license) example game scripts, plus the binaries and C++ source code for the engine, so you can turn any game dream into a reality—for only $179! That’s under two hundred bucks for full access to the inner workings of an award-winning AAA 3D game engine. As the Hulk would say, “...” Actually, I don’t think he would say anything. He’d probably smash something, after having been overcome with exuberance.

I have no qualms about suggesting that you go to GarageGames. They know their stuff, and they are not some gormless and faceless corporate entity. They’re basically a few baskets full of people who’ve made their way in the corporate computer game industry, and now they’re doing their level best to help the independent game developers of the world make their own fortunes.

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 so you’ll have 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.11 for a block diagram that depicts the major feature areas.

Figure 1.11
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 F.E.A.R., Quake 4, Half-Life 2, or Unreal Tournament 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 Torque 3D from GarageGames. Torque 3D is included on the DVD with this book. Later on we will discuss Torque 3D in more detail—and you will eventually come to understand why Torque 3D 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 TorqueScript 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.12 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 overlaid 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 top of it. This capability is provided by Torque 3D as part of the definition of the button control.

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

Figure 1.12
An example of a main menu GUI.

Models

3D models (see Figure 1.13) 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.13
A 3D wire-frame model and a textured model of a Korean War–era 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.14) 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.14
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.15 shows a sound-effect waveform being manipulated in a waveform-editing program.

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.

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

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, websites, 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.

Websites

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

A website provides a focal point for your game, like a storefront. If you intend to sell your game, a well-designed website 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.

Many games, like the Delta Force series, Battlefield Europe, and World of Warcraft, have an auto-update feature. Web-based distribution systems, like Steam from Valve, also provide such capability. 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 help 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 SQLite or something similar. Again, you will probably need to subscribe to a hosted web service that offers a database.

TORQUE 3D

I’ve mentioned Torque 3D several times already. I think now would be a good time to take a little deeper look at the engine and how you will be using it.

Appendix A provides a reference for Torque 3D, so look there if you really need more detail.

Descriptions

The following descriptions are by no means exhaustive, but a cup of coffee would go well with this section. Go ahead and make some—I’ll wait. Black with one sweetener, please.

Moving right along, you should note that the main reason for including this section is to give you, the Gentle Reader, the right sense of how much behind-the-scenes work is done for you by the engine.

Basic Control Flow

Torque 3D initializes libraries and game functions and then cycles in the main game loop until the program is terminated. The main loop basically calls platform library functions to produce platform events, which then drive the main simulation.

Torque handles all of the basic event procession functions as follows:

Dispatches Windows mouse movement events to the GUI

Processes other input-related events

Calculates elapsed time based on the timescale setting of the simulation

Manages processing time for server objects

Checks for server network packet transmission

Advances simulation event time

Processes time for client objects

Checks for client network packet transmission

Renders the current frame

Checks for network timeouts

Platform Layer

The platform layer provides a cross-platform architecture interface to the engine. The platform layer is responsible for handling file and network operations, graphics initialization, user input, and events.

Console

The console library provides the foundation for Torque-based games. The console has both a compiler and an interpreter. All GUIs, game objects, game logic, and interfaces are handled through the console. The console language is called Torque-Script and is similar to a typeless C++, with some additional features that facilitate game development. You can load console scripts using a command from the console window as well as automatically from files.

Input Model

Input events are translated in the platform layer and then posted to the game. By default the game checks the input event against a global action map that supersedes all other action handlers. If there is no action specified for the event, it is passed on to the GUI system. If the GUI does not handle the input event, it is passed to the currently active (nonglobal) action map stack.

Platform-specific code translates Win32, or OS X events into uniform Torque input events. These events are posted into the main application event queue.

Action maps translate platform input events to console commands. Any platform input event can be bound in a single generic way—so in theory, the game doesn’t need to know if the event came from the keyboard, the mouse, the joystick, or some other input device. This allows users of the game to map keys and actions according to their own preferences.

Simulation

A stream of events drives the game from the platform library: InputEvent, MouseMoveEvent, PacketReceiveEvent, TimeEvent, QuitEvent, ConsoleEvent, ConnectedReceiveEvent, ConnectedAcceptEvent, and ConnectedNotifyEvent. By journaling the stream of events from the platform layer, the game portion of the simulation session can be deterministically replayed for debugging purposes.

The simulation of objects is handled almost entirely in the game portion of the engine. Objects that need to be notified of the passage of time can be added to one of the two process lists: the global server or global client process list, depending on whether the object is a server object or a client ghost.

Server-side objects are only simulated at certain times, but client objects, in order to present a smooth view when the frame rate is high, are simulated after each time event.

There is a simulator class that manages all of the objects and events in the simulation. Objects are collected in a hierarchy of simulator classes and can be searched for by name or by object ID.

Resource Manager

Torque 3D uses many game resources. Terrain files, bitmaps, shapes, material lists, fonts, and interiors are all examples of game resources. Torque has a resource manager that it uses to manage large numbers of game resources and to provide a common interface for loading and saving resources. Under the auspices of Torque’s resource manager, only one instance of a resource will ever be loaded at a time.

Graphics

Torque 3D does not perform its own graphics rasterization; instead, it uses the OpenGL or DirectX graphics API. Torque includes a utility library that extends the APIs to support higher-level primitives and resources.

Torque 3D has a collection of utility functions that add support for complex primitives and resources like fonts and bitmaps and that add simple functions for more easily managing textures and 2D rasterization.

There is also a texture manager that tracks the loading and unloading of all textures in the game. Only one instance of a texture is ever loaded at a given time; after loading it is handed off to OpenGL or DirectX. When the game switches graphics modes or video devices, the texture manager can transparently reload and redownload all the game’s textures.

Torque supports several bitmap file types: DDS, PNG, JPEG, GIF, BMP, and the custom BM8 format, an 8-bit color texture format used to minimize texture memory overhead.

The GUI library manages the user interface of Torque games. It is designed specifically for the needs of game user interface development. The Canvas object is the root of the active GUI hierarchy. It dispatches mouse and keyboard events, manages update regions and cursors, and calls the appropriate render methods when it is time to draw the next frame. The Canvas keeps track of content controls, which are separate hierarchies of controls that render from bottom to top. The main content control is a screen in the shell that can be covered by any number of floating windows or dialog boxes.

A Profile class maintains common instance data across a set of controls. Information such as font face, colors, bitmaps, and sound data are all stored in instances of the Profile class, so that they don’t need to be replicated on each control.

A Control class is the root class for all the GUI controls in the system. A control can contain any number of child controls. Each control maintains a bounding rectangle in the coordinate system of its parent control. The Control class processes input events, rendering, and mouse focus and coordinates automatic sizing.

3D Rendering

The Torque library has a modular, extensible 3D world rendering system. Game subclasses first define the camera orientation and field of view and then draw the 3D scene using OpenGL drawing commands. A class manages the setting up of the viewport as well as the model view and projection matrices. A function returns the viewing camera of the current control object (the object in the simulation that the player is currently controlling), and then the engine calls the client scene graph object to render the world.

On the client, a scene graph library is responsible for traversing the world scene and determining which objects in the world should be rendered given the current camera position, while on the server, it determines what objects should be sent to each client based on that client’s position in the world. The world is divided into zones, which are volumes of space bounded by solid areas and portals. The outside world is a single zone, and interior objects can have multiple interior zones. The engine finds the zone of a given 3D point and which object owns that zone. The engine then determines which zone or zones contain an object instance. At render time the scene is traversed starting from the zone that contains the camera, clipping each zone’s objects to the visible portal set from the zones before it. The engine also performs the scoping of network objects, deciding whether a given object needs to be dealt with by a client.

Every world object in the scene that can be rendered is derived from a single base class. As the world is traversed, visible objects are asked to prepare one or more render images that are then inserted into the current scene. Render images are sorted based on translucency and then rendered. This system permits an interior object with multiple translucent windows to render the building first, followed by other objects, and then followed by the building’s windows. Objects can insert any number of images for rendering.

Terrain

The terrain library deals with objects that render a model of the outside world. It contains a sky object that renders the outside skybox, animates and renders cloud layers, and applies the visible distance and fog distance settings for when the world as a whole is rendered. The sky object also generates the vertical fog layers and sends them into the SceneGraph object for rendering. The TerrainBlock class provides a single 256 × 256 infinitely repeating block of heightfield terrain. Heightfield data is stored and loaded by the resource manager so that a single terrain data file can be shared between server and client.

The terrain is textured by blending base material textures with program code into new material textures and then mapping those across multiple terrain squares based on the distance from the square. The Blender class performs the blending of terrain textures and includes a special assembly version to speed things up when executing on × 86 architectures.

A Waterblock object utilizes shaders to dynamically render water effects based on distance, making nearby water more tessellated and detailed. Water coverage of an area can be set to seed fill from a point on the surface, allowing the water to fill a depression to form a lake without leaking outside the corners.

Shapes and Animation

A library manages the display and animation of shape models in the world. This library’s shape resource class can be shared between multiple shape instances. The shape class manages all the static data for a shape: mesh data, animation keyframes, material lists, decal information, triggers, and detail levels. An instance class manages animation, rendering, and detail selection for an instance of a shape. The instance class uses the thread class to manage one of the concurrently running animations on an instance. Each thread can be individually advanced in time or can be set on a timescale that is used when all threads are advanced. A thread can also manage transitions between sequences.

Animation sequences can be composed of node/bone animation (for example, joints in an explosion), material animation (a texture animation on an explosion), and mesh animation (a morphing blob; note that most mesh animations can be accomplished with node scale and rotation animations). Animations can also contain visibility tracks so that some meshes in the shape are not visible until an animation is played.

Networking

Torque was designed from the foundation to offer robust client/server network simulation support. The networking design of Torque was driven by the need for superior network performance over the Internet. Torque addresses three fundamental problems of real-time network programming: limited bandwidth, packet loss, and latency. For a more detailed, if somewhat outdated, description of the Torque network architecture, see “The Tribes II Engine Networking Model,” an article by Tim Gift and Mark Frohnmayer, at the Torque site (http://www.garagegames.com). An instance of a Torque game can be set up as a dedicated server, a client, or both client and server. If the game is both client and server, it still behaves as a client connected to a server, but the netcode has a short-circuit link to other netcode in the same game instance, and no data goes out to the network.

Bandwidth is a problem because of the large, open terrain environments Torque supports, as well as the large number of clients Torque can handle—up to 128 or more per server, which means that there is a high probability that many different objects can be moving and updating at the same time. Torque uses several strategies to maximize available bandwidth:

It sends updates to what is most important to a client at a greater frequency than it updates data that is less important.

It sends only the absolute minimum number of bits needed for a given piece of data.

It only sends the part of the object state that has changed.

It caches common strings and data so that they need only be transmitted once.

Packet loss is a problem because the information in lost data packets must somehow be retransmitted, yet in many cases the data in the dropped packet, if sent again directly, will be stale by the time it gets to the client.

Latency is a problem in the simulation because the network delay in data transmission makes the client’s view of the world perpetually out of sync with the server. Twitch-style FPS games, for which Torque was initially designed, require instant control response in order to feel anything but sluggish. Also, fast-moving objects can be difficult for highly latent players to hit. In order to solve these problems, Torque employs the following strategies:

Interpolation is used to smoothly move an object from where the client thinks it is to where the server says it is.

Extrapolation is used to guess where the object is going based on its state and rules of movement.

Prediction is used to form an educated guess about where an object is going based on rules of movement and client input.

The network architecture is layered. At the bottom is the OS/platform layer, above that the notify protocol layer, which is followed by the NetConnection object and event management layer.

Using Torque 3D in This Book

As you’ve seen, Torque 3D is powerful, feature rich, flexible, and controllable. What we will do in this book is create all of the different elements of the game that we’ll need and then write game control script code to tie it all together.

Program code, artwork, and audio resources you will need are included on the companion DVD, along with the tools to manipulate them and create your own.

At first glance that may not seem to be too daunting a task. But remember, we will be wearing all of the game developer hats. So we will be creating our own models (players, buildings, decorations, and terrains), recording our own sound effects, placing all of these things in a virtual world of our own fabrication, and then devising game rules and their scripted implementations to make it all happen.

Daunted much?

Hey, it’s not going to be that hard. We’ve got Torque 3D!

INSTALLING TORQUE 3D

The companion DVD contains all the materials you will need to follow on with the chapters: the Torque 3D executable, Torque 3D demos and tutorial base, any required art and script resources, plus useful tools. Everything you need will be in the folder called 3D3E.

Some of the tools, which will be located in the 3D3ETOOLS folder, may require installation before you use them. Not all of the supplied tools are required in order for you to follow along in the book. Some are provided as a courtesy in case you do not have another suitable tool for a particular task.

If the text absolutely requires you to use a specific tool to complete a procedure outlined in the book, the text will tell you where to find and install it or otherwise use it for that task.

To install Torque 3D for use with the book, insert the companion DVD into your DVD drive, and follow the on-screen instructions. When you have finished, the layout of the hard drive will match the layout of the companion DVD, so anywhere you see the folder 3D3E or any of its subfolders described in the text, you will be able to find it on your hard drive or on the companion DVD. The EXTRAS folder on the DVD is not needed in order to use the book, however.

When you insert the DVD, the autorun script should look after everything for you, including installing Torque 3D. However, if it doesn’t, you can manually install the DVD quite easily.

1. On the DVD, select the folder 3D3E, and drag it over to the root of your hard drive to initiate the copy from the DVD. For most people, the hard drive volume will be C:, but if you have other volumes or drives on your computer, you can copy to another drive instead. Just remember where you put it!

2. On the hard drive where you copied the DVD to, locate the Torque_3D_Tools_ Demo_1.1-Win.exe installer in the 3D3ETOOLSTORQUEWINDOWS folder and run it by double-clicking on it.

3. Answer the prompts for the license agreement and so on, but when you are asked where to install the Demo, do not use the default location or name. Instead, point the installer at the 3D3E folder, and change the name of the installation to “DEMO” (the installer wants to use that inconveniently long name “Program FilesT3DToolsDemo1.1” which, well, just sucks).

4. After completing this installation, browse your way into the 3D3EDEMOExamplesFPS Examplegame folder and take note of the contents.

The folder you arrived at in step 4 is where the Torque 3D Tools Demo engine executable is found. I will be referring to this as the Torque 3D root folder. Or sometimes just as the Torque 3D folder or even simply game folder. You need to remember this, because it gets really awkward when referring to paths inside this folder. I’m sure more than one person’s eyes would go crossed when seeing pages of instructions telling the reader to open the file 3D3ET3DToolsDemo1.1ExamplesFPS ExamplegameartshapesitemspatchhealthBB.png and repeatedly do things with it.

It’s much more polite to say to go to the “game” folder and look for the file art shapesitemspatchhealthBB.png. Well, I think it is anyway.

So the game folder is the same as... (everyone together now) 3D3EDEMOExamples FPS Examplegame. Good job.

For Apple-based Users

---

For readers using Mac OS X on Apple computers, the Torque 3D Tools Demo installer is located in 3D3E TOOLSTORQUEAPPLE. However, the companion DVD’s installation procedure may not work for you. The scripts and artwork from the book’s examples will work on Macintosh and Linux systems, providing you have run the correct demo installation from the 3D3ETOOLSTORQUEAPPLE folder on the companion DVD installed for your operating system.

When using the installers described here, please make sure that your destination directory or folder during the installation is 3D3EDEMO and not the default installer path. This is to ensure that your installation paths match the paths described in the book. You might need to create the 3D3E folder manually before running an installer.

---

In the book you might sometimes see folders that use full path names (like 3D3E democlientinit.cs, for example) and other times you will see partial path names (like RESOURCESch2). The drive letter will never be included. This means that the path to the folder will be appropriate no matter which hard drive or volume you install to. With the partial paths it will be obvious where the folders are. RESOURCES is always a subfolder of 3D3E, for instance, as are the TOOLS and DEMO folders.

Note

---

Throughout the book you will see references to the FPS Example or the PhysX Example. These are Torque 3D demo programs, set to run the FPS Example or PhysX missions.

The Torque 3D installer also installs a nifty utility called the Torque 3D Toolbox—Figure 1.16 shows an example of what the Toolbox looks like. This should be your entry point to using Torque 3D, and the IDE called Torsion. A shortcut will have been added to your desktop, into your Programs menu, and maybe even in your Task Manager Quick Launch bar. You should always use the Toolbox to run Torque 3D

Figure 1.16
The Torque 3D Toolbox.

Run the FPS Example by locating the FPS Example button in the Torque 3D Toolbox. It will probably be the lower button on the left-hand side, in the section titled “Examples.” Click on the FPS Example button, to highlight it, then click on the button called Play Game. The FPS Example game will launch. Also note that you can quickly browse to the FPS Example folder by clicking on the Open Folder button. When it opens the folder, you will see a subfolder called “game.” That is your Torque 3D root folder for the FPS Example.

In addition to the FPS Example shoot-’em-up demo, there is a physics demo for you to play with as well. It’s the top button on the left, called PhysX Demo in the Demos section.

---

MOVING RIGHT ALONG

There you go. You now have the basic Torque 3D engine plus some sample games installed. Enjoy!

Of course, if you are following along with the game development in this book, you may need to return to the DVD and install all the other components when they are needed.

In this chapter we looked at computer games from many different angles—the industry, the genres, and the different roles of developers. And we explored the kinds of things that make a game engine work and how they relate to each other.

In the next chapter we’ll get into the basics of programming. We’ll use the Torque 3D Engine itself to run our example programs as we work through the chapter. This will develop skills you’ll need in later chapters when we start delving into real game programming scripts.