Looking at the Server
The game server is a
specialized piece of software. It doesn’t need fancy graphics, kicking tunes, or
even dedicated input functions. The server merely needs to process the actions received from
connected
players and, every so often, send updates to the clients.
Once the server begins
executing, it enters into a tight loop, continuously processing
incoming network messages, updating all connected players based on their last
known movement actions, and sending updates.
Few network messages are
received from the server—connection requests, disconnect
notifications, and player actions. Those player actions are solely up to the
game design, and with the demo game for this chapter, those actions include
only players walking, standing still, or attacking with a weapon.
As network messages are
received from clients, the messages are stuffed into a
message queue. Using a message queue
speeds up network operations and leaves the majority of the work up to the main
application (rather than the network code thread). The server maintains a
message
queue (a stack of messages) that holds all incoming messages. As a message comes
in, it is added to the queue. The server continuously pulls out the oldest
message
and sends it off to various functions for processing. This process of message
handling
is illustrated in Figure 19.7.
NOTE
To keep things processing quickly, the server updates players only
every 33ms, whereas client updates are sent approximately every
100ms. Incoming messages (contained in the message queue) are
processed every frame, however.
The server deals with player
connection requests by first checking whether there are
any open slots for players. If so, the player data is requested from the client
and saved
in a local structure. All players in the game are notified that another player
has
joined the fray, and play goes on. A slot is freed up whenever a player
disconnects.
Player actions are quickly
dealt with; all player actions simply change the state of
the player. At this point, the only states used are those for walking, standing
still,
attacking, and being hurt. At every frame, those states are used to update the
player. As player actions are received, the server sends them out to all other
connected
players so that the players can update their game states (between server
updates, of course).
Aside from dealing with network
messages, the server updates the state of the
players. If a player character’s last known state was walking in a certain
direction,
that player’s character continues to walk in that direction. The server, in all
its
authority, will perform collision detection to make sure those moving characters
can’t walk through walls!
NOTE
By allowing only the server to update the game world, you eliminate
cheaters (players who try to alter the game-play to their advantage).
Cheaters typically work by sending bogus data to the server in
the hope that they can move their player in impossible ways.
For every action and state you
add to your game, you add the logic to the server to
process the characters. For example, the attack state requires the server to
refuse
further state changes from a player until the attack state has cleared (after
one second).
At the same time the attack is initiated by a client, the server will calculate
which other clients were hit and the level of damage.
Implementing the server is
easy. After you create a sound base from which to
work, you can easily begin adding more features to the server. Besides adding
new actions that players can perform, you can also add features such as player
account management. However, now it's time to take a quick peek at the client
side of things.