 Replica Manager 3 Plugin Interface Implementation |
|
Replica Manager 3 Implementation Overview Any game that has objects that are created and destroyed while the game is in progress, almost all non-trivial games, faces a minimum of 3 problems:
Additional potential problems, depending on complexity and optimization
The solution to most of these problems is usually straightforward, yet still requires a significant amount of work and debugging, with several dozen lines of code per object. ReplicaManager3 is designed to be a generic, overridable plugin that handles as many of these details as possible automatically. ReplicaManager3 automatically creates and destroys objects, downloads the world to new players, manages players, and automatically serializes as needed. It also includes the advanced ability to automatically relay messages, and to automatically serialize your objects when the serialized member data changes. Order of operations: Objects are remotely created in the order they are registered using ReplicaManager3::Reference(). All objects created or destroyed in a tick are created or destroyed in the same packet, meaning all calls to construct or destroy objects are triggered by the same RakPeerInterface::Receive() call. Serialize() happens after construction. Therefore, all objects will be created and will have DeserializeConstruction() called before any Serialize() call happens for any of the objects created that update tick. Unlike construction, Serialize() calls may be spread out over multiple calls to RakPeerInterface::Receive() call depending on bandwidth availability. Therefore, be sure that you send all data necessary for the object to be properly setup in the initial SerializeConstruction() call, since it is not guaranteed you will receive Deserialize() on the same tick. The first time objects are sent to a remote system, you will get the Connection_RM3::DeserializeOnDownloadComplete() once all objects have been constructed and Deserialized(). Dependency resolution: If one object refers to another (for example, a gun has a pointer to its owner) then the dependent objects need to be created first. In the case of a gun with a pointer to its owner, the owner would be created first. The gun would serialize the NetworkID of the owner, and lookup the owner in its DeserializeConstruction call. This can be achieved by registering the objects in that order using ReplicaManager3::Reference(). Sometimes you have dependency chains that cannot be resolved through reordering. For example, a player has an inventory list, and each item in the inventory has a pointer to its owner. Or you may have a circular chain, where A depends on B, B depends on C, and C depends on A. Or it may not be feasable to reorder the objects. For these cases, you can resolve dependencies in the Replica3::PostDeserializeConstruction() callback. PostDeserializeConstruction() is called after DeserializeConstruction() completes for all objects in a given update tick, so all objects that are going to be created will have been created by then. Static Objects: Sometimes you have an object that already exists in the world and is known to all systems. For example, a door on level load. In those situations you usually do not want the server to transmit the object creation message, since it would result in the same door twice. Yet you still want to reference and serialize the object, such as the door opening and closing, or the remaining health for the door.
RM3CS_ALREADY_EXISTS_REMOTELY causes ReplicaManager3 to consider the door to exist on the other system, so when Serialize() is called updates will still be sent to that system. But the SerializeConstruction() call and object creation is skpped. Combining with FullyConnectedMesh2 If you are using FullyConnectedMesh2 for host determination and ReplicaManager3 relies on a host, then you have to delay calling AddParticipant() until a host has been determined. Here is how to do so:
Explanation: Line 1, the first parameter to Replicamanager3::SetAutoManageConnections() is set to false in order to disable ReplicaManager3 from automatically calling PushConnection(), because you want to delay systems from participating in Replicamanager3 until a host has been determined. The second parameter is up to you. Line 2: If every system that connects to you is another game instance, you can leave SetAutoparticipantConnections() as the default to true, and do not need to call fullyConnectedMesh2->AddParticipant(packet->guid); later either. The reason this is here is in case you want to connect to a profiling tool or other non-game program. Line 3: FullyConnectedMesh2 requires a fully connected mesh topology, so you need to connect to everyone else in the game instance. This can be done with a simple rakPeer->Connect() call, or you could have other systems such as NAT punchthrough involved depending on your needs. The code here works with both everyone starting at the same time from a lobby, and with mid-game joins. See the manual page on connecting for more information about this. Line 4: Until a host has been determined, fullyConnectedMesh2->GetConnectedHost() will return UNASSIGNED_RAKNET_GUID. In that case, we delay replicaManager3->PushConnection() until ID_FCM2_NEW_HOST is returned. However, if a host is already known (for example, the game is already in progress), then the remote system is added immediately. Line 5: Once the host is known for the first time, all connected systems can be added to ReplicaManager3. oldHost==UNASSIGNED_RAKNET_GUID means there was no prior host. Line 6: A function to uniquely add connections to ReplicaManager3 given a list of remote RakNetGUIDs. Integration with component based systems By component-based system I mean one where a game actor has a list of classes attached, each of which contain an attribute of the actor itself. For example, a player may have position, health, animation, physics components for example. 1. Instances of the same actor either have the same type, order, and and number of components or else when you serialize you will have to provide a way to identify components. To Serialize(), first Serialize() your actor. Then Serialize() your components in order.2. Here is an example of QuerySerialization() in a peer to peer game where the host controls objects loaded with the level (static objects). Otherwise, the peer that created the object serializes it. However, a component can override this and allow the host to serialize the object regardless. For example, if a player puts a weapon on the ground, the weapon could return RM3QSR_CALL_SERIALIZE if our own system is the host system, and RM3QSR_DO_NOT_CALL_SERIALIZE otherwise.
if (IsAStaticObject())
{
// Objects loaded with the level are serialized by the host
if (fullyConnectedMesh2->IsHostSystem())
return RM3QSR_CALL_SERIALIZE;
else
return RM3QSR_DO_NOT_CALL_SERIALIZE;
}
else
{
// Allow components opportunity to overwrite method of serialization
for (int i=0; i < components.Size(); i++)
{
RM3QuerySerializationResult res = components[i]->QuerySerialization(destinationconnection);
if(res != RM3QSR_MAX)
return res;
}
return QuerySerialization_PeerToPeer(destinationconnection);
}
3. This variation, for QueryConstruction(), has components return Replica3P2PMode instead. Using the gun example, a gun may controlled by the host when on the ground, or by another player when picked up. If R3P2PM_MULTI_OWNER_CURRENTLY_AUTHORITATIVE or R3P2PM_MULTI_OWNER_NOT_CURRENTLY_AUTHORITATIVE is returned by a component, then QueryConstruction_PeerToPeer() will use that value to return an appropriate value for RM3ConstructionState. Internally, QueryConstruction_PeerToPeer() will return RM3CS_SEND_CONSTRUCTION if we control the object, RM3CS_NEVER_CONSTRUCT if we do not control the object and nobody else ever can, and RM3CS_ALREADY_EXISTS_REMOTELY if someone else controls the object but the owner can change.
if (destinationConnection->HasLoadedLevel() == false)
return RM3CS_NO_ACTION;
if (IsAStaticObject())
{
if(fullyConnectedMesh2->IsHostSystem())
return RM3CS_ALREADY_EXISTS_REMOTELY;
else
return RM3CS_ALREADY_EXISTS_REMOTELY_DO_NOT_CONSTRUCT;
}
else
{
Replica3P2PMode p2pMode = R3P2PM_SINGLE_OWNER;
for (int i=0; i < components.Size(); i++)
{
p2pMode = components[i]->QueryP2PMode();
if(p2pMode != R3P2PM_SINGLE_OWNER)
break;
}
return QueryConstruction_PeerToPeer(destinationconnection, p2pMode);
}
virtual Replica3P2PMode BaseClassComponent::QueryP2PMode() {return R3P2PM_SINGLE_OWNER;}
virtual Replica3P2PMode GunComponent::QueryP2PMode()
{
if (IsOnTheGround())
if(fullyConnectedMesh2->IsHostSystem())
return R3P2PM_MULTI_OWNER_CURRENTLY_AUTHORITATIVE;
else
return R3P2PM_MULTI_OWNER_NOT_CURRENTLY_AUTHORITATIVE;
else
if (WeOwnTheGun())
return R3P2PM_MULTI_OWNER_CURRENTLY_AUTHORITATIVE;
else
return R3P2PM_MULTI_OWNER_NOT_CURRENTLY_AUTHORITATIVE;
}
4. If you need to use composition instead of derivation see Replica3Composite in ReplicaManager3.h. It is a templated class with only one member, r3CompositeOwner. All Replica3 interfaces are queried on r3CompositeOwner.
Methods of object serialization: Manual sends on dirty flags Example virtual void Deserialize(RakNet::DeserializeParameters *deserializeParameters) Serializing based on the object changing Example void SetHealth(float newHealth) {health=newHealth;}
Example (also see ReplicaManager3 sample project) virtual RM3SerializationResult Serialize(SerializeParameters *serializeParameters) { Quick start:
For a full list of functions with detailed documentation on each parameter, see ReplicaManager3.h. The primary sample is located at Samples\ReplicaManager3. |
|
Differences between ReplicaManager3 and ReplicaManager2 |
ReplicaManager3 should be simpler and more transparent
|
|
See Also |
|
Index |