3D Game Programming All In One (2004)

578 Chapter 20 ■ Game Sound and Music

%impulseVec = %vec[%i]; break;

}

}

if (%forced && %success == -1) %pos = %oldPos;

%obj.unmount();

%obj.setControlObject(%obj); %obj.mountVehicle = false;

// Position above dismount point %obj.setTransform(%pos);

%obj.applyImpulse(%pos, VectorScale(%impulseVec, %obj.getDataBlock().mass));

}

This code allows us to get in (mount) the car and then get out (dismount). There's nothing about the sound in there, but it is convenient to have this ability.

Now use the same procedures with the World Editor as with the Tommy gun to insert the car into the game world. You will find the car in the Tree view under Shapes, Vehicles. Remember to tug the model up out of the ground if it's embedded in the ground—but don't tug it too hard!

Run up to the car, and you will automatically go inside and be seated. Use the normal forward movement key (Up Arrow) to accelerate, and the mouse to steer left and right. Have at it!

Environmental Sounds

A silent world is a dreary one. You can liven up your game world by inserting sounds to give a sense of the environment using AudioEmitters.

First, copy the file C:\3DGPAi1\RESOURCES\CH20\LOON.WAV over to C:\koob\control\data\sounds\.

Then open C:\koob\control\server\misc\sndprofiles.cs and add the following AudioProfile to the end of the file:

datablock AudioProfile(LoonSound)

{

filename = "~/data/sound/loon.wav";

description = AudioDefaultLooping3d;

};

Run your game, and open the World Editor and then the World Editor Creator as before.

Team LRN

Interface Sounds

579

Next, in the Tree view, locate Mission Objects, environment, AudioEmitter as shown in Figure 20.8. Click AudioEmitter while facing a location where you would like to place the AudioEmitter.

In the dialog box presented (see Figure 20.9), click the Sound Profile button. From the list that opens, choose the LoonSound Profile.

Make sure the Use profile's desc?, Looping?, and Is 3D sound? check boxes are selected, and then click OK. Check Figure 20.9 to verify the settings.

An AudioEmitter marker will be placed in the game world at the center of your screen, on the ground, as shown in Figure 20.10.

Now exit the editor by toggling the F11 key, make sure you are in camera fly mode, and move up and away from where you placed the marker. Then go back in to the editor. You should see two concentric spheres, as shown in Figure 20.11. The inner sphere is very faintly defined with gray lines in the figure, while the outer sphere is defined with black lines. In the Torque editor, the inner sphere is made with red lines, and the outer sphere is made with blue lines.

The inner sphere represents the reference (or minimum) distance, and the outer sphere represents the maximum distance. The larger the outer sphere, the more gradual the drop-off in sound as you move away from the emitter. The larger the inner sphere, the farther the sound will carry.

Press F3 to switch to World Editor Inspector, and then click the hand cursor on the marker. At the bottom right, the editor frame contains the properties for the object, as show in Figure 20.12.

You can use this frame to adjust the settings for the emitter. Click the buttons in the Inspector frame to expand a selection of properties. After making changes, make sure to click the Apply button to have your changes applied to the selected object.

Interface Sounds

Figure 20.8 AudioEmitter in Tree view.

Torque has a mechanism built in to offer sound effects when	Figure 20.9 The Building
you use buttons. Objects that use the GuiDefaultProfile	Object: AudioEmitter dialog box.

Team LRN

580 Chapter 20 ■ Game Sound and Music

		profile have two sound effects
		available: soundButtonDown	and
		soundButtonOver.
		If you look in C:\koob\control\
		client\default_profiles, you will find a
		sound effect for the buttonover con-
		text that I've created. This sound
		occurs whenever the cursor passes
		over a GUI button that has been
		defined to use the GuiDefaultProfile.
		The line looks like this:
		GuiButtonProfile.soundButtonOver =
