Contents  Introduction  Architecture  On to WinSock  The Basics  Socket Types  Error Checking  The price you  pay...  Rock, Paper,  Scissor, Shoot!  How to use  the demo  A word on lag  Conclusion  Demo  Printable version

Architecture

A very important thing to think about is what architecture to use when making a multiplayer game. The two (main) architectures are client - client and client - server.

Client - Client

The client-to-client (also called peer-to-peer) architecture is quite simple, yet should only be used in 2 player games. Two clients (player's computers) connect to each other using their opponent's IP address or domain/host name. One problem with this sort of connection is that exchanging IP addresses before you play gets on your nerves quickly. To play against someone, you will have to know his or her IP address. Some people trade IP addresses via email or chat (IRC, ICQ, AIM, etc). Another option is to a server that is especially set up to do nothing but help players swap IP addresses. This means that games are private and two-player. This may or may not be a good thing. The two machines will just exchange game states with each other and both will do full processing (wasting resources).

This is a diagram of the client - client architecture:

Or in terms of more than two machines:

Client - Server

This is the way to go. A fast computer with a fast internet/LAN connection starts a special server application. Everything goes through the server and the server may do processing for all the clients (which cuts down on processing if the game is only one screen big). The server may or may not process data, depending on the way the game was programmed. The cool thing about servers is that there can be (theoretically) unlimited players and the server can do the processing while all the clients just display what the server sent them. Another cool thing about servers is that they aren't usually started on some private computer, but on multiplayer servers, which have a domain name (www.mplayer.com, www.heat.net, etc.) so you don't have to type in the IP address, or exchange it. Also, client - server games will often have a lobby, where you can find other players, wait, or chat.

Here is a diagram of the client - server architecture:

There are three sockets in the diagram. There is the client socket, which obviously is the socket belonging to the client computer. The server uses two sockets. In the beginning there is only one socket, the listen socket. The listen socket listens at a well-known port (a port that the client knows). When the listen socket accepts the connection, it creates a new "connection socket". This may seem strange, but it is perfectly logical because if the client used the listen socket to communicate and exchange data with the server, then no one else could connect during that time.

Here is a diagram of multiple computers playing a client - server game:

The problem with the Internet or even LANs is that it is often too slow. That means that it is important that there is a balance between packet size and speed. Depending on the game, the server may do more or less. Some games also use hybrid architectures, where there is a server, but clients don't have to go through the server. My opinion is to keep it simple, fast, and efficient, and that means use client - server J.

Next : Enough theory, on to WinSock