using.design.patterns.in.game.engines.PDF

(25 KB) Pobierz
356847539 UNPDF
Using design patterns in game engines
By
Rasmus Christian Kaae
kaae@daimi.au.dk
Student of computer science and programmer at TietoEnator Consulting A/S
August 2001
All rights reserved
USING DESIGN PATTERNS IN GAME ENGINES.....................................................................1
1.0 I NTRODUCTION ............................................................................................................................2
2.0 M ODEL - VIEW - CONTROL FOR THE ENGINE CORE ..........................................................................3
2.1 Model......................................................................................................................................3
2.2 View ........................................................................................................................................3
2.3 Control....................................................................................................................................3
2.4 Example code .........................................................................................................................4
2.4.1 Comments on the code.........................................................................................................6
2.5 A graphical representation.....................................................................................................7
3.0 L AYER PATTERN FOR A 3D- ENGINE .............................................................................................8
3.1 Top layer.................................................................................................................................8
3.2 Second layer ...........................................................................................................................8
3.3 Third and lower layers ...........................................................................................................8
3.4 Example code .........................................................................................................................9
3.5 A graphical representation...................................................................................................11
4.0 C LOSING ....................................................................................................................................12
1.0 Introduction
Design patterns are well known patterns that may help the programmer in the initial phase of a
programming project. They can be used as a guideline on how to fragment and divide the functions
of a program into smaller fragments. In this article I will discuss my point of view on how to
structure a game engine, using available design patterns. My knowledge mainly comes from
personal experiences and from my study at the computer science department of Aarhus University.
There are many different design patterns and they all have different purposes and useability, I have
choosen to center the game engine around a model-view-control structure with an underlying layer-
structure. The layer structure is used in the 3D-engine core.
It is adviseable that you are familiar with polymorphism in C++.
2.0 Model-view-control for the engine core
The core of the engine should be able to handle all tasks that are involved in a game. This means
handling input from the user, handling possible input from other users (network games), handling
the game events and of course handling the audio and visual output. For this I will use a derivate of
the model-view-control design pattern. This pattern divides the engine into three vital parts.
Model-view-control is particular useful for GUI-programs since it provides a certain degree of
modularity which makes it possible to port a given implementation to other graphical-output
devices. For example, a given game engine may be implemented to create a running DirectX
program using the latest DirectX SDK and the wish is now to port this to OpenGL. Since all the
code regarding the dialog between the game engine and DirectX is to be kept in the view classes,
this makes the porting easier - whilst only the view classes should be altered.
More information on the model-view-control architecture can be found at http://ootips.org/mvc-
pattern.html and http://compsci.about.com/cs/mvcpattern/index.htm
2.1 Model
The model part of the structure will contain all game structures. For example the 3D-engine
structures will be kept in this class, also the behaviour patterns, which holds information on what to
do on a given user input, is stored in this part.
The model part has no relation to the view and control part of the structure. This means that the
model part can be used individual in another environment.
2.2 View
The view part contains everything that involves output to the user; in this case audio and visual
communication. For example, this is the place to implement OpenGL and DirectX drivers.
The view part of the structure is related to the model part. This means that the view part is able to
communicate the current state of the model to the user.
2.3 Control
The control part is the most essential part of the structure. When initialized it allocates an instance
of the view and the model classes and awaits user input. The user input is then parsed on to the
model part, where the input is processed, and shortly after the view is asked to project the current
state of the model.
2.4 Example code
The following example code is in pseudo-C++, which means that it will not compile.
/* InputBlock contains the current input from the user */
class InputBlock
{
// todo : add interesting variables and functions that displays the user
input
};
/* The model of the game */
class Model
{
public:
Engine3D *m_engine;
Sound
*m_sound;
Model();
UpdateControl(InputBlock *input)
{
// todo : react on the current input
}
};
/* ViewVisual is an interface class to be implemented for visual drivers */
class ViewVisual
{
public:
ViewVisual()
{
}
// pure virtual function that handles the changes in the current model
virtual void Update(Model *model)=0;
}
/* ViewVisualOpenGL an implementation of the ViewVisual interface */
class ViewVisualOpenGL
{
public:
ViewVisualOpenGL()
{
// todo : init code
}
// display the current state of the model
void Update(Model *model)
{
// todo : paint the model->m_engine
}
};
/* ViewAudio is an interface class to be implemented for audio drivers */
class ViewAudio
{
public:
ViewAudio()
{
// todo: init code
}
// pure virtual function that handles the changes in the current model
virtual void Update(Model *model)=0;
};
/* ViewAudioDirectSound an implementation of ViewAudio which will play sound via
DirectSound */
class ViewAudioDirectSound
{
public:
ViewAudioDirectSound()
{
// todo : init code
}
void Update(Model *model)
{
// todo : play the current sound from model->m_sound
}
};
/* View is the class that connects the visual and the audio drivers */
class View
{
protected:
ViewVisual *m_visual;
ViewAudio *m_audio;
public:
View(Model *model, ViewVisual *visual, ViewAudio *audio)
{
m_model=model;
m_visual=visual;
m_audio=audio;
}
void Update()
{
m_visual->Update(m_model);
m_audio->Update(m_model);
}
};
Zgłoś jeśli naruszono regulamin