Beginning CSharp Game Programming (2005) [eng]

Joysticks 241

static GameState state = null;

<snip>

}

The game title is there again, but everything else is different.

Game options and a device block (which hold all of your device options and devices) are in there as well. The devices and device options are public-static so that everything in your game can access them; so if any part of your program needs a graphics device, it can get it by accessing Game.devices.Graphics. While it’s generally bad practice to have global objects, it’s not a big deal in this case because there are not a lot of real-world situations in which a player will need to access different sets of devices on the same machine.

There are also state objects: a stack of states and state, which stores the current state. state is just a helper that makes it easier to get the current state. Instead of constantly coding

(GameState)states.Peek(), you can just write state instead.

Changing States

There are two functions that govern the changing of states: StateChange and AddState. StateChange takes a GameStateChange object and changes the state using that object; and AddState simply takes a new GameState object and switches to it.

Here’s StateChange:

void StateChange( GameStateChange change )

{

//current state is terminated, pop it off if( change.Terminated )

states.Pop();

//push on the new state, if any

if( change.NextState != null ) states.Push( change.NextState );

// if any states in stack, set to top if( states.Count != 0 )

state = (GameState)states.Peek();

else

state = null;

}

The code is pretty self-explanatory. The only part you might be concerned with is the last one. If there are no more states in the stack, then state is set to null. This means that the game is over, and that the game loop will check to see if state is null. You’ll see this behavior later on.

242Chapter 10 Putting Together a Game

The other function:

void AddState( GameState newstate )

{

states.Push( newstate ); state = newstate;

}

The Game Loop

The game loop is very similar to the loop from the old framework you’ve seen previously, except that it uses states instead of hard-coded functions. Take a look at it:

public void Run()

{

//define a state change so we’re not constantly creating

//one on the stack

GameStateChange result = null;

// loop while state is valid while( state != null )

{

//render the current scene state.Render();

//only process input while focused if( this.Focused == true )

state.ProcessInput();

//process a frame of animation result = state.ProcessFrame();

//change the state if a state change is requested if( result != null )

StateChange( result );

//handle all events

Application.DoEvents();

}

}

In overall form, this game loop very similar to the old framework’s Run function. The main difference is that instead of calling global Render, ProcessInput, and ProcessFrame functions, you’re now calling those functions on the current state object.

Joysticks 243

t i p

In a real-world situation, you’ll probably want to call Application.DoEvents at a much lower rate in a separate thread. The reason for this is that the function does a lot of memory allocation, thus causing significant slowdowns in your game.

The Entry Point

The last part of the framework is the entry point, which loads the game and runs it:

static void Main()

{

Game game; try

{

//show the setup form to gather device options Setup setup = new Setup( options ); setup.ShowDialog();

//create a new game form

game = new Game();

//initialize the devices devices.Initialize( options, game );

//initialize the game objects InitializeGlobalResources();

//initialize the game state game.AddState( new SampleState() );

//show the form and run it game.Show();

game.Run();

}

catch( Exception e )

{

MessageBox.Show( “Error: “ + e.Message + “\n” + e.ToString());

}

}

This is very similar to the old version of the framework, with a few key changes. The first change is that the Setup form is created in order to gather user preferences. Once that is done, the game is created, the devices are initialized, the global resources are initialized, and the demo starts running a SampleState. That’s pretty much all there is to it!

244 Chapter 10 Putting Together a Game

Generic Space Shooter 3000

Generic Space Shooter 3000 is based on the new framework you just learned about, which makes it pretty easy to design a game.

Game Objects

In the next subsections, I’ll describe all of the various game objects that are created and used throughout GSS3K.

The Loader

The very first object I created for GSS3K was a game object loader, which loads all of the game resources. In GSS3K, the game loader is all hard-coded, which is actually not the best way to go about it, but will work for the purposes of this book.

t i p

Instead of hard-coding your game resources, it’s better to have resource file lists, which are simply files that tell the game which resources it should load. Better yet, you could create your own archive file, which would store everything you needed into one large file and tell the game how to load it all. Most modern games use this approach.

This loader contains helper functions and static variables that will be used as templates in the game.

Here’s part of the class with all of the code cut out:

public class GameObjectLoader

{

// define all the textures

public static D3D.Texture[] ShipTextures; public static D3D.Texture[] ProjectileTextures; public static D3D.Texture[] PowerupTextures; public static D3D.Texture[] PowerBars;

public static DS.SecondaryBuffer[] Bloops; public static DS.SecondaryBuffer[] FiringSounds; public static DS.SecondaryBuffer[] Explosions;

The class has numerous arrays of textures and sound buffers. These contain, as you would imagine, textures and sound buffers for all of the objects in the game. All of these objects are loaded using the following functions:

// load all the objects

public static void LoadObjects()

static void LoadTextures() static void LoadSounds()

// helpers:

public static D3D.Texture LoadTexture( string filename ) public static DS.SecondaryBuffer LoadSound( string filename )

The last two functions contain code you’ve seen before; they exist only to simplify the loading of textures and sounds, so you don’t have to mess up your code trying to remember a million different parameters. I’m going to show you a bit of the LoadObjects function later on; for now, let me show you the rest of the class:

public static Powerup RandomPowerup()

// static templates:

public static Spaceship Player = new Spaceship( 100, 200.0f, 0.5f, 0 ); public static Spaceship Enemy0 = new Spaceship( 5, 0, 0.0f, 10 ); public static Spaceship Enemy1 = new Spaceship( 10, 0, 0.0f, 15 ); public static Spaceship Enemy2 = new Spaceship( 15, 0, 0.0f, 20 ); public static Spaceship[] Enemies =

new Spaceship[3] { Enemy0, Enemy1, Enemy2 };

public static Projectile Laser = new Projectile(); public static Projectile Plasma = new Projectile(); public static Projectile Missile = new Projectile();

}

