This page contains 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.
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 is not a twitch shooter, we send inputs as reliable
RPCs without worrying about the additional latency an input loss would add.
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 do not 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.
The archer's arrows uses a standalone
GameObject that is replicated over time. Since this object's movements are slow moving, we made the choice to use state to replicate this ability's status, in case a client connected while the arrow was flying.
We could have used an
RPC instead, for example the Mage's projectile attack. Since it is expected for that projectile to be quick, we are not affected by the few milliseconds where a newly connected client could 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 could have used a "kill"
RPC to set a character as dead and play the appropriate animations. 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 state changes animation.
The animation change:
Error when connecting after imps have died: The following is a small gotcha we encountered while developing Boss Room. Using
NetworkVariables is not magical. If you use
OnValueChanged, you still need to make sure you initialize your values when spawning for the first time.
OnValueChanged will not be called when connecting for the first time, only for the subsequent value changes.
All of our replicated object's position is 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 position 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.