Chapter 10

One example is the MultiplayerGameState class. In its update() function, we interpret the game action and build a packet based on it, which is then sent over the network. We fill the packet with the Client::GameEvent packet type, the game action type (which in our case is always GameActions::EnemyExplode) and the position coordinates.

GameActions::Action gameAction;

while (mWorld.pollGameAction(gameAction))

{

sf::Packet packet;

packet << static_cast<sf::Int32>(Client::GameEvent); packet << static_cast<sf::Int32>(gameAction.type); packet << gameAction.position.x;

packet << gameAction.position.y;

mSocket.send(packet);

}

On the server side, in GameServer::handleIncomingPacket(), this packet is interpreted. When the game action denotes an exploded enemy, a pick-up will be spawned with a certain probability. This in turn leads to a packet of type Server::SpawnPickup, which is distributed to all clients.

The new pause state

For this chapter, the pause state was slightly modified. The same PauseState class was now modified to accept an option in its constructor to either allow or deny underlying states from being updated. The "default" behavior didn't change, but if we pass this parameter as true, the underlying states keep updating. This was a necessity as there was no concept of pausing in a networked game, because the

world is persistent. However, the user may still want to access settings or go back to the main menu!

Settings

You may now configure two sets of keys in the Settings screen! This was done by not using an application wide Player instance anymore, rather by using a proper KeyBinding structure, holding the keys that are later passed to Player instances at will.

[ 263 ]

www.it-ebooks.info