Figure 20.10 The AudioEmitter marker.
		"AudioButtonOver";
		It points the property to an
		AudioProfile. The profile is located in
		C:\koob\control\client\initialize.cs. The
		profile is located there and not in the
		sndprofiles.cs module because I need it
		to load before the menu with the but-
		tons comes up. The AudioButtonOver
		profile looks like this:
		new AudioProfile(AudioButtonOver)
		{
		filename = "~/data/sound/but-
		tonOver.wav";
Figure 20.11 The AudioEmitter spheres.
		description = "AudioGui";
		preload = true;
		};

It's pretty straightforward. A useful exercise for you at this point would be to create a sound effect for pressing down on the button, insert the appropriate audio profile code, and then point the soundButtonDown property at it, just as I showed you for the soundButtonOver property.

	Music
Figure 20.12 World Editor	You can handle music in much the same way as the
Inspector frame.	simple sound effect I showed you at the beginning of

Team LRN

Music 581

this chapter. A useful way to employ music is to provide a background for the different dialog boxes or menu screens in the GUI. Of course, you can also insert music into the game as AudioEmitters or even attach it to vehicles or players.

We'll take a slightly more conventional approach and put in some start-up music. First, locate the file C:\3DGPAi1\RESOURCES\CH20\TWLOGO.WAV and copy it over to C:\koob\control\data\sounds\.

Next, open the file C:\koob\control\client\misc\initialize.cs and add the following code to the top of the file:

new AudioDescription(AudioMusic)

{

volume	= 0.8;
isLooping= false;
is3D	=	false;
type	=	$MusicAudioType;

};

new AudioProfile(AudioIntroMusicProfile)

{

filename = "~/data/sound/twlogo.wav"; description = "AudioMusic";

preload = true;

};

function PlayMusic(%handle)

{

if (!alxIsPlaying(%handle)) alxPlay(%handle);

}

function StopMusic(%handle)

{

if (alxIsPlaying(%handle)) alxStop(%handle);

}

Now scroll down a bit until you find this line:

SetNetPort(0);

Add the following after it:

StartMusic(AudioIntroMusicProfile);

Team LRN

CommandToClient(XXXX)/

582Chapter 20 ■ Game Sound and Music

This will start the opening music playing shortly after the first window appears once the game application has been launched.

Now open the file C:\koob\control\client\client.cs and insert the following line as the first line in the LaunchGame() function:

StopMusic(AudioIntroMusicProfile);

This line will ensure that if the opening music is still playing when you actually go to start the game, it will be turned off.

Now go ahead and launch the game and listen to the music.

You can use the same technique in combination with the

clientCmdXXXX system that we've used in earlier chapters to have the server trigger music cues on all or selected clients whenever you want.

Moving Right Along

There you go, enough sound that the people around you will be pestering you to turn the blasted game down!

You've seen the ways that sounds can be added for player-avatars, vehicles, and weapons. You've seen what a state machine does and how it helps define what sounds occur, and when, when using a weapon.

Then there's the ability to hurl insults at other players—a very important feature to know how to put into a game!

You've seen how to add sounds into your game world at specific locations, so that you can bring life to a babbling brook, or a howling wind on an open plain.

Adding sounds to the user interfaces, like buttons on interface screens, is really reasonably simple, as you've seen.

Finally, adding music to your game is really no more complex than any other sound, and in some cases, easier. You've seen how you can control the playing of music using Torque Script.

In the next chapter, we begin rolling all the things covered in earlier chapters together, by starting to create a game world.

Team LRN

chapter 21

Creating the

Game Mission

Let's take a moment to step back and see where we are. In the first chapters of the book you learned the basics of programming and how to apply those concepts to real things that can be done with a modern game engine. In the process you

learned how to use a programming editor—UltraEdit—and how to use Torque to try out our ideas. You saw that Torque has a powerful script system and the things you can do with it are almost limitless.

We then moved on to artwork, starting with textures and graphic images. You learned about a couple of new tools—Paint Shop Pro and UVMapper—and how to apply them to the task of skinning 3D objects and GUI screens.

Then we got into modeling 3D objects, using a few more tools—MilkShape and QuArK— to create the models using different techniques. Animating our objects using MilkShape helped bring static models to life.

After that, it was on to some nifty things like creating skyboxes and images for weather effects, such as lightning and rain.

Then it was sound effects, recording them and using them in a game in different ways.

Now you might think that all of this is leading somewhere! And you would be right.

Game Design

Okay, enough typing and programming for now. It's time to examine some higher-level issues, like game design.

583

Team LRN

584Chapter 21 ■ Creating the Game Mission

Start with a vision.

You have an idea. It can be an amorphous, gee-I'm-not-really-sure-but-something-like- this idea, or it can be concrete, specific, and detailed. Using that as your reference, start asking yourself questions, write them down, and don't worry about answering them…yet.

Requirements

There are a myriad of questions you can ask yourself when considering the design of your game:

■What will the genre or play style be like?

■Will this be a single-player or multiplayer game?

■If it is to be a multiplayer game, will it be an online game or a split-screen type of multiplayer game?

■Does the game relate to real-world activities?

■Does the player play as a creature (human, animal, alien, and so on) character or as some sort of machine?

■If the player isn't a creature or a machine, is he some sort of higher-level being that directs or controls a multitude of game entities?

■What are the player's goals?

■How do we measure player success and what are the scoring mechanisms?

■What are the challenges that the game presents to us as players?

■Will the challenges be designed (planned by the game developers) or will they be random?

■What is the backstory—the narrative that describes the world the game takes place in, if any?

■What is it about the game that will make people want to play it?

■What is the one skill or skill set that the game requires the player to master in order to succeed?

■What other skills will contribute to player success?

■What mechanisms can the game offer that will help players develop those skills?

■How much game enhancement of skills is too much help?

Feel free to add more questions of your own.

As you can see the list is big, and we've only scratched the surface here. By answering these questions, and any others you may want to add, we can build a list of requirements. It is important to generate at least this list—the requirements specification—in order to know where we are going with our design and how to measure our progress toward completion.

Team LRN

Game Design 585

Software design is a Big Ticket Item, and hundreds of books have been written about it and the various design methodologies that have been proposed. It's an industry unto itself. There are dozens of different ideas about the best approach to take—and much disagreement. The one area everyone seems to agree on, however, is the need for the requirements to be determined and recorded in a meaningful way. Functional specs, test plans, schedules, and the like may or may not work for you, but you will get nowhere fast if you don't know what it is you are trying to accomplish.

Some of the questions lead to other questions. Some answers may need to be deferred until later when you have more information. Even if your list of questions exceeds your list of answers, it is still an important activity. Keep the list nearby, return to it regularly, and update the answers. See where it leads you. Perhaps you can see that you are wandering away from your original vision. The list may uncover things you'd never considered before, that really are important, and prevent you from wasting time on a mistaken approach.

When you work your way through creating the questions, try hard to stay general—steer away from specifics until they can't be avoided any longer.

At some point you will want to ask yourself, "What technology should I use to create this game?" Don't ask this question at the very beginning. In most cases you should wait until you know the answers to the bulk of your questions—in other words, wait until your requirements are starting to look meaty and useful—before you ask yourself technology questions.

Constraints

We usually have to accept that there are constraints that can arbitrarily force us to move in particular directions or prevent us from moving in others.

The design should drive the technology and not the other way around. However, in a lowbudget development shop, this is often an unaffordable luxury. There are budgetary constraints caused by available funds that will force us in certain technological directions. In our case, because this book is about making games with minimal expenditure and using the Torque Game Engine to help us achieve that goal, we will have to accept that constraint and monitor the effect it has on our design as we build it up.

