Introduction

• Introduction
• Classes And Class IDs
• Adding The Nodes
• Entering Zoidmode
• The Announcement
• Handling Node Events
• Deleting The Server Nodes
• Extended Object Information
• Replication Summary

Introduction

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:

• Internal objects which want to communicate with their counterpart on clients.
  • Chat object - Receives and sends chat lines from and to clients
  • Weather object - Sends ingame weather information to clients
• Internal objects which want to synchronize state with clients
  • Gamestate object - Distributes information about the state of the game to all clients (e.g. team scores)
  • Player objects - Contain names, team, ping and other stats about each player
• Objects that are part of the game world
  • Static objects like trees - These are sent once but never change position or state, unless they are destructible, in which case they don't belong into this category
  • Objects with state like doors, switches - They don't move but they change state and appearance
  • Movable objects like players, projectiles, cars, monsters - These generate the most traffic since they need to get updated frequently

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:

• Authority is the role possessed by objects on the server. All data updates made here override everything else on the clients. Updates received from Owners can, but do not necessarily need to be accepted.
• Owner is the role assigned to the copy on the controlling player's machine. This node can update the authority with input and other things.
• Proxy is the role assigned to objects that players will see but don't have influence on, i.e. all objects not under their control. These objects receive their updates from the authority.

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

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:

• The data arrives directly at the destination object and not in the server/client class.
  If object related messages were received in the ZCom_Control, the application had to find out to which object the message belongs, find that object and then call some method on that object to notify it about the incoming message. When node events are used, the message can be fetched directly from the object's node. No passing around of messages is necessary as this is completely handled by Zoidcom.
• The data is prioritized with the object's priority.
  Imagine two objects, one very important one generating a little bit of traffic and a relatively unimportant one generating a lot of traffic. When the node of the important object gets a higher priority than the node of the unimportant one, events/messages generated by the high-importance object are sent before those of the other object, regardless of how much traffic the low priority object generates.

---