Introduction Manual Class Reference Header Reference

Replicating Player Movement


Perfectly replicating player movement across a network link is a nontrivial task, especially when it comes to first person shooters and similar games, where one keypress results in direct movement of the player's character. Several goals have to be reached:

Zoidcom provides a special replicator that aims for these goals: ZCom_Replicate_Movement. This class implements client side prediction, dead reckoning/extrapolation, interpolation, movement correction and local overrides.


This class provides quite a bit of functionality, but it also requires a few things from the application:


There are three kind of nodes involved:

The movement replication is done by ZCom_Replicate_Movement. An instance of this replicator has to be registered with the player character's node. The abstract class ZCom_MoveUpdateListener needs to be implemented and registered with the replicator, so that it can notify the game object about the events inputUpdated(), correctionReceived() and two others.

Order of events

The following is an order of events that occurs when a player moves. O, A and P stand for owner, authority and proxy respectively. U stands for code executed in the user application, i.e. things the user application has to do, whereas Z stands for tasks done by Zoidcom.

(*) The owner receives a copy of it's own input for processing as soon as Zoidcom has sent the input update to the authority. This ensures that owner and authority stay in sync. Owner is not allowed to use the input before it has been sent to the server.

(**) The authority updates it's physics state in lockstep mode. That means, that the authority object is physically updated ONLY when new input is received from the owner. That is necessary to keep owner and authority in perfect sync.

Summary of physic state updates


The fact, that the server object only gets updated when new input is received, makes it necessary to take additional steps if the server object is to be displayed (in a smooth way). I suggest not displaying server objects at all, and instead run client code in addition to the server code if there is a player playing on the server. Ie if a player hosts a game, his machine becomes server and client at the same time. Instead of implementing special cases for that in the code, just instantiate client and server in the same process, and let the client connect to the server through a local socket.

Example Code

A complete implementation of the above can be found in ex07_movement.
This file is part of the documentation for Zoidcom. Documentation copyright © 2004-2008 by Jörg Rüppel. Generated on Sat Aug 16 15:26:51 2008 for Zoidcom by doxygen 1.4.6-NO