Again in our case, because we already know the technology we are going to use, we should examine it for its limitations and measure our constraints starting there.

As mentioned elsewhere Torque is designed for online, multiplayer, first-person shooterstyle games. This means that whenever implementation tradeoffs had to occur when creating the game engine, the developers always tried to make their decisions in a way that favored efficient and fast networking, first-person perspective 3D rendering, and multiplayer support.

Team LRN

586Chapter 21 ■ Creating the Game Mission

One of things that Torque, right out of the box, doesn't address in its design is massive multiplayer support. Torque can easily handle 64 players logged in to one session. It can even handle more than 100. In fact, there is no hard-coded limit to the number of players that could log in to the same server. But because of its design, Torque really starts to lose its shine when you exceed the realm of about 100 players.

Massively multiplayer games require the ability to have thousands of players playing the same game together. Torque just doesn't handle this kind of load.

So the server load is a constraint. While Torque's ability to handle 100 players at once is better than most, if not all, other FPS-style games out there, that still doesn't translate to thousands. We must keep this in mind.

The tools we have available can dictate other constraints. It's fine to decide that you will have a certain feature, but it may require an expensive 3D modeling tool to create and thus sit out of reach. So make sure you can create the things you want.

Koob

So let's go about listing some requirements for Koob, the game we are making. Feel free to add your own, but the list of 29 items here will serve as a starting place.

1.First-person and third-person perspective play.

2.Internet multiplayer game play.

3.Global in-game chat.

4.Ability to use at least one weapon.

5.Ability to get in and out of vehicles.

6.Ability to drive vehicles.

7.A road or track in the world to drive on.

8.Trees and other foliage.

9.Powerups: health, energy, ammunition, coins (for points).

10.Buildings that serve as hiding places and storage locations for powerups.

11.All other players are enemies.

12.All point values configurable from a setup file.

13.1 point per enemy killed.

14.3 points per vehicle destroyed.

15.Ability to race around the track and score 5 points for each lap you lead.

16.Laps can only be scored in the car.

17.A 10-lap race with no time limit.

18.A 10-point bonus for winning the race.

Team LRN

Torque Mission Editor

587

19.On-screen scorecard.

20.Scores retained at the end of each race restored when player resumes the game.

21.Each player gets an account at startup and must use a password to log in to the game.

22.Track must be clearly marked on the terrain.

23.Checkpoints along the way to measure progress and ensure the player stays on course.

24.Laps can only be completed when all checkpoints are completed for that lap.

25.Checkpoints must be completed in sequential order.

26.Coins of three denominations will be randomly scattered around the maps. The values will be 1 point, 10 points, and 100 points for copper, silver, and gold, respectively.

27.Some nice burning objects to admire as we play.

28.A waterfall to drive through just for the heck of it.

29.When one map is finished, cycle to the next in the list.

So as you can probably gather, Koob is a kind of death match scavenger hunt game. The player tries to win the race, accumulate some loot, and, at the same time, stop his enemies from winning.

As we progress from here to the end of the book, we'll check back against this list of requirements to make sure we've covered all the items.

Right off the bat, we can check off item 1. A few of the other items are definitely doable because we've chosen the Torque Engine to create the game, but we have some programming yet to do to make them happen.

Torque Mission Editor

You've already been exposed to the Mission Editor—a little bit here, a little bit there. As you've seen, the Mission Editor contains several subeditors: the World Editor, Terrain Editor, Terrain Terraformer Editor, Terrain Texture Editor, and Mission Area Editor. The main point of this section is to place objects in the game world and adjust them as required. To do this we will use the World Editor, which has two components: the World Editor Creator and its partner, the World Editor Inspector.

In the Mission Editor the normal movement keys can be used to control both the player and the camera. The right mouse button is used to rotate the camera or adjust the player's view.

Disk and file operations are carried out using the items in the File menu, as shown in Table 21.1. These include opening, saving, importing, and exporting.

Team LRN