Delphi Graphics and Game Programming Exposed! with DirectX For versions 5.0-7.0:Putting It All Together                       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 CHAPTER 13Putting It All Together This chapter covers the following topics: •  The Delphi Blocks game architecture •  User input implementation •  Sound and music implementation •  Graphics implementation •  Potential enhancements Each individual piece of a game is interesting to study and can be downright fun to program. Sound and music programming is always interesting, as it’s cool to programmatically control a sound’s properties such as volume or panning, and perhaps even more interesting to output music from various sources. Input programming is also a lot of fun, especially when reading from devices other than the standard mouse or keyboard. Force feedback is especially cool, as it’s unusual to control an external peripheral using code instead of the other way around. And, of course, graphics programming is never boring, and is limited to only what your imagination can stir up. However, while each piece is interesting individually, orchestrating them together into a digital masterpiece is incredibly rewarding and entertaining. We’ve covered many useful game programming techniques throughout this book, and now it’s time to put them together and make something useful. In this chapter, we will examine a full-fledged game written using the techniques and examples that we’ve developed throughout the course of the text. We’ll break down several important aspects of the game, and see how all of these parts come together to make a working, playable game application. Delphi Blocks Our case study game is called Delphi Blocks. If you remember the old Breakout game, this one will be very familiar. While we’re not breaking any new technological ground with this application, it does serve as a working example of bringing graphics, sound, and input programming together to make a working, playable, and even fun game. The basic idea is to destroy all of the blocks on the screen using a ball. This ball bounces around the screen, off of blocks and the screen sides. The user can control a small paddle at the bottom of the screen to deflect the ball toward the blocks. If the ball goes off of the bottom of the screen, it is lost and another ball is put into play. The user has three balls; when all of them are lost, the game is over. The game play is simple, but it is easy to learn without ever consulting a manual and can be addictive. General Game Architecture This is a simplistic game with an equally simplistic architecture. The code is encapsulated into one unit, although we could have easily segregated several portions of the code into individual units in order to increase its readability and adaptability. In general, we decided to make the overall game level based to facilitate a more intuitive player advancement system, using a state-driven architecture to ease implementation and simplify game control. Player Advancement As stated above, the player’s goal is to destroy every block on the screen. We’ll use a level based system of advancement, so that when all of the blocks have been destroyed, the level is increased and a new grid of blocks is generated. The score for each block is based on the level, so the higher the level, the more each block is worth. However, the speed of the ball is also based on the level, so at higher levels the ball will be moving at more and more rapid velocities, making the game harder and justifying the score increase for each block. This type of advancement is important, as it challenges the players and forces them to get better in order to play the game for longer periods of time. Game States The game is state driven, using the basic state-driven architecture we covered back in Chapter 2. There are four specific states: Idle, Playing, Intermission, and Game Over. Game execution flows through the states in the following manner: Figure 13-1:  Delphi Blocks state flow Idle This state is basically a demo state. All it does is sit and display a static image with a full grid of blocks and the game title while waiting for the user to start a new game. Unlike the other states, though, in this state we display two buttons, one for starting the game and one for quitting. We’ll discuss how the buttons work when we cover user input. Playing This is the main game state, and includes the logic for moving the sprites and performing the graphics rendering. Additionally, it also checks to see if the current level has been cleared, and if so, it initializes a new level and puts the game in intermission. Intermission This state simply provides the player with a short pause between levels. This is important, as a twitch game like Delphi Blocks can get rather hectic at higher levels, and you really need to provide players with an opportunity to catch their breath every now and then. All this state does is display a full grid of blocks with an indicator of the next level. Game Over The game goes into this state when the player has lost all of the available balls. It serves to indicate to the user that the game has been completed, and a new one must be started. Like the intermission state, it simply displays a full grid of blocks with the words “Game Over” superimposed over them. User Input During the idle state, the user has the choice of selecting two buttons, one for starting a game and one for quitting the application. While actually playing the game, the user has control over a paddle that can move left and right. At higher levels, the user needs to be able to move the paddle rapidly and intuitively. Thus, the most obvious form of control for this type of game would be the mouse. We’ve used a modification of the baseline application with mouse support in order to accomplish this task. Using this baseline, it was very easy to get mouse support up and running with little effort. Buttons The buttons were actually very easy to implement. They are displayed only during the idle state, and it is in this idle state that we check for click events. If a click is detected, we simply check to see if the mouse cursor was located over one of the buttons, and take the appropriate action: {determine if the mouse was clicked in one of the buttons} if MouseClickList.Count>0 then begin {while there are any events in the mouse click list, retrieve them all and empty the list} while MouseClickList.Count > 0 do begin {free the current mouse data} if MouseData <> nil then begin MouseData.Free; MouseData := nil; end; {retrieve and delete the click event} MouseData := TMouseData(MouseClickList[0]); MouseClickList.Delete(0); end; {if the quit button was pushed...} if PtInRect(Rect(416, 350, 544, 414), Point(MouseData.XPos, MouseData.YPos)) then Close; {if the start button was pushed...} if PtInRect(Rect(96, 350, 224, 414), Point(MouseData.XPos, MouseData.YPos)) then StartGame; 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.