Overview
This page serves as an introduction into the Multiplayer Framework. It gives a short overview of the various concepts and shows how they play together. We recommend that you first read the introduction and after you have an overview of how things play together, you may read the more detailed explanations of the key concepts where you'll find several tips and usage hints and learn how to use other concepts to increase multiplayer performance.
Layers of the Framework
The framework is based on the following set of abstraction layers:
- UDP (connectionless, unreliable, short latency)
- Object synchronisation (serialization)
- Event publishing over network
- Guaranteed event delivery
- Dynamic object creation and destruction
The first layer is the User Datagram Protocol. Even though it has some major drawbacks compared with TCP, it has one big
advantage which makes it the favourite protocol for network games: Shortest possible latency. A lost packet does not affect
other transmitted packets. This is crucial for low latency, which is the main problem of games that are played over the
Internet.
The second layer is the concept of serialization which we use to synchronize objects over the network.
This layer is not dynamic in its nature itself, this means that you cannot simply add and remove objects using this layer
only.
In other words: The objects you want to synchronize must already exist on 'both' sides. You can hardcode them, or you can
use the dynamic object creation and destruction mechanism.
The third layer, which builds on top of the object synchronisation mechanism, is the event delivery system.
It uses a an event broker object, which is present on all peers by default, to publish events over the network and deliver
them to the subscribers. This system enables a programmer the usage of the famous publish/subscribe pattern over the network.
The forth layer enhances the event system with guaranteed delivery of events. A feature we would have inherited automatically
if
we had used TCP. Events that are either received by all remote peers or not at all are called two phase commit events
(EM_NET_2PC_EVENT_OBJECT).
The fifth layer builds an object creation and destruction mechanism using the secured delivery of events.
Classes
The framework is built around a few core classes which play a very important role:
-
EM_NET_BASE is the heart of the framework.
EM_NET_SERVER and EM_NET_CLIENT are both ancestors from it. Together they build a client-server architecture, that is probably the choice for every multiplayer game. It is possible to extend EM_NET_BASE to a peer to peer system though. - EM_NET_OBJECT implements the basic features needed for object synchronisation. If you want to synchronize your own game objects, they must inherit from EM_NET_OBJECT.
- EM_NET_OBJECT_TYPES manages object types and their creation functions.
- EM_NET_CONNECTION represents a connection to another peer.
- EM_NET_GROUP is a tool to bring order into the bulk of connections and enables you to form logical connection groups.
- EM_NET_EVENT_OBJECT is the base class of events. EM_NET_2PC_EVENT_OBJECT is the base class of secured two phase commit events. There is already a set of predefined events (2PC and non 2PC) in the cluster net_system_events.
- For a complete list of all classes involved have a look at the multiplayer cluster.
Network structure
The standard architecture of the framework is client/server based. The following illustration serves as an abstract overview.

- The server is the game host. One can distinguish between shorttime normal servers, where a players computer serves as the host, and longterm dedicated servers which usually don't have graphics output.
- A client can join open games on a server which is either located in the same LAN or only reachable over the Internet.
- The LAN is usually the preferred medium for fast actions game where low latency is an important fun factor.
- If client and server are both in the same LAN the client can search for servers using a LAN-Broadcast.
- Because of obvious reasons, the Internet has no such thing like a broadcast. Therefore a masterserver is needed which serves as a negotiator between clients and servers. The masterserver keeps a list of all active servers.
- All active servers periodically send heartbeats to the masterserver to mark them as active. If the masterserver detects a server whose heartbeats are missing it deletes its registration.
- If a client is interested in Internet gaming it initiates a server-list-transfer from the masterserver.