5. Complex hierarchies
Game characters and other networked entities are often made of very deep hierarchies of nested GameObjects, needing to sync specific properties along these chains. In addition, a common use case is to parent a networked object to the tip of a chain of GameObjects.
Let's see how to handle these cases.
- A/D or Left/right joypad triggers: Rotate crane base
- W/S or Left joystick up/down: Raise/lower crane head
- Q/E or Left joystick left/right: Move crane head forward/back
- P/Space/Enter or Joypad button left: Pickup and release crate
This scene features a robotic arm that can be controlled by one player at a time. In the scene, a small crate can be picked up and released.
The first player to connect takes control of the arm, and other players can request it via a UI button.
To demonstrate complex hierarchies we choose to sync the movement of a robot arm, made of several GameObjects. In addition to syncing several positions and rotations, we also sync animation variables and other script parameters, present on child objects.
To sync the whole arm we use a coherence feature called deep bindings, that is bindings that are located not on the root object, but deeper in the transform hierarchy.
Select the RobotArm __ Prefab asset located in
/Prefabs, and open it for editing. You will immediately notice a host of little coherence icons to the right of several GameObjects in the Hierarchy window:
The icons in the Hierarchy show the GameObjects that contain bindings.
These icons are telling us that these GameObjects have one or more binding currently configured (a variable, a method, or a component action).
Now open the coherence Configuration window, and click through those objects to discover what's being synced:
The root syncs only Transform.position (by default) and animation.
In addition to position and rotation, we also choose to sync the animation parameter ClawsOpen, and enable
Animator.SetTrigger()as a Network Command. Finally we disable the Robot Arm script when losing authority (to disallow input).
This is the base of the robot arm, for which we only sync rotation:
The physical base of the arm syncs its rotation
We don't sync the rotation of every object in the chain, since the arm is equipped with an IK solver, which allows us to just sync the target (Two-Bone IK_target) and work out the rotation of the limb (robotarm_bottomarm and robotarm_toparm) on each Client:
The IK target syncs both position and rotation.
By syncing all of these properties, we can have the robotic arm move in sync on all Clients, simply by translating the tip of the IK, and rotating the base of the crane. All of the bindings in this hierarchy are synced through the Coherence Sync component present on the Prefab's root object RobotArm.
As you can see, using deep bindings doesn't require any special setup: they are enabled in exactly the same way as a binding, Network Command or Component action on the root object.
As mentioned in the lesson about Parenting Entities, parenting a network entity to a GameObject that belongs to a chain requires some setup. To be able to pick up the crate with the crane, we equip it with a
The Path property displays the location in the hierarchy where this object will be inserted. It gets automatically updated by coherence every time the object is parented. Each number represents a child in the root object (and it's 0-based).
Once we have this component set up, parenting the object only requires calling
Transform.SetParent()like any usual parenting operation, and setting its
Rigidbodycomponent to be kinematic.
When we do this, coherence takes care of propagating the parenting to other Clients, so that the crate becomes a child GameObject on every connected Client.
This code is in the
RobotArmHandclass, a component attached to the tip of our hierarchy chain: GrabPoint. In
OnTriggerEnterwe detect when the crate is in range, storing a reference to it in a variable of type
This reference is set to sync:
The end point of the arm syncs two variables of its Robot Arm Hand script, useful for the grabbing behavior.
When the player presses the key P (or the Left Gamepad face button), the referenced crate is parented to the GrabPoint GameObject.
Note that coherence natively supports syncing references to
Transformcomponents, and to GameObjects.
Even if the Robot Arm Hand script is disabled on non-authoritative Clients, by referencing the grabbed crate in the
grabbableObjectvariable and syncing it over the network, even if a Client disconnects, other Clients will already have the correct reference to the crate network entity.
This allows us to gracefully handle a case where, for instance, a Client picks up the crate and disconnects. Because both the crate and the robot arm have Auto-adopt Orphan set to "on", authority is passed onto another Client and they immediately have all the data needed to keep handling the crate.
To move authority between Clients, we can use the UI in the bottom left corner. The button is connected to the Robot Arm Authority script on the ArmAuthoritySwapper GameObject. This script takes care of the authority transfer and what happens as a result, including setting the crate to be kinematic or not.
Differently from other scenes (like the lesson on Physics) where the object is always non-kinematic on the Client simulating it, in this case we want the crate to stay kinematic when authority changes while it's being held.
Is Kinematic is set as follows:
On the authority Client
On non-authoritative Clients
Is being held
Has been released
The code is in the
RobotArmAuthorityclass. To detect whether it's currently being held, it's as simple as checking whether its
crate.GetComponent<Rigidbody>().isKinematic = crate.transform.parent != null;
Remember you can use Tab/click the Gamepad stick to use the authority visualization mode. Try requesting authority from another Client while in this mode.
Both the robot arm and the crate are currently simulated on this Client.