Introduction Manual Class Reference Header Reference



Object replication in Zoidcom is handled by the classes ZCom_Control and ZCom_Node. A node, an instance of ZCom_Node, is the binding object between an application object and Zoidcom, it represents the application object in the network layer: Each networkable application object needs it's own node.

Whenever a new client connects, all relevant nodes that currently exist on the server are distributed to the client. The client will create the requested objects. After that, each server object has copies of itself on N clients, where N is the number of clients interested in each object. The original server object has the role eZCom_RoleAuthority. The copies on the clients have the role eZCom_RoleProxy or eZCom_RoleOwner.

What is a networkable application object? Examples:

The above list is by no means complete, but it should give quite a good overview over what can be considered a networkable object.

Object Roles

Zoidcom has a simple role concept for replicated objects. The originating object (or more accurate, it's node), has the role 'Authority'. Normal copies on clients have the role 'Proxy'. The 'Authority' can promote the role of proxies to the higher role 'Owner'. Normally, data synchronization and messages are sent from authority to proxies, whereas owner nodes have the ability to feed the authority with updates. Mapping this to games shows that:

What the owner nodes can and cannot do is by no means hardcoded into Zoidcom. The application can query the role of the local and remote nodes at any time and decide if the received data is accepted, processed or simply ignored.


Zoidlevels are filtergroups for objects. Each node can be registered with one or more Zoidlevels, while clients can request to enter a specific level. When on level 2, only nodes that are on level 2 are replicated to this client, while nodes registered only on other levels are not.

Replication Features

Maybe you ask yourself what is gained by using object replication, as you could as well not use it and stay with ZCom_Control::ZCom_sendData() instead and send everything yourself. And that's exactly the point. You can either handle, manage, prepare and send everything on your own, or you can let Zoidcom take care of these tasks.

Object Replication

Zoidcom can handle the announcement and deannouncement of objects to clients. Objects have a general priority that is used to determine which of them needs to get announced first and updated the most often. Furthermore, the application can inform Zoidcom about how relevant an object is to a specific client. When the relevance is set to 0, the client will never receive the object, set to 1 means full relevance. This value can be anything between 0 and 1 and is multiplied with the general priority of the object for each client. This allows situations like 'rockets are more important than trees, but for this player, the tree is more important because the rocket is far away'. So the rocket could have a general priority of 200, the tree's priority could be 50. But the connection specific relevance of the rocket to the client is next to zero or zero while the tree has full relevance because the game determined it is in the client's field of view. This saves traffic and pushes the game experience on tight connections because irrelevant data is not sent.

State Synchronization

State synchronization essentially means automatic updating of object variables between server and client. A lot of effort has gone into making this as efficient and flexible as possible. Once the relevant object variables are registered with the node, the hard work is taken over by Zoidcom.

Node/Object Events

Object events are the node equivalent of ZCom_Control::sendData(). With sendData(), you send data on one ZCom_Control and another control receives it. With node events on the other hand, you send data from the server (aka authority) node to all client (aka proxy) nodes, or from one special client node to the server node and from there to all other client nodes. The key differences in comparison to ZCom_sendData() are:

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