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.
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;
-
game design team
We have emerged as the leading online community for game development of all levels. Our expertise encases all facets for writing PC , Mobile and Online of 2D and 3D Gaming programming and applications development, for instance by using the latest 3D engines, scripting languages and animation techniques, our experienced and qualified team deals with all kind of requirements, whether it be a beginner's choice or an expert gaming action. Most importantly, we endeavor to offer compelling solution and eminent support to our growing community of prospective players and customers.
Categories:
Subscribe to:
Post Comments (Atom)
0 Response for the "Developing a Game Engine"
Post a Comment