Game engines are particularly useful in situations in which you plan on creating more than one game, and you don't want to have to reinvent the wheel each time around. The idea is that you figure out what common functionality all games use, and you write it once and stick it in the game engine. Another significant benefit of a game engine for Windows games is that it allows you to hide the messy details of Windows-specific code that doesn't necessarily have anything to do with a game. For example, virtually all the code in the Skeleton application in Appendix C has nothing to do with a game, but it's required of every Windows application.
A game engine represents an organization of the code for a game so that general application tasks are separated from game-specific tasks. The benefit to the game developer is that you can add features to a game engine that you will be able to reuse in all of your future games. Additionally, using a game engine allows you to simplify the code for your games and focus your attention on the game code that matters most. Once you get accustomed to using a game engine, you'll wonder how games could be created any other way. In reality, most commercial game developers do have their own custom game engines that they've developed over years of learning what common features most games require.
It is the responsibility of a game engine to handle the chores of setting up a game, making sure that it runs properly, and then shutting it down. Although it is true that these tasks are required of any program, certain aspects of initializing, running, and cleaning up after games are truly unique to games. Therefore, it is important for a game engine to address the unique needs of games and help make the process of building games around the engine as simple and straightforward as possible. With a well-designed game engine, you'll find that creating a game requires a lot less code than if you had not relied on a game engine. The idea is to develop certain core game routines once, stick them in the game engine, and then never bother with them again unless absolutely necessary. For example, once you've written code to load an image and draw it on the screen, there is never a reason to rewrite the code again. Loading and drawing images is a basic feature required of all game engines
A game engine represents an organization of the code for a game so that general application tasks are separated from game-specific tasks. The benefit to the game developer is that you can add features to a game engine that you will be able to reuse in all of your future games. Additionally, using a game engine allows you to simplify the code for your games and focus your attention on the game code that matters most. Once you get accustomed to using a game engine, you'll wonder how games could be created any other way. In reality, most commercial game developers do have their own custom game engines that they've developed over years of learning what common features most games require.
It is the responsibility of a game engine to handle the chores of setting up a game, making sure that it runs properly, and then shutting it down. Although it is true that these tasks are required of any program, certain aspects of initializing, running, and cleaning up after games are truly unique to games. Therefore, it is important for a game engine to address the unique needs of games and help make the process of building games around the engine as simple and straightforward as possible. With a well-designed game engine, you'll find that creating a game requires a lot less code than if you had not relied on a game engine. The idea is to develop certain core game routines once, stick them in the game engine, and then never bother with them again unless absolutely necessary. For example, once you've written code to load an image and draw it on the screen, there is never a reason to rewrite the code again. Loading and drawing images is a basic feature required of all game engines
Breaking a Game Down into Events
Every Windows program can be broken down into events, which are things that take place while a program is running, such as mouse clicks and window resizes. Just as Windows programs have events that they must handle, games have their own unique set of events that must be taken into consideration during development. The initialization process of a game can be considered an event, and its responsibilities are to load graphics and sounds for the game, clear the playing field, zero out the score, and so on. Similarly, user input carries over to games as well, meaning that mouse clicks and key presses are events that games certainly must concern themselves with. Additionally, keep in mind that, in Windows, it's possible for some games to be minimized or otherwise placed into the background, which means that you'll probably want to pause the game. This activation and reactivation process can be represented by a couple of events.
Although many other events could certainly factor into a game engine, the following are some of the core events applicable to just about any game:
Although many other events could certainly factor into a game engine, the following are some of the core events applicable to just about any game:
- Initialization
- Start
- End
- Activation
- Deactivation
- Paint
- Cycle
The initialization event occurs when a game is first launched and gives a game a chance to perform critical initial setup tasks, including creating the game engine itself. The start and end events correspond to the start and end of a game, and they provide good places to perform initialization and cleanup tasks associated with a specific game session. The activation and deactivation events come into play when a game is minimized or sent to the background and then later restored. The paint event is sent when a game needs to draw itself and is similar to the Windows WM_PAINT message. Finally, the cycle event enables a game to perform a single game cycle, which is very important, as you learn next.
Establishing the Timing for Games
If you've never taken a look at a game from a programming perspective, it might surprise you to learn how all the movement and the animation in a game are orchestrated. You will learn all the details of animated graphics in Chapter 9, "Making Things Move with Sprite Animation," but for now, I want to touch on the importance of game timing as it applies to animation and other facets of games. Every game, except extremely simple card games, relies on some sort of timing mechanism to enable the game to break down its execution into frames or cycles. A cycle of a game is one slice of time, which usually corresponds to a snapshot of the game's graphics and data. If you think of a game as a movie playing on a VCR or DVD player, pressing Pause allows you to view a single cycle. Stepping forward one frame in the video is like moving to the next cycle of the game. In any given cycle, a game takes care of updating its graphics, as well as performing any other calculations and processing related to how characters and objects are moving and interacting with each other.
A good way to get a grasp on the importance of game cycles is to take a practical game as an example. The classic Space Invaders game was mentioned in the opener of this chapter, so let's use it as an example to demonstrate game cycles. When Space Invaders first starts, the ship is created, along with several rows of alien invaders. Each of these objects has an initial position and velocity. If Space Invaders had no timing or game cycles, the game would be forever frozen in its initial state, as if you had pressed a permanent Pause button when the game started. We know that this isn't the case, however, because the game starts out with the aliens slowly moving across the screen. If you were to view Space Invaders a cycle at a time, you would notice that, in each cycle, the aliens are only moved slightly. This is because there happen to be quite a few cycles taking place in a given period of time, which gives the effect of smooth motion. The role of a game cycle is to update the status of all the objects in the game and then reflect these changes by updating the graphics shown on the screen. As a comparison, televisions display 30 different images (cycles) per second, whereas motion pictures rely on 24 images per second. You learn much more about the significance of different rates of animation in Chapter 9. For now, it's important to understand that just about every game is highly dependent on periodic cycles.
A good way to get a grasp on the importance of game cycles is to take a practical game as an example. The classic Space Invaders game was mentioned in the opener of this chapter, so let's use it as an example to demonstrate game cycles. When Space Invaders first starts, the ship is created, along with several rows of alien invaders. Each of these objects has an initial position and velocity. If Space Invaders had no timing or game cycles, the game would be forever frozen in its initial state, as if you had pressed a permanent Pause button when the game started. We know that this isn't the case, however, because the game starts out with the aliens slowly moving across the screen. If you were to view Space Invaders a cycle at a time, you would notice that, in each cycle, the aliens are only moved slightly. This is because there happen to be quite a few cycles taking place in a given period of time, which gives the effect of smooth motion. The role of a game cycle is to update the status of all the objects in the game and then reflect these changes by updating the graphics shown on the screen. As a comparison, televisions display 30 different images (cycles) per second, whereas motion pictures rely on 24 images per second. You learn much more about the significance of different rates of animation in Chapter 9. For now, it's important to understand that just about every game is highly dependent on periodic cycles.
Note - A single screen of graphics in a game is known as a frame. Because a new screen of graphics is drawn during each game cycle, the speed of games is often measured in frames per second, or fps. Because the discussion in this chapter is centered on cycles, as opposed to frames, I refer to game speeds in cycles per second. However, cycles per second, frames per second, and even images per second are really the same measurement.
The more cycles a game can run through in a given amount of time, the smoother the game appears to run. As an extreme example, compare the "smoothness" of a slideshow to a motion picture. The slideshow abruptly moves from one still image to another with no transition or sense of smooth movement, whereas a motion picture shows fluid motion as if you were experiencing it in real-time. Similarly, a game with only a few cycles per second will appear choppy, whereas a higher number of cycles per second will result in a much smoother game. A larger number of cycles per second also gives you more flexibility in speeding up or slowing down a game to arrive at a perfect speed.
Knowing that more cycles result in smoother graphics and better flexibility, you might think that you could crank up the cycles per second really high. As with most things in life, there is a trade-off when it comes to game cycles and game efficiency. The problem lies in the fact that the amount of processing taking place in a game in each cycle is often considerable, which means that to perform numerous cycles per second, your computer's processor and graphics card have to be able to keep up. Even with the blazingly fast computers prevalent these days, there are practical limitations as to how fast most computers can perform game processing. In reality, most games will fall in the range of 15 to 20 cycles per second, with a maximum speed surpassing that of a motion picture at 30 cycles per second. Except for some rare situations, the minimum speed you should shoot for is 12 cycles per second.
Knowing that more cycles result in smoother graphics and better flexibility, you might think that you could crank up the cycles per second really high. As with most things in life, there is a trade-off when it comes to game cycles and game efficiency. The problem lies in the fact that the amount of processing taking place in a game in each cycle is often considerable, which means that to perform numerous cycles per second, your computer's processor and graphics card have to be able to keep up. Even with the blazingly fast computers prevalent these days, there are practical limitations as to how fast most computers can perform game processing. In reality, most games will fall in the range of 15 to 20 cycles per second, with a maximum speed surpassing that of a motion picture at 30 cycles per second. Except for some rare situations, the minimum speed you should shoot for is 12 cycles per second.
Note - Commercial 3D games are always pushing the envelope of what is possible given the current computer hardware available. The number of cycles per second for a modern 3D game is the most common measurement used to determine if the game is being too ambitious in terms of how much it is taxing the processing capabilities of the computer. In an ideal world, you would design games with beautifully detailed graphics and not worry about whether the game brings a user's system to a screeching halt. In reality, game designers are always walking a tight rope to make games look incredibly good yet still maintain a decent frame rate (ideally, 30fps or more).
Now that you understand how the timing of a game is expressed in terms of cycles, you can probably see why a cycle is a type of game event. It works like this: When a game first starts, you initialize the game engine with the game speed in cycles per second. Let's say that you go with 12 cycles per second. The game engine is then responsible for setting up and managing a timer that fires a cycle event 12 times each second. The game code receives these cycle messages and handles them by updating the objects in the game and redrawing the game screen. You can think of a cycle event as a snooze alarm that keeps going off over and over; except in this case, it's going off 12 times a second. Your game clearly isn't getting much sleep!
Note - Speaking of sleep, another role of a game engine is to put a game to sleep whenever it is no longer the active window. In practical terms, putting a game to sleep simply means that the game engine stops sending cycle messages. Because no cycle messages are being sent, the game is effectively paused.
The Game Event Functions
The first place to start in creating a game engine is to create handler functions that correspond to the game events mentioned earlier in the chapter. When an event occurs in a game, the corresponding event handler function will be called, which gives your game a chance to respond accordingly. The following are these functions, which should make some sense to you because they correspond directly to the game events:
BOOL GameInitialize(HINSTANCE hInstance);
void GameStart(HWND hWindow);
void GameEnd();
void GameActivate(HWND hWindow);
void GameDeactivate(HWND hWindow);
void GamePaint(HDC hDC);
void GameCycle();
The first function, GameInitialize(), is probably the only one that needs special explanation simply because of the argument that gets sent into it. I'm referring to the hInstance argument, which is of type HINSTANCE. This is a Win32 data type that refers to an application instance. An application instance is basically a program that has been loaded into memory and is running in Windows. If you've ever used Alt+Tab to switch between running applications in Windows, you're familiar with different application instances. The HINSTANCE data type is a handle to an application instance, and it is very important because it enables a program to access its resources since they are stored with the application in memory.
BOOL GameInitialize(HINSTANCE hInstance);
void GameStart(HWND hWindow);
void GameEnd();
void GameActivate(HWND hWindow);
void GameDeactivate(HWND hWindow);
void GamePaint(HDC hDC);
void GameCycle();
The first function, GameInitialize(), is probably the only one that needs special explanation simply because of the argument that gets sent into it. I'm referring to the hInstance argument, which is of type HINSTANCE. This is a Win32 data type that refers to an application instance. An application instance is basically a program that has been loaded into memory and is running in Windows. If you've ever used Alt+Tab to switch between running applications in Windows, you're familiar with different application instances. The HINSTANCE data type is a handle to an application instance, and it is very important because it enables a program to access its resources since they are stored with the application in memory.
Developing a Game Engine
The first place to start in creating a game engine is to create handler functions that correspond to the game events mentioned earlier in the chapter. When an event occurs in a game, the corresponding event handler function will be called, which gives your game a chance to respond accordingly. The following are these functions, which should make some sense to you because they correspond directly to the game events:
BOOL GameInitialize(HINSTANCE hInstance);
void GameStart(HWND hWindow);
void GameEnd();
void GameActivate(HWND hWindow);
void GameDeactivate(HWND hWindow);
void GamePaint(HDC hDC);
void GameCycle();
The first function, GameInitialize(), is probably the only one that needs special explanation simply because of the argument that gets sent into it. I'm referring to the hInstance argument, which is of type HINSTANCE. This is a Win32 data type that refers to an application instance. An application instance is basically a program that has been loaded into memory and is running in Windows. If you've ever used Alt+Tab to switch between running applications in Windows, you're familiar with different application instances. The HINSTANCE data type is a handle to an application instance, and it is very important because it enables a program to access its resources since they are stored with the application in memory.
BOOL GameInitialize(HINSTANCE hInstance);
void GameStart(HWND hWindow);
void GameEnd();
void GameActivate(HWND hWindow);
void GameDeactivate(HWND hWindow);
void GamePaint(HDC hDC);
void GameCycle();
The first function, GameInitialize(), is probably the only one that needs special explanation simply because of the argument that gets sent into it. I'm referring to the hInstance argument, which is of type HINSTANCE. This is a Win32 data type that refers to an application instance. An application instance is basically a program that has been loaded into memory and is running in Windows. If you've ever used Alt+Tab to switch between running applications in Windows, you're familiar with different application instances. The HINSTANCE data type is a handle to an application instance, and it is very important because it enables a program to access its resources since they are stored with the application in memory.
The GameEngine Class
The GameEngine Class The game event handler functions are actually separated from the game engine itself, even though there is a close tie between them. This is necessary because it is organizationally better to place the game engine in its own C++ class. This class is called GameEngine and is shown in Listing 2.1.
Note - If you were trying to adhere strictly to object-oriented design principles, you would place the game event handler functions in the GameEngine class as virtual methods to be overridden. However, although that would represent good OOP design, it would also make it a little messier to assemble a game because you would have to derive your own custom game engine class from GameEngine in every game. By using functions for the event handlers, you simplify the coding of games at the expense of breaking an OOP design rule. Such are the trade-offs of game programming.
Listing 2.1 The GameEngine Class Definition Reveals How the Game Engine Is Designed
class GameEngine
{
protected:
// Member Variables
static GameEngine* m_pGameEngine;
HINSTANCE m_hInstance;
HWND m_hWindow;
TCHAR m_szWindowClass[32];
TCHAR m_szTitle[32];
WORD m_wIcon, m_wSmallIcon;
int m_iWidth, m_iHeight;
int m_iFrameDelay;
BOOL m_bSleep;
public:
// Constructor(s)/Destructor
GameEngine(HINSTANCE hInstance, LPTSTR szWindowClass, LPTSTR szTitle,
WORD wIcon, WORD wSmallIcon, int iWidth = 640, int iHeight = 480);
virtual ~GameEngine();
// General Methods
static GameEngine* GetEngine() { return m_pGameEngine; };
BOOL Initialize(int iCmdShow);
LRESULT HandleEvent(HWND hWindow, UINT msg, WPARAM wParam,
LPARAM lParam);
// Accessor Methods
HINSTANCE GetInstance() { return m_hInstance; };
HWND GetWindow() { return m_hWindow; };
void SetWindow(HWND hWindow) { m_hWindow = hWindow; };
LPTSTR GetTitle() { return m_szTitle; };
WORD GetIcon() { return m_wIcon; };
WORD GetSmallIcon() { return m_wSmallIcon; };
int GetWidth() { return m_iWidth; };
int GetHeight() { return m_iHeight; };
int GetFrameDelay() { return m_iFrameDelay; };
void SetFrameRate(int iFrameRate) { m_iFrameDelay = 1000 /
iFrameRate; };
BOOL GetSleep() { return m_bSleep; };
void SetSleep(BOOL bSleep) { m_bSleep = bSleep; };
};
The GameEngine class definition reveals a subtle variable naming convention that you might or might not be familiar with. This naming convention involves naming member variables of a class with an initial m_ to indicate that they are class members. Additionally, global variables are named with a leading g_ to indicate that they are globals. This convention is useful because it helps you to immediately distinguish between local variables, member variables, and global variables in a program. The member variables for the GameEngine class all take advantage of this naming convention.
The GameEngine class defines a static pointer to itself, m_pGameEngine, which is used for outside access by a game program. The application instance and main window handles of the game program are stored away in the game engine using the m_hInstance and m_hWindow member variables. The name of the window class and the title of the main game window are stored in the m_szWindowClass and m_szTitle member variables. The numeric IDs of the two program icons for the game are stored in the m_wIcon and m_wSmallIcon members. The width and height of the game screen are stored in the m_iWidth and m_iHeight members. It's important to note that this width and height correspond to the size of the game screen, or play area, not the size of the overall program window, which is larger to accommodate borders, a title bar, menus, and so on. The m_iFrameDelay member variable indicates the amount of time between game cycles in milliseconds. Finally, m_bSleep is a Boolean member variable that indicates whether the game is sleeping (paused).
The GameEngine constructor and destructor are defined after the member variables, as you might expect. The constructor is very important because it accepts arguments that dramatically impact the game being created. More specifically, the GameEngine() constructor accepts an instance handle, window classname, title, icon ID, small icon ID, width, and height. Notice that the iWidth and iHeight arguments default to values of 640 and 480, respectively, which is a reasonable minimum size for game screens. The ~GameEngine() destructor doesn't do anything, but it's worth defining in case you need to add some cleanup code to it later. I mentioned that the GameEngine class maintains a static pointer to itself. This pointer is accessed from outside the engine using the static GetEngine() method. The Initialize() method is another important general method in the GameEngine class, and its job is to initialize the game program once the engine is created. The HandleEvent() method is responsible for handling standard Windows events within the game engine and is a good example of how the game engine hides the details of generic Windows code from game code. The remaining methods in the GameEngine class are accessor methods used to access member variables; these methods are all used to get and set member variables. The one accessor method to pay special attention to is SetFrameRate(), which sets the frame rate or number of cycles per second of the game engine. Because the actual member variable that controls the number of game cycles per second is m_iFrameDelay, which is measured in milliseconds, it's necessary to perform a quick calculation to convert the frame rate in SetFrameRate() to milliseconds.
The source code for the GameEngine class provides implementations for the methods described in the header that you just saw, as well as the standard WinMain() and WndProc() functions that tie into the game engine. The GameEngine source code also initializes the static game engine pointer, like this: GameEngine *GameEngine::m_pGameEngine = NULL;
Listing 2.2 The WinMain() Function in the Game Engine Makes Calls to Game Engine Functions and Methods and Provides a Neat Way of Separating Standard Windows Program Code from Game Code
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
PSTR szCmdLine, int iCmdShow) {
MSG msg;
static int iTickTrigger = 0;
int iTickCount;
if (GameInitialize(hInstance))
{
// Initialize the game engine
if (!GameEngine::GetEngine()->Initialize(iCmdShow))
return FALSE;
// Enter the main message loop
while (TRUE)
{
if (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
{
// Process the message
if (msg.message == WM_QUIT)
break;
TranslateMessage(&msg);
DispatchMessage(&msg);
}
else
{
// Make sure the game engine isn't sleeping
if (!GameEngine::GetEngine()->GetSleep())
{
// Check the tick count to see if a game cycle has elapsed
iTickCount = GetTickCount();
if (iTickCount > iTickTrigger)
{ iTickTrigger = iTickCount +
GameEngine::GetEngine()->GetFrameDelay();
GameCycle();
}
}
}
}
return (int)msg.wParam;
}
// End the game
GameEnd();
return TRUE;
}
Although this WinMain() function is similar to those found in every Windows application, there is an important difference. The difference has to do with the fact that this WinMain() function establishes a game loop that takes care of generating game cycle events at a specified interval. The smallest unit of time measurement in a Windows program is called a tick, which is equivalent to one millisecond and is useful in performing accurate timing tasks. In this case, WinMain() counts ticks in order to determine when it should notify the game that a new cycle is in order. The iTickTrigger and iTickCount variables are used to establish the game cycle timing in WinMain().
The first function called in WinMain() is GameInitialize(), which gives the game a chance to be initialized. Remember that GameInitialize() is a game event function provided as part of the game-specific code for the game; therefore, it isn't a direct part of the game engine. A method that is part of the game engine is Initialize(), which is called to get the game engine itself initialized. From there, WinMain() enters the main message loop for the game program. The else part of the main message loop is where things get interesting. This part of the loop first checks to make sure that the game isn't sleeping and then uses the frame delay for the game engine to count ticks and determine when to call the GameCycle() function to trigger a game cycle event. WinMain() finishes up by calling GameEnd() to give the game program a chance to wrap up the game and clean up after itself. The other standard Windows function included in the game engine is WndProc(), which is very simple because the HandleEvent() method of the GameEngine class is responsible for processing Windows messages:
LRESULT CALLBACK WndProc(HWND hWindow, UINT msg, WPARAM wParam, LPARAM lParam)
{
// Route all Windows messages to the game engine
return GameEngine::GetEngine()->HandleEvent(hWindow, msg, wParam, lParam);
}
All WndProc() really does is pass along all messages to HandleEvent(), which might at first seem like a waste of time. However, the idea is to allow a method of the GameEngine class to handle the messages so that they can be processed in a manner that is consistent with the game engine.
Speaking of the GameEngine class, now that you have a feel for the support functions in the game engine, we can move right along and examine specific code in the GameEngine class. Listing 2.3 contains the source code for the GameEngine() constructor and destructor.
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
PSTR szCmdLine, int iCmdShow) {
MSG msg;
static int iTickTrigger = 0;
int iTickCount;
if (GameInitialize(hInstance))
{
// Initialize the game engine
if (!GameEngine::GetEngine()->Initialize(iCmdShow))
return FALSE;
// Enter the main message loop
while (TRUE)
{
if (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
{
// Process the message
if (msg.message == WM_QUIT)
break;
TranslateMessage(&msg);
DispatchMessage(&msg);
}
else
{
// Make sure the game engine isn't sleeping
if (!GameEngine::GetEngine()->GetSleep())
{
// Check the tick count to see if a game cycle has elapsed
iTickCount = GetTickCount();
if (iTickCount > iTickTrigger)
{ iTickTrigger = iTickCount +
GameEngine::GetEngine()->GetFrameDelay();
GameCycle();
}
}
}
}
return (int)msg.wParam;
}
// End the game
GameEnd();
return TRUE;
}
Although this WinMain() function is similar to those found in every Windows application, there is an important difference. The difference has to do with the fact that this WinMain() function establishes a game loop that takes care of generating game cycle events at a specified interval. The smallest unit of time measurement in a Windows program is called a tick, which is equivalent to one millisecond and is useful in performing accurate timing tasks. In this case, WinMain() counts ticks in order to determine when it should notify the game that a new cycle is in order. The iTickTrigger and iTickCount variables are used to establish the game cycle timing in WinMain().
The first function called in WinMain() is GameInitialize(), which gives the game a chance to be initialized. Remember that GameInitialize() is a game event function provided as part of the game-specific code for the game; therefore, it isn't a direct part of the game engine. A method that is part of the game engine is Initialize(), which is called to get the game engine itself initialized. From there, WinMain() enters the main message loop for the game program. The else part of the main message loop is where things get interesting. This part of the loop first checks to make sure that the game isn't sleeping and then uses the frame delay for the game engine to count ticks and determine when to call the GameCycle() function to trigger a game cycle event. WinMain() finishes up by calling GameEnd() to give the game program a chance to wrap up the game and clean up after itself. The other standard Windows function included in the game engine is WndProc(), which is very simple because the HandleEvent() method of the GameEngine class is responsible for processing Windows messages:
LRESULT CALLBACK WndProc(HWND hWindow, UINT msg, WPARAM wParam, LPARAM lParam)
{
// Route all Windows messages to the game engine
return GameEngine::GetEngine()->HandleEvent(hWindow, msg, wParam, lParam);
}
All WndProc() really does is pass along all messages to HandleEvent(), which might at first seem like a waste of time. However, the idea is to allow a method of the GameEngine class to handle the messages so that they can be processed in a manner that is consistent with the game engine.
Speaking of the GameEngine class, now that you have a feel for the support functions in the game engine, we can move right along and examine specific code in the GameEngine class. Listing 2.3 contains the source code for the GameEngine() constructor and destructor.
Listing 2.3 The GameEngine::GameEngine() Constructor Takes Care of Initializing Game Engine Member Variables, Whereas the Destructor is Left Empty for Possible Future Use
GameEngine::GameEngine(HINSTANCE hInstance, LPTSTR szWindowClass, LPTSTR szTitle, WORD wIcon, WORD wSmallIcon, int iWidth, int iHeight)
{
// Set the member variables for the game engine
m_pGameEngine = this;
m_hInstance = hInstance;
m_hWindow = NULL;
if (lstrlen(szWindowClass) > 0)
lstrcpy(m_szWindowClass, szWindowClass);
if (lstrlen(szTitle) > 0)
lstrcpy(m_szTitle, szTitle);
m_wIcon = wIcon;
m_wSmallIcon = wSmallIcon;
m_iWidth = iWidth;
m_iHeight = iHeight;
m_iFrameDelay = 50; // 20 FPS default
m_bSleep = TRUE;
}
GameEngine::~GameEngine()
{
}
The GameEngine() constructor is relatively straightforward in that it sets all the member variables for the game engine. The only member variable whose setting might seem a little strange at first is m_iFrameDelay, which is set to a default frame delay of 50 milliseconds. You can determine the number of frames (cycles) per second for the game by dividing 1,000 by the frame delay, which in this case results in 20 frames per second. This is a reasonable default for most games, although specific testing might reveal that it needs to be tweaked up or down. Keep in mind that you should always shoot for the highest frame rate (lowest frame delay) possible that allows your game to run smoothly; you don't want to see a game slowing down because it can't keep up with a high frame rate.
The Initialize() method in the GameEngine class is used to initialize the game engine. More specifically, the Initialize() method now performs a great deal of the messy Windows setup tasks, such as creating a window class for the main game window and then creating a window from the class. Listing 2.4 shows the code for the Initialize() method.
{
// Set the member variables for the game engine
m_pGameEngine = this;
m_hInstance = hInstance;
m_hWindow = NULL;
if (lstrlen(szWindowClass) > 0)
lstrcpy(m_szWindowClass, szWindowClass);
if (lstrlen(szTitle) > 0)
lstrcpy(m_szTitle, szTitle);
m_wIcon = wIcon;
m_wSmallIcon = wSmallIcon;
m_iWidth = iWidth;
m_iHeight = iHeight;
m_iFrameDelay = 50; // 20 FPS default
m_bSleep = TRUE;
}
GameEngine::~GameEngine()
{
}
The GameEngine() constructor is relatively straightforward in that it sets all the member variables for the game engine. The only member variable whose setting might seem a little strange at first is m_iFrameDelay, which is set to a default frame delay of 50 milliseconds. You can determine the number of frames (cycles) per second for the game by dividing 1,000 by the frame delay, which in this case results in 20 frames per second. This is a reasonable default for most games, although specific testing might reveal that it needs to be tweaked up or down. Keep in mind that you should always shoot for the highest frame rate (lowest frame delay) possible that allows your game to run smoothly; you don't want to see a game slowing down because it can't keep up with a high frame rate.
The Initialize() method in the GameEngine class is used to initialize the game engine. More specifically, the Initialize() method now performs a great deal of the messy Windows setup tasks, such as creating a window class for the main game window and then creating a window from the class. Listing 2.4 shows the code for the Initialize() method.
Listing 2.4 The GameEngine::Initialize() Method Handles Some of the Dirty Work that Usually Takes Place in WinMain()
{
WNDCLASSEX wndclass;
// Create the window class for the main window
wndclass.cbSize = sizeof(wndclass);
wndclass.style = CS_HREDRAW | CS_VREDRAW;
wndclass.lpfnWndProc = WndProc;
wndclass.cbClsExtra = 0;
wndclass.cbWndExtra = 0;
wndclass.hInstance = m_hInstance;
wndclass.hIcon = LoadIcon(m_hInstance,
MAKEINTRESOURCE(GetIcon()));
wndclass.hIconSm = LoadIcon(m_hInstance,
MAKEINTRESOURCE(GetSmallIcon()));
wndclass.hCursor = LoadCursor(NULL, IDC_ARROW);
wndclass.hbrBackground = (HBRUSH)(COLOR_WINDOW + 1);
wndclass.lpszMenuName = NULL;
wndclass.lpszClassName = m_szWindowClass;
// Register the window class
if (!RegisterClassEx(&wndclass))
return FALSE;
// Calculate the window size and position based upon the game size
int iWindowWidth = m_iWidth + GetSystemMetrics(SM_CXFIXEDFRAME) * 2,
iWindowHeight = m_iHeight + GetSystemMetrics(SM_CYFIXEDFRAME) * 2 +
GetSystemMetrics(SM_CYCAPTION);
if (wndclass.lpszMenuName != NULL)
iWindowHeight += GetSystemMetrics(SM_CYMENU);
int iXWindowPos = (GetSystemMetrics(SM_CXSCREEN) - iWindowWidth) / 2,
iYWindowPos = (GetSystemMetrics(SM_CYSCREEN) - iWindowHeight) / 2;
// Create the window
m_hWindow = CreateWindow(m_szWindowClass, m_szTitle, WS_POPUPWINDOW |
WS_CAPTION | WS_MINIMIZEBOX, iXWindowPos, iYWindowPos, iWindowWidth,
iWindowHeight, NULL, NULL, m_hInstance, NULL);
if (!m_hWindow)
return FALSE;
// Show and update the window
ShowWindow(m_hWindow, iCmdShow);
UpdateWindow(m_hWindow);
return TRUE;
}
This code is similar to the Skeleton program example found in Appendix C, and it should be familiar to you if you've done any Windows programming using the Win32 API. An important thing to note in this code is how it determines the game application window size, which is calculated based on the size of the game client area. The GetSystemMetrics() Win32 function is called to get various standard window sizes, such as the width and height of the window frame, as well as the menu height. The position of the game application window is then calculated so that the game is centered on the screen.
Comments (0)
Post a Comment