Game Development Reference
In-Depth Information
Figure 10.1
Screens need a screen manager.
Other games use multiple screens to set up the characters or missions. When every-
thing is set up for the player, the game transitions to the game screen where most, if
not all, of the game is played. Almost every console game uses this model. Let
'
s look
at a simple interface design for a screen:
class IScreenElement
{
public:
virtual HRESULT VOnRestore() = 0;
virtual HRESULT VOnRender(double fTime, float fElapsedTime) = 0;
virtual void VOnUpdate(int deltaMilliseconds) = 0;
virtual int VGetZOrder() const = 0;
virtual void VSetZOrder(int const zOrder) = 0;
virtual bool VIsVisible() const = 0;
virtual void VSetVisible(bool visible) = 0;
virtual LRESULT CALLBACK VOnMsgProc( AppMsg msg )=0;
virtual
IScreenElement() { };
virtual bool const operator <(IScreenElement const &other)
{ return VGetZOrder() < other.VGetZOrder(); }
˜
};
This interface shows that a screen knows how to restore itself when it needs to be
rebuilt, render itself when it
s time to draw, how it should be ordered in the master
draw list, and whether it is visible. The
VOnMsgProc()
method accepts Windows
messages from the application layer, but translates them into a structure to simplify
the call signature of anything that will accept these messages:
'
