Talk:Network implementation

Discussion about the implementation of network multiplayer.

Useful Links This contains some very interesting articles on networked physics. The actual article appears to be using the 'client as dumb input/output terminal' approach, but it has a list of other articles that might be more useful. This project implements a simple STUN server and client on Windows, Linux, and Solaris. The STUN protocol (Simple Traversal of UDP through NATs) is described in the IETF RFC 3489, available at

Interpolation and rewinding

Due to the high latency that needs to be tolerated in WAN games (think of 100 msec) we have to interpolate the behaviour of karts and items in a race, otherwise the game will become too sluggish. This on the other hand means that we have to be able to roll back certain decisions. For example, locally you might have a collision between your kart and a remote kart (since the update that the remote kart has actually steered away hasn't arrived). But when you receive the update from the remote kart, you have to rewind the local simulation to a previous state, and re-simulate with the updated information that the remote kart is steering. This means to restore the state of bullet physics object saved from a previous time step.

[well, this is what I came up with so far, if someone can think of a better approach, please update the page]

Client/server vs. peer to peer

Gaffer's article on network physics contain a discussion of this (in the comment section). Short summary:

  • p2p is very open to cheating (especially for open source games).
  • bandwidth requirements per client increases with increasing number of clients (esp. considering that upload bandwidth is often lower than the download bandwidth).
  • implementation can be more complicated (e.g. which clients can make the decision which of several karts might have hit an item first).

On the other hand it will reduce latency (two messages for client/server: client to server, then server to other clients).