RPCs vs NetworkVariables Examples
This page has examples of how RPCs or NetworkVariables have been used in the Small Coop Sample (Boss Room Project). It should provide some guidance on when to use RPCs or 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.
loading...
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
The following RecvPerformHitReactionClient call sends actions from server to client:
loading...
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.
loading...
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.
loading...
Breakable state
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.
loading...
The visual changes:
loading...
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.
loading...
Hit points
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.