Building XNA 2.0 Games- P8 potx

At the class level in Character, add the following: public const int TEAM_GOOD_GUYS = 0; public const int TEAM_BAD_GUYS = 1; public int Team;... Id = newId; Team = newTeam; Now that our

a soft spray of dust, as shown in Figure 7-11 (it looks better in motion, obviously).

Figure 7-11 Bullet ricochet

Adding Zombies

Shooting the earth is fun enough, but what we really need here are some undead punching

bags, and not a moment too soon! We’re all the way to Chapter 7 with nary a monster in sight,

so, without further ado, let’s make some zombies!

We need to start off with some graphics We’ll use a few new images: head2.png, torso2.png,

and legs2.png, as shown in Figure 7-12

Figure 7-12 Zombie parts

We’ll add these images to the Content project in two solutions: CharacterEditor and

ZombieSmashers We also need to upgrade CharacterEditor again to allow the user to specify

which textures to use

Zombies in the Character Editor

First, we’ll change the arrays as created in Game1.LoadContent() to contain two indices

Fortu-nately, we don’t need to change the loading, because we coded it to automatically load the

textures based on the length of the array

legsTex = new Texture2D[2];

torsoTex = new Texture2D[2];

headTex = new Texture2D[2];

weaponTex = new Texture2D[1];

Let’s add a new tab to our low-budget triggers/script tab area, turning it into a triggers/

script/textures tab area We’ll start by creating a new class-level constant:

const int AUX_SCRIPT = 0;

const int AUX_TRIGS = 1;

const int AUX_TEXTURES = 2;

Now we’ll draw our texture-selection panel in Draw() We’ll just be iterating through the

four texture indices, incrementing, decrementing, and drawing text

#region Texture Switching

if (auxMode == AUX_TEXTURES)

