Multiplayer: Peer to Peer (P2P)

(return)  (springs & pucks)
data flow
Figure 1. connections via a local Node.js server

data flow
Figure 2. Direct P2P connections established with a remote
Node.js server

A P2P layer has been added to the multiplayer functionality for the demos. The connectivity described on the original multiplayer page is still in place and facilitates P2P and also acts as a backup if P2P connections can't be established.

P2P offers only a minor performance advantage when compared to the local Node.js server configuration represented in Figure 1. The time consumed in sending mouse and keyboard data through a middle-man is small when all computers are on the same local network.

A key drawback with this configuration is the required installation of a Node.js server onto the host computer. It's a simple install but any install can be a barrier to the recruiting process for a multiplayer game.

Prior to now, the demo page, in multiplayer mode, ran with the default Node.js server being a remote one, at Heroku (like Figure 1, but with the yellow circle far outside the local network). No install needed. But the time-of-flight lag, back and forth to Heroku, is quite noticeable especially in mouse movements projected to the host. This lag (latency) is a key drawback of the non-local node server. Even more so, this lag is a hindrance to any kind of synchronized play between users on different networks.

An alternative to synchronizing two physics engines is to stream (P2P) the rendered result from the host's canvas out to a video element on the client page. Client mouse movements (over the video element) and keyboard events are sent to the host, interacting with the host physics engine. Using only one engine, two users can play in different physical rooms, networks, states, countries...

As the educational (classroom) applications of this site are considered, the advantages of P2P connections become clear:

And so began a time of wandering through the online documentation for WebRTC, a P2P protocol that is native now in most browsers.


The diagram in Figure 2 shows the current default configuration for multiplayer. The thin lines represent the connections that continue to support the chat feature and now the signaling process for the WebRTC connections.

Signaling is the process by which the clients and host exchange their network configuration data needed for NAT traversal, etc. It depends on having a server that is accessible from all computers involved. That means a public server, like the default Heroku server used here, or a computer inside your local network.

Figure 2 shows an example where host and clients are on the same local network. This reflects the same-physical-room setup that has been discussed here; everyone looking at the same display, maybe a projection. Video-stream functionality has been recently added (using the P2P connection of WebRTC). This allows players to be in different rooms, states, countries.

The Node server is shown at a distant location in Figure 2. Since its role now is mainly to establish the P2P connection, its location can be anywhere without reducing performance.

The Heroku server has Node.js running on a free account. By default, the host and client pages use this distant Heroku server for signaling activities. If the default server is used, which is done by leaving the "server" field set to, there is no installation task needed to try the P2P and multiplayer features here. If your network environment/security blocks the WebRTC signaling process, you can try installing the node-server code on a local server following the instructions here.

A few useful things to know:

All the network magic is contained in three files:

Resources that were helpful: