RPCs vs NetworkVariables Examples
This page has examples of how RPC
s or NetworkVariable
s have been used in the Small Coop Sample (Boss Room Project). It should provide some guidance on when to use RPC
s or NetworkVariable
s 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 NetworkVariable
s, you just want to blast your inputs to the server. Since Boss Room isn't a twitch shooter, we send inputs as reliable RPC
s 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 RPC
s 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 NetworkVariable
s 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 NetworkVariable
s 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 NetworkVariable
s, easily collecting and providing data.
If this was done through RPC
s, we would need to keep a list of RPC
s to send to connecting players to ensure they get the latest hit point values for each object. Keeping a list of RPC
s for each object to send to those RPC
s on connecting would be a maintainability nightmare. By using NetworkVariable
s, we let the SDK do the work for us.