RandomPowerup returns a new random PowerUp object, which I will get to later on. The rest of the objects listed are all templates, static Spaceships and Projectiles that will be used to generate actual game objects.

As you can see in the code, there are four different kinds of spaceships and three different kinds of projectiles. The values used for the spaceships will become apparent later on, when I show you the Spaceship class.

For now, I’ll show you a bit of the LoadObjects function:

public static void LoadObjects()

{

LoadTextures();

LoadSounds();

// set player textures and sizing Player.Texture = ShipTextures[1]; Player.Scale = 0.25f; Player.Center();

246 Chapter 10 Putting Together a Game

Player.AddWeapon( new LaserWeapon() );

<snip>

}

The static Player object is created at load-time, when your program runs. As Player is a static, it is created and its constructor is called even before your program runs the Main function.

Keep in mind that a Player is a Spaceship, which is a GameObject, which in turn is a Sprite, which contains a Texture object. You can’t create a texture without a graphics device, and you don’t want to create a graphics device before you get options from the user, which means that the Player object is created before the textures are even loaded into the game. This has the unfortunate result of requiring the game to go back and set the Player texture later on, which is precisely what the LoadObjects function does.

When you create the Player object with

public static Spaceship Player = new Spaceship( 100, 200.0f, 0.5f, 0 );

you can only set options like its energy, speed, shields, and score. You can’t set its texture because the textures haven’t even been loaded yet.

This is where the LoadObjects function comes in. It loads all of the textures and sounds, and then sets the texture of the Player and the scale, then tells Player to center itself, and adds a LaserWeapon.

n o t e

Ship textures are at 256×256, which are huge for sprites. For GSS3K, they’ve been scaled to 25 percent of the size, making them 64×64. This is the kind of data that you should be storing on disk, however, and not hard-coding into the game. This is just a quick-and-dirty solution.

The rest of the function is similar; it loads the other ships and the projectile templates.

The Base Game Object Class

I touched on this earlier: Most of the game objects (the Spaceships, Projectiles, and PowerUps, in particular) share many common attributes, such as physics data and sprite data. Therefore, it’s logical to create a base class for all of these objects. Here it is, with the code cut out of it:

public class GameObject : Sprite, System.ICloneable

{

// data:

bool destroyed = false;

float vx, vy, ax, ay;

System.Drawing.Rectangle bounding;

248 Chapter 10 Putting Together a Game

The final function is the Clone function, which you get from inheriting the ICloneable interface. You have to implement it yourself, however:

public object Clone( )

{

return MemberwiseClone();

}

This simply calls the MemberwiseClone function, which you get from the Object class. MemberwiseClone simply copies all of the references of the object and places them into a new object and returns it.

n o t e

The process of copying the references into a new object and returning it is known as a shallow copy because everything is only copied on one level. Let me give you an example: As the GameObject class inherits from Sprite, it has a Direct3D.Texture reference in it. This shallow copy will create a brand-new GameObject, but that new object will point to the same texture object as the original does. The opposite of the shallow copy process is a deep copy. A deep copy of a game object would actually create a brand-new texture identical to the original texture, and the new object will point to the new texture instead of having two objects pointing at the same texture. You must implement deep copies yourself because C# doesn’t provide an automatic method for doing so.

The Spaceship Class

Spaceships are the most complex of the game objects and have the most data in them. Here’s a listing of the data:

public class Spaceship : GameObject

{

float energy; float speed; float shields;

float nextfire = 0;

System.Collections.ArrayList weapons = new System.Collections.ArrayList(); int currentweapon = 0;

int score; <snip>

}

All of the data has been described before, when I went over what data the game objects will have. Some of the variables that ships have are energy, speed, shields, the next firing time, an array-list of weapons, the index of the current weapon, and the score of the ship.

None of these variables is public, and for a very good reason: The spaceships use properties to enforce that certain values don’t go above or below given values. For example, the

energy of a ship can’t go above 100, and if it goes to 0 or below, the ship is destroyed. Furthermore, whenever the energy of a ship is decreased, the damage amount needs to be scaled based on the current shield value.

That’s a lot of extra processing; I take care of it all using the Energy property:

public float Energy

{

get { return energy; } set

{

//figure out how much energy is changing float delta = value - energy;

//energy drain, calculate shield absorption if( delta < 0 )

{

delta *= (1.0f - Shields); Shields -= 0.02f;

}

energy += delta;

// make sure energy doesn’t go below 0 or above 100 if( energy <= 0 )

{

Destroyed = true; energy = 0;

}

if( energy > 100.0f ) energy = 100.0f;

}

}

That’s a lot of code, but it makes absolutely certain that the rules are always enforced. The get code is pretty simple; it just returns the raw energy value.

The set code is where all the magic is done. First it figures out the delta value, or how much the energy is changing. This is particularly important because if the energy is being drained, then the shields should take some of that damage. If the shields are taking the damage, the delta value is multiplied by the shields’ absorption rate. If the shields are at 1.0, for example, then the delta is multiplied by 0, meaning exactly 0 damage is done to the energy; then the shields are decreased in power by 2 percent. After that, the delta is added to the raw energy value, and the function checks to see if the energy went below 0