Delphi Graphics and Game Programming Exposed! with DirectX For versions 5.0-7.0:The Anatomy of a Game                       Search Tips   Advanced Search        Title Author Publisher ISBN    Please Select ----------- Artificial Intel Business & Mgmt Components Content Mgmt Certification Databases Enterprise Mgmt Fun/Games Groupware Hardware IBM Redbooks Intranet Dev Middleware Multimedia Networks OS Productivity Apps Programming Langs Security Soft Engineering UI Web Services Webmaster Y2K ----------- New Arrivals









Delphi Graphics and Game Programming Exposed with DirectX 7.0

by John Ayres

Wordware Publishing, Inc.

ISBN: 1556226373   Pub Date: 12/01/99














Search this book:
 



Previous Table of Contents Next The Playing State This state is responsible for the code that makes up the actual game play. All of the segments of the previous game loop presented above will be found here, such as user input processing, sprite updating, and screen drawing. The code run in this state will probably look similar to the example game loop implementation previously discussed. The Intermission State When a user has completed a level (or a series of levels or a mission), games usually enter a type of intermission state. In this state, a report is given to the user that, depending on the type of game, details the user’s accomplishments in the completed level. Such things as the number of kills, the number of secrets found or unnoticed, and the accuracy of shots are typically highlighted, as is the found or unnoticed, and the accuracy of shots are typically highlighted, as is the number of the next level or the name of the next mission. Sometimes, even an animation will be used to provide a transition from one level to the next, especially id a “chapter” of the game has been completed and an entirely new set of environments and enemies are about to be introduced. Intermission states only last a short while, setting the game state to playing once the intermission state is over. Tip: It is a good practice to provide a hot key or some other mechanism whereby a user can skip the intermission state and proceed directly back to the playing state. The Paused State The paused state is simply a suspension of game play. All game object logic and processing should be halted, including the output of sound effects and possibly even the output of music. Typically, pausing a game should simply toggle between the paused state and the playing (or intermission) state. Pausing a game should usually have no effect during a demo or game over state. Paused states are generally entered through either a hot key activation or by interacting with a user interface control (such as a button or menu item). The Game Over State In the game over state, an expanded report of the user’s accomplishments throughout the course of the game could be displayed. This includes the information displayed during the intermission state as it applies to the overall game achievements. End game animations could also be played, perhaps varying the exact animation dependent upon whether the player won or lost. The game over state usually only lasts for a short amount of time, perhaps only a little longer than the intermission state, before proceeding to the demo state. Case Study In order to further demonstrate the concepts discussed in this chapter, we should examine the case study provided on the CD in this chapter’s directory. It is a game titled Shoot ’em, where the player simply fires at oncoming enemy spaceships. It is a simple game using simple graphics, but it should serve as an example of implementing several of the topics we just covered. This is not a complete game, and many of the tasks required by a commercial quality game have been left out (such as sound and music output) so as not to complicate the code. The architecture used in this example game will be the basis for examples to come. Of particular interest to this chapter is the game loop itself. The example implements a simplistic game loop similar to the first loop architecture we’ve discussed. It is state driven, and throughout the code you can see where this state is modified and how it affects the overall game processing. This game loop is embodied in the DrawSurfaces procedure. Take a look at this procedure to get a taste of how to implement an actual game loop. This case study example is presented in its entirety to get you familiar with the types of examples demonstrated throughout the book. There are several programming techniques implemented in this example that we have yet to discuss, such as sprite manipulation. This example also contains some DirectX initialization code that we haven’t yet discussed. Peruse the first part of the example to get familiar with the function calls that we’ll be exploring in subsequent chapters. Beginning with the DrawSurfaces procedure, we see some techniques that we’ve outlined in this chapter. This example also demonstrates how to logically control such entities as sprites and background animation elements with arrays. Later in the book, we’ll extend this to a more general approach for controlling game entities. Previous Table of Contents Next 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 whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.