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 We have examined games in terms of the general tasks that are performed. Additionally, games can be examined from the standpoint of their current mode of execution. When a game is first launched, it is considered to be in one mode of execution, but when a new game is started and the user is actually playing, it is in a totally different mode of execution. Our current game loop does not support this functionality. What is needed is a technique by which the game can be put into specific modes of execution, or states. For example, when the game is first launched, it should be initialized to a demo state. Other states, such as an intermission state or a game over state, will control what parts of the game loop are executed, and will display the appropriate output. To extend our game loop, we will assume that it supports a game with five states: •  Demo •  Playing •  Intermission •  Paused •  Game Over Each different state would involve executing code appropriate only for that state. Through each iteration of the game loop, the current state is checked, and an appropriate set of functions is executed that produces output (and retrieves input) commensurate with that state. Figure 2-4:  Controlling the game through states This could be implemented by using a case statement. The game states could be represented as an enumerated type. Then, when the game loop is executed, the case statement would jump to the appropriate code for the current state. The game state could then be set elsewhere as dictated by user input or the results of game object actions, which would subsequently change the output of the game loop on the next iteration. For example, if collision detection results in the destruction of the final enemy, the current level could be advanced and the game state set to Intermission. After the collision detection code and the rest of the game loop for the current state has finished, the next iteration through the game loop will flow through the Intermission section of code. Listing 2-2 demonstrates a possible implementation of this technique. Listing 2-2: Game state implementation type TGameState = (gsDemo, gsPlaying, gsIntermission, gsPaused, gsGameOver); var GameState: TGameState; . . . procedure GameLoop; begin while GameRunning do case GameState of gsDemo : begin {demo code} end; gsPlaying : begin {game play code} end; gsIntermission : begin {intermission code} end; gsPaused : begin {paused code} end; gsGameOver : begin {game over code} end; end; end; This technique requires the case statement to be executed over and over. If this becomes a speed issue, this technique could be modified such that each case statement entry jumps to a function that contains its own internal loop. That internal loop would then continue until the game state changes. When this occurs, the internal loop exits, and the main game loop must be called again to switch execution into another function with its own internal loop. This modification is illustrated in Figure 2-5. Technically, an internal loop may simply display a static graphic and then pause for an appropriate period of time, such as for an intermission, instead of performing some sort of animation loop. However, static screens are usually pretty boring. Figure 2-5:  A modified game state looping architecture Designing a game application in this manner allows it to be controlled in a very logical and ordered manner. The state of a game can flow from one state to another as appropriate, changing between logical states and ultimately creating a circuit or loop from game beginning through game play to game end and back again. For example, games may start in the demo state, switching into the playing state when a user starts a game. This state will move back and forth between the paused state and the intermission state as the user finishes levels and plays the game. Ultimately, the user will finish the game or will die, at which point the state will switch to the game over state, and finally back to the demo state, where the entire process can be restarted anew. Figure 2-6 illustrates the flow of game logic through a typical game loop constructed in this manner. Figure 2-6:  The flow of game states Each state’s code is responsible for supplying specific output or retrieving specific input, as appropriate for the intention of that state. Some games may have more states than others; other games may not use this design at all, opting for another, more applicable control method. Even so, whether a game uses this technique or not, the execution of a game can be described in terms of states. The Demo State This state typically provides some sort of animation while waiting for the user to start a new game. This may take the form of simple animations within user interface controls (such as animated images on buttons) or something more complex. This state could even be used to play the opening animation sequence introducing players to the game. Some games provide a demonstration of game play as the background animation. This is certainly a popular technique with hot first-person shooters, and even with most action arcade-like games. Displaying a demonstration of actual game play can whet users’ appetites for the game and help to familiarize them with the environment before actually diving in. To appropriately show a demonstration of game play, this state must run some code elements of the state that is used for actual game play. Artificial intelligence routines could be used to simulate the input of a user and generate some interesting animation. Alternatively, input from an actual game session could be saved to an output file. If designed correctly, the functions that interpret user input could take their values from either a user input device or this digitized user input file. Thus, the demo state would simply open this file and begin streaming the data to the input routines, resulting in an exact duplication of the player’s movements and actions. Figure 2-7:  Input coming from devices or files This technique has many benefits. For one, the developer can control exactly what the user will see in the demonstration, which could avoid accidentally showing off hidden rooms or other surprises. Additionally, the developer could digitize walkthroughs that could then be used in separate game hint packages. Also, this method lends itself directly to instant replay functionality, highly desirable in sports and racing games. 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.