Basic Concepts - PeerGaming/peergaming GitHub Wiki

To help others by creating their own multiplayer game - PeerGaming had to achieve these goals:

standalone

In contrast to other multiplayer modules for the browser - the framework tries
to be agnostic and without further dependencies. Developers & gamers shouldn't
require an additional server setup or a complex installation to use the script.

configurable

Many aspects are customizable and as you are the one who uses the framework -
you probably know best which settings are appropriated for your needs.
The developer should allways be in charge and therefore able to choose his own path.

simple

Network or security issues shouldn't concern a developer who just likes to create
a game. Aside from the default settings, the whole API is designed for minimal
input and graceful handling of parameters. It should work out of the Box!

Decisions

The framework is also based on following ideas:

• PeerChain
• Topology
• Routing
• Synchronization

PeerChain

During the login of a user - the current time will stored and assigned to the account. This information will be used later on, to define an order and rank the peers by their entry time.

Topology

Using a Full-Mesh (1:n) instead of a star or grid composition - allows to simplify the comunication and reduce the latency. As each player got a direct connection to the others, every message just needs one "jump".

Routing

In general a peer connects to a default server and looks for partners in the same room. Besides providing your own server setup, you can also use a ".noServer" option - which will be triggered to exchange credentials via a transport channel of your choice. You could e.g. use a messenger or share them locally with people around.

Synchronization

Adapting an existing singleplayer game and adding a new multiplayer mode will often require somekind of refactoring. To ease this migration, the framework tries to reduce the new overhead by using familiar patterns. Through the creation of the player instance during the login, getter & setter are defined on a shared object. As a new connection with another peers gets established, the remote partner receives a proxy which contains the current data and automaticly updates on a change on your side. The developer don't need to care about messaging or defining a RPC routine by himself.