Search Tips Advanced Search |
| 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
Standard Input Devices Since games must provide some method for the user to interact with the game world, it would be nice to know if the end user’s machine had a specific input device attached. Fortunately, it would be a rare occurrence indeed to find a machine that did not come with both a mouse and a keyboard as standard attachments. For many games, this combination of input devices works best, and most games may not need any other type of input device. Therefore, it is pretty safe to assume that the user will have at least the mouse and the keyboard available as input devices. Most, if not all, games now support both of these devices, in addition to others. Peripheral Input Devices Peripheral input devices consist of game controllers that are not standard equipment with new computers. Such devices include joysticks, game pads, rudder pedals, and a plethora of other types of input devices of every shape and size. These devices are generally suited for use with “twitch” style games that require good hand-eye coordination, such as flight simulators or first-person shooters. However, several of the more esoteric devices may provide a much more intuitive feel for the user, as opposed to using just a plain keyboard or mouse or joystick. Fortunately, most of these devices are accessed programmatically in a very standard way. This allows the developer to support several devices using the same code base, although some specialty devices may require slightly different coding methods to support their use. As stated above, it is a good practice to support a wide variety of peripheral input devices so that the user will have a choice as to which device feels the most comfortable. ### Real-Time Event-Driven Programming Anyone who has done any amount of serious work in Delphi is now intimately familiar with the event-driven model of application programming. Delphi developers routinely write event handlers, either by creating them manually through the IDE or by hooking them up programmatically in code. It’s an inescapable practice, and it makes application coding and debugging both faster and easier. Game programming, under Delphi or any language, is similar to application programming in many ways, but it is fundamentally different in a few areas. While object-oriented game programming shares the practice of hooking up events, there’s a slight twist to this model that is required for supporting the types of games that are commonly created today. The model most programmers, especially Delphi programmers, are now very familiar and comfortable with is known as event-driven programming. The application is written in such a way that its functionality is triggered by external events. These events can take the form of programmatic signals from other applications or devices, but for the most part, these events are triggered from user input. Until some event is triggered, it simply sits there waiting for an event to fire. For example, consider a word processor. It might have a few events that are triggered from a programmatic source, such as an autosave function fired off of a timer event. However, if you open a word processor and do nothing, it will simply sit there until the user either presses a keyboard button or activates something with the mouse. Event-driven programming is a very effective and useful method by which very robust applications can be effectively written. Game applications, on the other hand, are in continuous motion. Events are constantly being fired based on the current game world situation, and the application continues to process with or without user input. This is the most fundamental difference between game programming and application programming, and is known as the real-time event-driven model. The game application cannot sit there and wait until the user moves the joystick before continuing. The user expects enemy ships and objects to be in constant motion, and would probably be surprised if they were not killed in some spectacular way if they just sat there. Sure, some games are written with the same event-driven model as regular applications, such as a Solitaire game, a chess game, or some other turn-based game. However, arcade-style action games that exhibit constant motion must be written using the real-time event-driven model.
| Note: It is possible to use Delphi’s input events such as OnKeyDown to provide event-driven input to a game. However, while this may work for some games, this is generally not the best approach. We’ll look at more desirable techniques in Chapter 7, Input Techniques.
### Basic Game Architecture There are probably as many different ways to design and architect game application code as there are game applications themselves. Each game will have unique and individual requirements based on the style of game and what it does. However, most games must perform similar tasks, usually in a similar order. With this in mind, let’s examine an arbitrary game architecture that will support the real-time event-driven model as discussed above. Figur 2-1: Basic game architecture Basically, every game can be divided into six different modules: • Initialization • Game Introduction • Game Startup • The Game Loop • Game Ending • Shutdown and Exit Typically, the Initialization and Game Introduction modules are performed at the start of program execution, and usually only run once. The user is then presented with the Game Startup module, which generally contains code for letting the user customize the game in some manner. The Game Loop module is then entered, which contains the primary logic for the game. When the game is over, the Game Ending module presents the user with information on their game performance, and then jumps back into the Game Startup module. The Shutdown and Exit module is finally called when the user wishes to discontinue the game and shut it down. #### Initialization The initialization module is responsible for setting up the beginning game state. It allocates needed memory, initializes global variables, creates lookup tables, and loads resources such as graphics, sound, and music files. Typically, the initialization module will display a splash screen at the beginning of the initialization code so that the user has something to look at. This is an especially good practice if game initialization takes a while; otherwise the user may suspect that the application has frozen or stopped executing.
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.