Tricks of the Windows Game Programming Gurus:Algorithms, Data Structures, Memory Management, and Multithreading

All ITKnowledge Source Code Search Tips Advanced Search |

| Tricks of the Windows Game Programming Gurus by Andre LaMothe Sams, Macmillan Computer Publishing ISBN: 0672313618 Pub Date: 09/27/99

Search this book:

Previous | Table of Contents | Next

### Strategies for Saving the Game

One of the biggest pains in the butt is writing a save game feature. This is one of those things that all game programmers do last, and do by the seat of their pants in most cases. The key is to write your game with the idea that you’re going to want to give the player a save game option at some point. That way you won’t paint yourself into a corner.

To save at any point in the game means to record the state of every single variable and every single object in the game. Hence, you must record all global variables in a file along with the state of every single object. The best way to approach this is with an object-oriented thought process. Instead of writing a function that writes out the state of each object and all the global variables, a better idea is to teach each object how to write and read its own state to a disk file.

To save a game, all you need to do is write the globals and then create a simple function that tells each game object to write out its state. Then, to load the game back in, all you need to do is read the globals back into the system and then load the states of all the objects back into the game.

This way, if you add another object or object type, the loading/saving process is localized in the object itself rather than strewn about all over the place.

### Implementing Multiple Players

The next little bit of game programming legerdemain is implementing multiple players. Of course, if you want to implement a networked game, that’s a whole other story, although DirectPlay makes the communication part easy, at least. However, if all you want to do is let two or more players play your game at the same time or take turns, that requires nothing more than some extra data structures and a bit of housekeeping.

#### Taking Turns

Implementing turn-taking is easy and hard at the same time. It’s easy because if you can implement one player, implementing two or more only requires having more than one player record. It’s hard because you must save the game for each player when switching players. Hence, usually you need to implement a save game option if you want to have turn-taking. Obviously, the players shouldn’t know that the game is being saved as they take turns, but that’s what’s really going on.

With that in mind, here’s a list of the steps that you would follow to allow two players to play, one after another:

  1. Start game; player 1 starts.
  2. Player 1 plays until she dies.
  3. The state of player 1’s game is saved; player 2 starts.
  4. Player 2 plays until he dies.
  5. The state of player 2’s game is saved (here comes the transition).
  6. The previously saved player 1 game is reloaded, and player 1 continues.
  7. Go back to step 2.

As you can see, step 5 is where the action starts happening and the game starts pinging back and forth between players. If you want more than two players, simply play them one at a time until you’re at the end of the list, and then start over.

#### Split-Screen Setups

Enabling two or more players to play on the same screen is a little harder than swapping because you have to write the game a little more generally as far as gameplay, collision, and interaction between the players are concerned. Moreover, with multiple players in the game at the same time, you must allocate a specific input device for each player. This usually means a joystick for each player, or maybe one player uses the keyboard and one uses the joystick.

The other problem with putting multiple players in the game at the same time is that some games just aren’t good for it. In a scrolling game, for example, one player might want to go one way while the other wants to go another way. This can cause a conflict, and you’ll have to plan for this. Thus, the best games for multiple players are single-screen fighting games, or games in which the players stay relatively near each other for one reason or another.

But if you want to allow the players to roam around freely, you can always create a split-screen display, as shown in Figure 11.14.

Figure 11.14 Split-screen game display.

The only problem with the split-screen display is—the split-screen display! You must generate two or more views of the game, which can be technically challenging. Moreover, there might not be enough room on the screen to fit the two or more views, and the players might find it hard to see what’s going on. But the bottom line is, if you can pull it off, it’s a cool option…

### Multithreaded Programming Techniques

Up to this point, all the demos in this book have used a single threaded event loop and programming model. The event loop reacts to the player’s input and renders the game at a rate of 30+ fps. Along with reacting to the player, the game performs millions of operations per second, along with processing dozens if not hundreds of small tasks, such as drawing all the objects, retrieving input, making music, and so on. Figure 11.15 shows the standard game loop that you’ve been using.

Figure 11.15 Standard DOS single-tasking game loop.

As you can see from Figure 11.15, the game logic performs all the tasks of the game in a serial/sequential manner. Of course, there are exceptions to this, including interrupts that can perform simple logic such as music and input control, but for the most part, a game is one long sequence of function calls that repeat forever.

What makes a game seem fluid and real is the fact that even though everything is performed in sequence, step by step, the computer is so fast that it all seems as if it’s happening at once. Hence, the model that most game programmers use is a single tasking execution thread that performs many operations in series to arrive at the desired output for each frame. This is one of the best ways to do things and is a side effect of DOS game programming.

However, the days of DOS are over, so it’s time that you start using the multithreaded abilities of Windows 95/98/NT/2000 and, well, liking it!

This section is going to cover the threads of execution under Windows 95/98/NT. These threads allow you to run multiple tasks within the same application with very little drama. Now, before you get started, let’s cover a little terminology so that this simple subject isn’t alien to you.

Previous | Table of Contents | Next

Copyright © Macmillan Computer Publishing, Inc.

Products | Contact Us | About Us | Privacy | Ad Info | Home
Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.