Game Development Reference
In-Depth Information
players. It starts by popping the front game view, which is assumed to be the main menu
since the main menu is the only thing that can transition to this state. Then it reads the
options from the application layer to find out how many objects it can expect.
The main menu code itself is relatively straightforward, and it can be found in
Dev/Source/TeapotWars/TeapotWarsView.h and TeapotWars.cpp.
The next block takes care of networking. The game logic really has two modes: It can
either be a full game logic, or it can be a proxy that pretends to be a game logic. If
you
'
re playing a multiplayer game, only the server gets a true game logic object; all
the other players get proxies. This proxy is responsible for serializing events coming
in from the local game views and forwarding them to the server. When the server
game logic sends events, these are caught by the proxy game logics and forwarded
to the appropriate places. There
'
s a flag on BaseGameLogic that is set to true if
this game logic is just a proxy.
The first part checks to see if the application layer has a listed game host. Some
methods, such as a menu interface or simple game options file, will set the game
host before the BGS_WaitingForPlayers state is entered. If the game is a remote
client, the logic is set to a proxy logic by calling VSetProxy() , which sets the
m_bProxy member of the BaseGameLogic class to true . After that point, most of
the game logic is short-circuited, and the game events will simply come in from the
remote server.
If the game is an authoritative server expecting remote players, a new socket manager
is created and initialized. This class was covered in Chapter 19,
Network Program-
ming for Multiplayer Games.
If either case fails, the game goes back to the main menu. If this is neither a client
nor a server, it is considered to be a single-player game.
The game-specific logic class will often need to handle processing states and state
changes. The VOnUpdate() and VChangeState() functions can be overridden
for just that purpose. In Teapot Wars, only the VChangeState() function needs
to be overridden to handle actor spawning.
void TeapotWarsLogic::VChangeState(BaseGameState newState)
{
BaseGameLogic::VChangeState(newState);
switch(newState)
{
case BGS_WaitingForPlayers:
{
Search WWH ::




Custom Search