Creating a Multiplayer Game
Architecture
When creating your game, if you
were to stop mid-stream and try to add multiplayer
features (features you hadn’t planned on including) chances are you would
have a hard time making everything work out correctly. Let’s face it—you need to
be prepared ahead of time, and if your game is going to be
multiplayer-compatible,
you must make sure that you have a solid foundation on which to work.
You start by understanding what
you’re up against when using networks and what
you can do to ensure that everything works correctly. It will be helpful to look
at
how to use a client/server network architecture.
NOTE
A client application is the program the player interacts with during a networked
gaming session.
A server is the network application that serves as the central processing hub of
the gaming
world. Client applications connect to servers and begin communicating player
actions back and
forth. However, ultimately, the server handles the majority of the
game-processing functionality.
Working Together: The Client
and the Server
The client and the server
communicate back and forth continuously. As players
(the clients) perform actions in the game, those actions are sent as messages to
the
server for verification. The server, in order to maintain synchronization, takes
the
players’ actions, updates the game world, and then sends game updates to the
clients. In this way, the server maintains the entire gaming world, whereas the
clients are merely systems for collecting the players’ actions (and displaying
their
eventual outcomes on the clients’ screens).
The types of messages sent
between the server and clients are numerous, but with
some well thought-out design, those messages are easily manageable. The messages
can be the following:
■ Connection requests. Joining
in a game means connecting to a server. Not
just anyone can join, however; the server might be operating at its limit or
the player might not have a valid account. Once a client is connected, the
real action(s) begin!
■ Navigation. Players can move
around maps, usually by pressing an arrow on
the keyboard or clicking their destination on the map. Clients send in movement
requests and leave it up to the server to return game update messages.
■ Combat. With swords swinging
and spells erupting, it seems too much to
deal with. If you were to strip away the fluff, however, you would discover that
combat is nothing more than an attacker with his form of attack and a
defender with his form of defense. Clients are the only ones to request combat;
it’s the job of the server to take combat requests and work them into the
game updates.
■ Resource management. With a
world full of goods, players want to be able to
buy, sell, find, and use just about any resource that they can get their hands
on. I’m beginning to repeat myself, because resource management comes
from the client, and requests are sent to the server to use for updates.
■ Conversation. What fun is a
multiplayer game without the social interaction?
Characters talk to each other in order to learn vital information or just to
shoot the breeze. Either way, this is a simple matter of displaying a few lines
of text. This conversation works both ways, from clients sending in text to the
server returning text to display.
■ Game updates. As mentioned,
the server needs to let all clients know the
state of the game periodically, and the game update messages are just the
ticket. Game updates usually include the positions of all characters in the
game, plus information about items and other game resources.