10. Duplicated Object Features Overview

A NetZ duplicated object is composed of a duplication master, which has operation privileges, on one station and duplicas, which are duplicates for reference purposes, on the other stations. NetZ synchronizes the data from the duplication master to the duplicas. The application is never directly involved in the transmission of data.

Duplicated objects have the following features.

10.1. Incorporating Duplicated Object Features in Games

There are two ways to apply duplicated objects to your game. The first method is to completely integrate the NetZ calls and classes into the game's source code. The other method involves delegating operations on objects to NetZ after the game has been written.

The first approach is best if you are writing your game from scratch with multiplayer gameplay in mind from the start.

The second method can be used when you have already written your game and want to add networking to it. It allows you to include the duplicated object hierarchy while maintaining your existing game hierarchy. This approach is recommended for most games. It is particularly useful if you have written a single-player game that you want to network, or have a networked game where the current network is unsatisfactory.

Which route you take to integrate duplicated objects into your game depends largely on whether you have already written your game. Nevertheless, the choice is entirely up to you, because NetZ functions equally well using either method of incorporation.

There are four steps to integrate duplicated objects into your game.

Write DDL file:
In the Data Definition Language (DDL) file, define the information, game objects, and their attributes that must be sent across the network.
Compile DDL:
Compile the DDL file using the DDL compiler. The compiler generates network code specific to each duplicated object defined in the file.
Integrate:
Implement appropriate methods to integrate the DDL-generated classes, the NEX P2P library, and your code.
Optimize:
Use your C++ compiler to generate your networked game executable. Then start tweaking things until your game is working exactly how you want.

10.2. Types of Control for Duplicated Object Features

There are two types of control for duplicated object features. One is a centralized architecture where all of the duplication masters are placed on a station that acts as the server (usually the session master) while the client stations send operations to the server station and get position and other data in return. The other is a distributed architecture where the duplication masters are spread throughout the system.

You are not limited to just one of these two types of control. NetZ lets you choose the control type separately depending on the characteristics of the duplication master. For example, you could distribute most objects throughout the system and have just a small number of them on the server, or you could distribute a small number of objects and have most of them concentrated on the server.

10.2.1. Centralized Control

In games that use centralized control, the server controls the entire game and the individual clients always follow instructions from the master.

There are two ways to generate duplicated objects with centralized control architecture. One is to have the client request that the server create a duplicated object for it. Another is to have the client create its own local duplicated object and migrate it to the server.

_images/Fig_Overview_Centralized_Network.png

Figure 10.1 Centralized Control

The client sends operations on the duplication master to the server, and the server automatically propagates the results of the operations to all clients.

10.2.2. Distributed Control

In a game that uses distributed control, each station controls its part of the game state and is an authority on what is going on for that part.

For example, in Figure 10.2, station 1 handles operations such as the movement of duplication master A and synchronizes the object with the duplicas on all other stations by sending changes in position and other information. Station 2 handles duplication master B in a similar manner, as does station 3 with duplication master C.

_images/Fig_Overview_Distributed_Network.png

Figure 10.2 Distributed Control

One problem with distributed control is the lack of a consistent state for the entire game network. Objects A, B, and C are updated at different times and with different propagation delays. This makes it impossible to guarantee that the states of all objects in all stations match in the synchronization process.

10.2.3. Choosing the Topology

The type of control that you use drives the network topology that you select for NetZ. If you implement your application using distributed control, it adapts more readily to a P2P network topology or a hybrid network topology. If you implement your application using centralized control, it adapts more readily to a client-server game topology. The choices you make depend on the needs of your application and the capabilities of your physical network.


CONFIDENTIAL