TankersThe Next Game Idea


The puzzle game you created in earlier chapters was pretty fun to write. Many of the basic concepts you needed to write a great game were included in the application, even though it was decidedly simple, both in implementation and game play. Now, with those concepts still freshly ingrained into your brain, it's the perfect time to begin expanding on them and coming up with an even more challenging game.

This new game will not only include the concepts that were addressed in the last chapter, but will also add more challenges to the development. Nowadays, virtually all the games on the market have at least some aspect of multiplayer support. Many times, the game can't be considered "complete" without this support, so naturally you want to include the ability to play this new game over the Internet. You also want to include sound in the game, which was lacking in the last one.

So what type of game should you write now? You still haven't dug all the way into the concepts you need to understand for an overly complex game, so this one should be more difficult than the last one but not so overly difficult that it becomes frustrating. For this section, you should concentrate on writing a multiplayer tank-battle game.

In this game, the players will be in some field of combat, or arena. With two players in the arena, the objective of the game is to disable the other player's tank before that player can disable yours. Rather than a large open arena, the battlefield will have obstacles that will help shield your player from the opponent's. So as you did with the last game, you should get a list of all the features to implement in this game.

Detailing the Proposal

With the basic idea I just outlined, you can create the list of features you want this game to support:

  • This arcade-type battle game is called Tankers.

  • Multiple players will play via the Internet.

  • The environment will be fully 3D.

  • The object is disabling the opponent's tank.

  • The game will contain multiple battlefields.

  • Each battlefield will contain obstacles that provide cover.

  • Player movement will be controlled with either keyboard, mouse, or joystick.

  • Hitting an opponent's tank three times will disable it.

  • After disabling the opponent's tank, the player will respawn at its original location.

  • Disabling the opponent's tank three times will win the game.

  • Each player's tank gun turret and barrel can be moved independently of the tank.

Once again, this list shouldn't be considered exhaustive because, obviously, it won't be. If you remember the classic game Combat for the Atari 2600, you have a rough idea of the inspiration for this game. This list is a nice road map to start with, though. Once more, you want to design a rough object model for this game, which you can see in Figure 11.1.

Figure 11.1. A high-level object diagram for the game.


As you can see here, the magic cloud that is the game engine once again makes its appearance. The game engine will be the central repository for virtually everything that happens in the game. It will interact with a few new items as well. You have a new sound device, which will output the audio data to the speakers, as well as a networking layer, which will communicate with the Internet. Actually, it will just communicate with a secondary machine via Transmission Control Protocol/Internet Protocol (TCP/IP), but close enough.

Obviously, you also need a player object to represent both your tank and the opponent's tank, which will be accessed from the game engine. The battlefield is also a separate object, and each of the arenas will be stored locally on the file system. The other objects are still around from your first game, namely the high-precision timer and the rendering device, which will output the data to the screen.

The overall diagram still has items missing, such as the user interface screens, which will drive the player interaction before the game actually starts. The goal of this exercise is not to provide an exhaustive look at the scope of the project, but to get you thinking about the items you need to implement in a broad sense.

Remember from the last game, the final product didn't match the initial diagram exactly, but it did have the rough guidelines in place.

You might realize pretty quickly that many of the items used in the Blockers game can be brought over wholesale for this new game. Without wasting any time, you should get right into writing code, and I explain things as we move along. It's been my experience that you learn more from doing than hearing (or in this case, reading), so now is the time to get started.



Beginning 3D Game Programming
Beginning 3D Game Programming
ISBN: 0672326612
EAN: 2147483647
Year: 2003
Pages: 191
Authors: Tom Miller

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net