{

for (int i = 0; i < 4; i++)

case 1:

if (charDef.TorsoIndex > 0) charDef.TorsoIndex ; break;

case 2:

if (charDef.LegsIndex > 0) charDef.LegsIndex ; break;

Finally, we add a third tab button to our triggers/script/texture area:

#region Script/Trigs Selector

Our texture selection panel (and zombie) is shown in Figure 7-13

We’ve set up the zombie with some simple animations: idle, fly, land, and run—which

we’ve dealt with before—and hit, which will become a new reserved word animation that we’ll

set a character to when it has been hit

Figure 7-13 Texture selection and a brand-new zombie

Bringing Zombies into the Game

Now let’s bring the zombie into ZombieSmashers First, put the zombie.zmx file into data/chars, and make sure to include it in the project and select Copy If Newer Now is probably a good time to add a new field to Character to specify which team that character is on (the good guys

or the bad guys) At the class level in Character, add the following:

public const int TEAM_GOOD_GUYS = 0;

public const int TEAM_BAD_GUYS = 1;

public int Team;

Then change the constructor to this:

public Character(Vector2 newLoc,

CharDef newCharDef, int newId, int newTeam)

{

Id = newId;

Team = newTeam;

Now that our Character class has a new team field and constructor, we need to update

Game1.Initialize() to load the new zombie file and create characters using the new constructor

charDef[(int)CharacterType.Guy] = new CharDef("chars/guy");

charDef[(int)CharacterType.Zombie] = new CharDef("chars/zombie");

We deemed it prudent to make eight zombies, spaced at 100-pixel intervals across our

map They will just spawn in the sky, land, and stand there

for (int i = 1; i < 9; i++){

Now, in Draw(), we’ll draw all existing characters instead of just the guy at index 0 Change

the character[0].Draw() line as follows:

for (int i = 0; i < character.Length; i++)

if (character[i] != null)

character[i].Draw(spriteBatch);

There! We’ve added our zombie character definition file zombie.zmx to ZombieSmashers,

parsed the file as CharacterType.Zombie, created eight zombies, and are now drawing all

char-acters every frame The result is shown in Figure 7-14 We don’t have hit collision yet, but that’s

coming up soon

Figure 7-14 Zombies in a row

Time for the fun part!

if (hitLoc.X > Location.X - 50f * Scale &&

hitLoc.X < Location.X + 50f * Scale &&

hitLoc.Y > Location.Y - 190f * Scale &&

hitLoc.Y < Location.Y + 10f * Scale)

return true;

return false;

}

Let’s create a class to manage all things related to hitting characters; we’ll call it HitManager

We’ll use it to iterate through valid characters, determine if characters are fair game, and figure

out what to do with characters that get hit We are also going to do some refactoring in the

Particle class, adding some properties for Owner, and making both Location and Trajectory

into public fields

CharDir tFace = GetFaceFromTraj(p.Trajectory);

for (int i = 0; i < c.Length; i++)

{

We’ll want to make sure characters can’t hurt themselves with their own particles

(other-wise, we could end up hitting ourselves with our own bullets):

public void MakeBulletBlood(Vector2 loc, Vector2 traj)

class Blood : Particle

When we update the blood, we want it to be slightly affected by gravity, but not so much

that it doesn’t seem a bit misty

public override void Update(float gameTime, Map map,

ParticleManager pMan, Character[] c)

{

Trajectory.Y += gameTime * 100f;

if (Trajectory.X < -10f) Trajectory.X += gameTime * 200f;

if (Trajectory.X > 10f) Trajectory.X -= gameTime * 200f;

rotation = GlobalFunctions.GetAngle(Vector2.Zero, Trajectory);

base.Update(gameTime, map, pMan, c);

Figure 7-15 Zombie shooting!

There we have it! We can shoot zombies, and it looks good

More Zombie Smashing

Let’s put the wrench to use We have a couple of combos mapped out in our guy’s character

definition file, but they won’t do anything until we create some hit triggers and implement

them in the game Starting at the class level of CharacterEditor, define the triggers as follows:

const int TRIG_WRENCH_UP = 3;

const int TRIG_WRENCH_DOWN = 4;

const int TRIG_WRENCH_DIAG_UP = 5;

const int TRIG_WRENCH_DIAG_DOWN = 6;

const int TRIG_WRENCH_UPPERCUT = 7;

const int TRIG_WRENCH_SMACKDOWN = 8;

const int TRIG_KICK = 9;

Each trigger has a slightly different direction; some of them won’t even be used yet When

our guy swings his wrench down and across, that’s TRIG_WRENCH_DIAG_DOWN When he swings it

in a wide arc up, that’s TRIG_WRENCH_UP It’s easy to figure out the rest

Normally, this would be considered very poor code design for a few reasons The biggest issue with declaring constants such as these, or even putting them in an enumeration, is that they are completely dependent on you implementing them in the code In the grand scheme of game development, implementation of what kind of attacks are allowed and how they are carried out should be split between the game designers and the artists In this way, artists can draw the attacks and weapons, and the designers can let the game engine know they exist This way, no major pieces of code need to be written whenever a new attack is developed However, you are

an independent developer trying to get your game out quickly, so this is excusable for now.Let’s move on and make sure to add the string names in GetTrigName() of

ever-so-With all of our spanner-whacking triggers set up, let’s implement the action in ZombieSmashers The first order of business is to bring the new trigger constants (the same ones declared at the class level of CharacterEditor—TRIG_PISTOL_UP, TRIG_PISTOL_DOWN, and so on) to the Character class-level declarations

Figure 7-16 Wrench triggers

Next, let’s create a new Particle called Hit We’ll use Hit for any trigger that’s a one-shot

attack By one-shot, we mean that the particle is spawned, checks for impact at Update(), and

dies Here’s what Hit looks like:

class Hit : Particle

public override void Update(float gameTime,

traj += Rand.G etRandomVector2(-100f, 100f, -100f, 100f);

for (int i = 0; i < 64; i++)

AddParticle(new Blood(loc, traj *

Here, we create 128 particles of blood—what a mess! Of those, 64 will be “exit wound” type

splatters—they will fire off in a tighter cone in the direction of the strike The other 64 particles

will be “entry splatter”—they will come in the opposite direction of the strike and will be in

looser form

We still have a few odds and ends to work out Let’s start with Game1.slowTime We use that

for Matrix-esque pauses in action—to accent strikes and to build anticipation for devastating

moves We declare Game1.SlowTime in the Game1 class-level declarations as follows:

private static float slowTime = 0f;

public static float SlowTime

{

get { return slowTime; }

set { slowTime = value; }

}

Then, in Game1.Update(), we reduce frameTime by a factor of 10 if slowTime is greater than

zero This way, if we want a half second of pause, we set slowTime to 0.5

Now that we are using our own timing system that allows us to slow down time, we need

to make sure our Character class uses it Ensure that frameTime in Game1 is a private static field,

and then expose it via a static property Then, in the Character.Update() method, change the

local variable et to use the Game1.FrameTime property

float et = Game1.FrameTime;

//float et = (float)gameTime.ElapsedGameTime.TotalSeconds;

The next step in the Character class is to make sure we are firing the hits correctly In the

FireTrig() method, update the switch case statement to add a default case

private void Land()

• Manually move colliding players so that they are not colliding This is most commonly used, and will give a solid-looking collision response

• Change the colliding characters’ trajectories so that they eventually will not be colliding This is what was originally used in The Dishwasher game It gives sort of sloppy collisions, in that it’s possible for fast-moving characters to pass through each other

• Add a new collision trajectory to the colliding characters’ trajectories This is what was eventually used for The Dishwasher When tweaked properly, it provides a slightly bouncy collision response that isn’t too weak

We chose to go with the third technique We use essentially the first technique for map

collision detection, so you get a good lesson on that as well

In the Character class at the class level, let’s declare our collision trajectory value:

public float ColMove = 0f;

Then in Update(), we’ll detect and respond to character-to-character collisions:

#region Collison w/ other characters

for (int i = 0; i < c.Length; i++)

The next section basically compares our location with that of the other character We

might want to change these values, depending on the feel of the collision response

if (Location.X > c[i].Location.X - 90f * c[i].Scale &&

Location.X < c[i].Location.X + 90f * c[i].Scale &&

Location.Y > c[i].Location.Y - 120f * c[i].Scale &&

Location.Y < c[i].Location.Y + 10f * c[i].Scale)

{

We’ve detected a collision; now let’s respond We calculate dif as a value that scales up as

the two characters get closer to each other Then we set our colMove value and the other

char-acter’s colMove value to opposite values of dif, to move them apart

float dif = (float)Math.Abs

We’ll reduce the value of ColMove to zero, giving our colliding characters a sort of springy response.

Location.X += ColMove * et;

We’re going to include ColMove when we call CheckXCol() The new function looks like this:public void CheckXCol(Vector2 pLoc)

Figure 7-17 Fun air combos!

Conclusion

Finally, we got to do all the fun stuff in this chapter! Let’s go over the improvements we put into

Zombie Smashers XNA:

• Implemented a particle system with a particle manager, particle bass class, and a bunch

• Added a hit manager to manage hits, obviously

• Implemented collision detection, giving the movement and combat a good feel

Finally, our project resembles a real game that can actually be played! After all, what would

a game called Zombie Smashers be without any actual zombie smashing? However, this isn’t the end, because neither our hero or the zombies can die What this game needs is a goal and ways to impede the player’s progress toward that goal What does this mean in reality? More blood, death, and zombie destruction

■ ■ ■

XACT Audio, Rumble, and More

Sensory Overload

At this point, we have a robust game-playing system—a world we can run and jump around

in, zombies to shoot and bash, some fun revolver and wrench moves to shoot and bash

zombies with, and oodles of cool combat effects But something is definitely missing, and, as

the chapter title suggests, that something is audio

To understand the impact audio will have on our game (or any game), consider a game

that has sold millions of copies Think of your favorite game, and now imagine it without sound

Remember how when you fire a gun in a shooter game, you can hear the bullets fire, ricochet,

and hit your target Now try to imagine firing the gun without sound Audio not only provides

entertainment value, but it also gives the player feedback as to what is going on in the game

And as a rule of thumb, the more feedback you can give players without crowding them, the

better the game will be

Audio is another area where a scripting system really shines Before we had the idea of the

character-scripting system, we hard-coded all of the sound Needless to say, our older games

didn’t have any really complex audio expression! Of course, there are still instances when we

can hard-code sound For example, remember our Character.Land() function? We set the

character animation to hitland where appropriate, and with that, we could play a thumping

sound If we had to hard-code every character to make the thumping sound in hitland, it

would be a hassle Then again, if we want different characters to make different thumping

sounds, we might just want to forego the hard-coding Food for thought!

Because this is the sensory overload chapter, we’re also going to implement some rumble

Rumble is often not implemented in games that target the casual game-playing audience, and

it is more than frequently left out of games developed by hobbyists We think that rumble is

necessary in most game types, because it gives the player feedback through another area:

touch Players have sound, as you will see in this chapter, and players already have visual

feed-back Tactile feedback can help players know immediately what is going on with their character

and his surroundings

Obtaining and Editing Audio

So, we’re setting out to add audio to our game We can’t do much if we don’t have any good

sound files in the first place, can we?

And after we get those audio files, we’ll need to edit them to suit our game Much like the particle systems we created previously, generating good audio is more an art than it is a science It takes a lot of practice, some creativity, and a lot of testing

Getting Sound Files

Getting sound files can be a tricky process Unlike graphics, clean audio is not really something

an amateur developer without any expensive equipment can produce This leaves us with a few options:

Find free sounds: This leads to licensing issues and has varying results A few good sites to go to

are FlashKit (www.flashkit.com) and the Freesound Project (http://freesound.iua.upf.edu/)

Buy sounds: This may also lead to licensing issues, but typically provides better results than

the free route A number of web sites sell sounds; we like Sounddogs (www.sounddogs.com)

Record your own sounds: This typically provides the worst results of all, unless you are a

professional audio person—in which case, congratulations, you have a fallback career!We’re going to go with the first option because it provides the best balance between quality

and cost But remember that the term free usually means a few things One major disadvantage

of using free resources is that their license is often restrictive If you’re looking to make money off your game, we suggest you get good licenses with your audio The second large problem with free resources is that you will often find them used in many places Be sure to look over as much audio as you can stand before deciding

■ Tip You can often record some interesting sounds using items found around the house Trash cans (metal) and pots make excellent clangs, and if you are lucky enough to have a younger brother, he may let you hit him

over the head a few times! You may not have professional equipment, but having some sound is what is

important For instance, just for fun, a few friends created a Tower Defense clone (a game that involves a lot

of sounds) using XNA During the development process, it was important to get sounds working as soon as possible to know where and how they would fit in While the team scoured the Internet for decent sounds, they used placeholder sounds, including those that literally consisted of the developers saying words like “click” for a button click It may not have been pretty, but it worked well enough while the rest of the game was developed

For Zombie Smashers, we used some sounds from FlashKit If you go to the Sound FX section

of the site and search within the Mayhem category, you should be in pretty good shape! natively, you can use the sound files included with the downloadable materials for this book (available from the Source Code/Download section of www.apress.com) We’ve provided all the audio files used in this chapter

Alter-We’ll use an assortment of smacking and crunching sounds:

• Slapstick punch

• Cracking bones