RPC vs NetworkVariable
Choosing the wrong data syncing mechanism can create bugs, use too much bandwidth, and add too much complexity to your code.
Netcode for GameObjects (Netcode) has two main ways of syncing information between players: RPCs (Remote Procedure Calls) and replicated states (NetworkVariables). They both send messages over the network. The logic and your design around how they send messages is what will make you choose one over the other.
Choosing between NetworkVariables or RPCs
- Use RPCs for transient events, information only useful for a moment when it's received.
- Use
NetworkVariables for persistent states, for information that will be around more than a moment.
A quick way to choose which to use is to ask yourself: "Should a player joining mid-game get that information?"
Using the Boss Room's door as an example. A player's client needs to receive the information that the door is open to play the right animations.
If we sent an RPC to all clients, then all players connecting mid-game after that RPC is sent will miss that information and have the wrong visual on their clients.
In that case, it's preferable to use NetworkVariables as show below:
/// <summary>
/// This class contains both client and server logic for a door that is opened when a player stands on a floor switch.
/// (Assign the floor switches for this door in the editor.)
/// Represents a door in the client. The visuals of the door animate as
/// "opening" and "closing", but for physics purposes this is an illusion:
/// whenever the door is open on the server, the door's physics are disabled,
/// and vice versa.
/// </summary>
public class SwitchedDoor : NetworkBehaviour
{
[SerializeField]
FloorSwitch[] m_SwitchesThatOpenThisDoor;
[SerializeField]
Animator m_Animator;
public NetworkVariable<bool> IsOpen { get; } = new NetworkVariable<bool>();
It uses a BoolNetworkVariable to represent the IsOpen state. If one player opens the door and a second player connects after this, the host replicates all the world's information to that new player, including the door's state.
NetworkVariables are eventually consistent. This means not all value changes will be synced, contrary to RPCs, where five calls to an RPC will produce five RPC sends on the network.
NetworkVariables will save on bandwidth for you, making sure to only send values when the data has changed. However, if you want all value changes, RPCs might be best.
Why not use NetworkVariables for everything?
RPCs are simpler.
If you have a temporary event like an explosion, you don't need a replicated state for this. It would not make sense. You would have an "unexploded" state that would need to be synced every time a new player connected? From a design perspective, you might not want to represent these events as state.
An explosion can use an RPC for the event, but the effect of the explosion should be using NetworkVariables (for example player's knockback and health decrease). A newly connected player doesn't care about an explosion that happened five seconds ago. They do care about the current health of the players around that explosion though.
Actions in Boss Room are a great example for this. The area of effect action (AoeAction) triggers an RPC when the action is activated (showing a VFX around the affected area). The imp's health (NetworkVariables) is updated. If a new player connects, they will see the damaged imps. We would not care about the area of effect ability's VFX, which works great with a transient RPC.
AoeActionInput.cs Shows the input being updated client side and not waiting for the server. It then calls an RPC when clicking on the area to affect.
using Unity.BossRoom.Gameplay.GameplayObjects;
using UnityEngine;
using UnityEngine.AI;
namespace Unity.BossRoom.Gameplay.Actions
{
/// <summary>
/// This class is the first step in AoE ability. It will update the initial input visuals' position and will be in charge
/// of tracking the user inputs. Once the ability
/// is confirmed and the mouse is clicked, it'll send the appropriate RPC to the server, triggering the AoE serer side gameplay logic.
/// The server side gameplay action will then trigger the client side resulting FX.
/// This action's flow is this: (Client) AoEActionInput --> (Server) AoEAction --> (Client) AoEActionFX
/// </summary>
public class AoeActionInput : BaseActionInput
{
[SerializeField]
GameObject m_InRangeVisualization;
[SerializeField]
GameObject m_OutOfRangeVisualization;
Camera m_Camera;
//The general action system works on MouseDown events (to support Charged Actions), but that means that if we only wait for
//a mouse up event internally, we will fire as part of the same UI click that started the action input (meaning the user would
//have to drag her mouse from the button to the firing location). Tracking a mouse-down mouse-up cycle means that a user can
//click on the NavMesh separately from the mouse-click that engaged the action (which also makes the UI flow equivalent to the
//flow from hitting a number key).
bool m_ReceivedMouseDownEvent;
NavMeshHit m_NavMeshHit;
// plane that has normal pointing up on y, that is 0 distance units displaced from origin
// this is also the same height as the NavMesh baked in-game
static readonly Plane k_Plane = new Plane(Vector3.up, 0f);
void Start()
{
var radius = GameDataSource.Instance.GetActionPrototypeByID(m_ActionPrototypeID).Config.Radius;
transform.localScale = new Vector3(radius * 2, radius * 2, radius * 2);
m_Camera = Camera.main;
}
void Update()
{
if (PlaneRaycast(k_Plane, m_Camera.ScreenPointToRay(Input.mousePosition), out Vector3 pointOnPlane) &&
NavMesh.SamplePosition(pointOnPlane, out m_NavMeshHit, 2f, NavMesh.AllAreas))
{
transform.position = m_NavMeshHit.position;
}
float range = GameDataSource.Instance.GetActionPrototypeByID(m_ActionPrototypeID).Config.Range;
bool isInRange = (m_Origin - transform.position).sqrMagnitude <= range * range;
m_InRangeVisualization.SetActive(isInRange);
m_OutOfRangeVisualization.SetActive(!isInRange);
// wait for the player to click down and then release the mouse button before actually taking the input
if (Input.GetMouseButtonDown(0))
{
m_ReceivedMouseDownEvent = true;
}
if (Input.GetMouseButtonUp(0) && m_ReceivedMouseDownEvent)
{
if (isInRange)
{
var data = new ActionRequestData
{
Position = transform.position,
ActionID = m_ActionPrototypeID,
ShouldQueue = false,
TargetIds = null
};
m_SendInput(data);
}
Destroy(gameObject);
return;
}
}
/// <summary>
/// Utility method to simulate a raycast to a given plane. Does not involve a Physics-based raycast.
/// </summary>
/// <remarks> Based on documented example here: https://docs.unity3d.com/ScriptReference/Plane.Raycast.html
/// </remarks>
/// <param name="plane"></param>
/// <param name="ray"></param>
/// <param name="pointOnPlane"></param>
/// <returns> true if intersection point lies inside NavMesh; false otherwise </returns>
static bool PlaneRaycast(Plane plane, Ray ray, out Vector3 pointOnPlane)
{
// validate that this ray intersects plane
if (plane.Raycast(ray, out var enter))
{
// get the point of intersection
pointOnPlane = ray.GetPoint(enter);
return true;
}
else
{
pointOnPlane = Vector3.zero;
return false;
}
}
}
}
AOEAction.cs has server-side logic detecting enemies inside the area and applying damage. It then broadcasts an RPC to tell all clients to play the VFX at the appropriate position. Character's state will automatically update with their respective NetworkVariables update (health and alive status for example).
/// <summary>
The following snippet of code is triggered by an RPC coming from the server
public override bool OnStartClient(ClientCharacter clientCharacter)
{
base.OnStartClient(clientCharacter);
GameObject.Instantiate(Config.Spawns[0], Data.Position, Quaternion.identity);
return ActionConclusion.Stop;
}
If you want to make sure two variables are received at the same time, RPCs are great for this.
If you change NetworkVariables "a" and "b", there is no guarantee they will both be received client side at the same time.
Sending them as two parameters in the same RPC ensures they will be received at the same time client side.
NetworkVariables are great when you only care about the latest value.
Summary
NetworkVariables are great for managing state, to make sure everyone has the latest value. Use them when you want to make sure newly connected players get an up to date world state.
RPCs are great for sending transient events. Use them when transmitting short-lived events.