![]() |
Major systems that go into the making of a multiplayer game |
Discovering other systems |
Direct IP entry The oldest and simplest method, this involves typing in the IP address of the user you want to connect to. The remote user can go to a page such as http://www.whatismyip.com/ to get their IP. They can then communicate this IP to you through other communication channels such as email or instant messenger. If the remote user is behind a router, they will have to open the appropriate ports on the firewall to accept incoming connections. If they are behind a firewall, they will have to configure the firewall as well. DNS entry Applicable to client/server games where you control the servers, you can have a DNS entry point to the server. Connecting clients can then connect to the DNS entry rather than typing in a fixed IP address. This is useful if the IP address of the server may change. This service is available for free through http://www.dyndns.com/. RakNet provides a class to update DynDNS as well, found in Source/DynDNS.h and Source/DynDNS.cpp. This is usually used for client/server games where you host your own server. LAN Broadcast If the remote computer is on the same LAN, you can discover this computer by sending a datagram to the IP address 255.255.255.255 provided that the remote computer is listening on the port you send on, and will send a datagram in response. RakNet provides this through the Ping() and AdvertiseSystem() functions. Rooms server More sophisticated games may have a system of rooms for users to find each other. A server will contain a list of rooms, where each room contains a list of players. Players connect to that server, search for and join rooms, and start games through this system. The server is responsible for storing the IP addresses of each player and transmitting that data to other players. RakNet provides this service on the PC through the RoomsPlugin plugin, on Steam through the SteamLobby plugin, and rough equivalents on the XBOX and PS3 with their respective lobby classes. This is usually used for peer-to-peer games, where players have some significant interaction between each other before the game starts. Directory server Similar to the rooms server, a server maintains a list of running games. Typically, when an end-user starts a game, they upload statistics about the game to a directory server that you as the developer host. The directory server holds the IP addresses of the running games, game statistics, and allows game clients to download the list of running games. The clients would then locally connect to servers to join games in progress. This is usually used for client/server games where players host their own game servers. RakNet provides this service through the CloudServer / CloudClient projects. |
Network topology |
Client/Server where you host the servers
Client/Server where users host the servers
Peer to peer
RakNet provides plugins to make peer to peer programming easier: NATPunchthrough, ReadyEvent, ConnectionGraph2, FullyConnectedMesh2, and TeamBalancer |
Replicating game sessions |
Other connected systems
Other game objects
In order to transmit and refer to a game object, one cannot just send a pointer to that object. The object needs to be serialized into a stream format, similar to loading and saving. Some kind of identifier needs to be assigned to the object so the same object on two systems can be referred to. If using client/server topology, all of the above 5 events will also need to be relayed through the server, if the client had initiated the event. If using a peer to peer topology, conflicts may need to be resolved concerning object state in a way that is also fair to the other peers. RakNet provides an architectural solution to these problems through the ReplicaManager3 plugin. Events Interpolation |
Patching |
Per-file difference based patching
RakNet provides the AutopatcherServer and AutopatcherClient plugins as a diff based patching system. Per-file patching RakNet provides the FileListTransfer plugin to transfer lists of files, and the DirectoryDeltaTransfer plugin to transfer lists of changed or missing files.
|
Debugging |
Logging RakNet provides two logging solutions. The first is called SQLite3LoggerPlugin, and is based on SQLite3 on a hosted server. All logs go to the same server, and are automatically correlated. The logs can be viewed in viewer that supports SQLite although RakNet also provides a free and open source custom viewer called EchoChamber. Individual game and connectivity messages can be logged per system using the PacketLogger plugin. Minidump RakNet provides the CrashReporter system to make this easier. It provides additional functionality such as sending emails to the developer in the case of unattended servers.
|
Lobbies and persistent data |
Persistent user data
RakNet provides a system called LobbyServer and LobbyClient to provide this kind of functionality for the PC. Steam, the PS3, and the XBOX already store this on their own backend. For those cases, RakNet uses the same LobbyClient interface so as to provide a unified interface to all systems.
|
Security |
The game should verify all inputs for sanity when possible. This will need to be done even if cheating is not a concern, since latency will also cause unusual inputs. RakNet can automatically protect against attacks #3 and #4 with secure connection support. Solutions already exist for protecting the EXE from modification on the PC. Protecting against latency based cheating just takes smart design decisions, such as not trusting client/peer inputs.
|
See Also |
Index Autopatcher CloudComputing ConnectionGraph2 CrashReporter ReplicaManager3 FullyConnectedMesh2 NATPunchthrough PacketLogger ReadyEvent RPC3 TeamBalancer SQLite3LoggerPlugin |