This page has examples of how
NetworkVariables have been used in the Small Coop Sample (Boss Room Project). It should provide some guidance on when to use
NetworkVariables in your own projects.
See the RPC vs NetworkVariable tutorial for more information.
RPCs for movement
Boss Room uses RPCs to send movement inputs.
We want the full history of inputs sent, not just the latest value. There is no need for
NetworkVariables, you just want to blast your inputs to the server. Since Boss Room isn't a twitch shooter, we send inputs as reliable
RPCs without worrying about the additional latency an input loss would add.
Sending action inputs RPCs
RecvPerformHitReactionClient call sends actions from server to client:
For example, the Boss Room project "ouch" action
RPC mentioned for
NetworkCharacterState is interesting for optimization purposes. You would normally want to have only one
RPC for an action and let the client decide who should play the associated animation. Due to "ouch" being a long running action over multiple frames, you don't know yet when sending the initial
RPC which characters will be affected by that action. You want this to be dynamic as the boss is hitting targets. As a result, multiple
RPCs will be sent for each hit character.
Arrow's GameObject vs Fireball's VFX
The archer's arrows uses a standalone
GameObject that is replicated over time. Since this object's movements are slow, we made the choice to use state (via the NetworkTransform) to replicate this ability's status, in case a client connected while the arrow was flying.
We can have used an
RPC instead, for example the Mage's projectile attack. Since it's expected for that projectile to be quick, we aren't affected by the few milliseconds where a newly connected client can miss the projectile and we save on bandwidth having to manage a replicated object. Instead a single RPC is sent to trigger the FX client side.
We can have used a "break"
RPC to set a breakable object as broken and play the appropriate visual effects. Applying our "should that information be replicated when a player joins the game mid-game" rule of thumb, we used
NetworkVariables instead. We used the
OnValueChanged callback on those values to play our visual effects, as well as an initial check when spawning the NetworkBehaviour.
The visual changes:
Error when connecting after imps have died: The following is a small gotcha we encountered while developing Boss Room. Using
NetworkVariables isn't magical. If you use
OnValueChanged, you still need to make sure you initialize your values when spawning for the first time.
OnValueChanged won't be called when connecting for the first time, only for the subsequent value changes.
All of our characters and objects' hit points are synced through
NetworkVariables, easily collecting and providing data.
If this was done through
RPCs, we would need to keep a list of
RPCs to send to connecting players to ensure they get the latest hit point values for each object. Keeping a list of
RPCs for each object to send to those
RPCs on connecting would be a maintainability nightmare. By using
NetworkVariables, we let the SDK do the work for us.