RPCs in Fusion Shared Mode

This page accompanies the Photon Fusion 2 RPCs Explained: Send Events Between Players video and explains how to send one-time events between peers using Remote Procedure Calls in Photon Fusion Shared Mode.

Use this page when implementing actions such as emotes, notifications, ready states, votes, visual effects, private messages, or requests sent to an authoritative shared object.

If you want a dedicated deep dive on RPCs, take a look here.

Overview

An RPC, or Remote Procedure Call, requests that a method execute on another peer over the network.

RPCs are suitable for actions that happen at a specific moment, such as:

• showing an emote;
• sending a ready notification;
• submitting a vote;
• triggering a temporary sound or effect;
• sending feedback to one player;
• requesting an update on an authoritative shared object.

RPCs represent events, not persistent state.

If a player joins after an RPC has already executed, that player does not automatically receive its result. When the result must also be visible to late joiners or reconnecting players, store it in a [Networked] property.

The examples in this video use RPCs to initiate actions and Networked properties to preserve their results.

The tutorial demonstrates three communication patterns:

• all peers to all peers;
• State Authority to one target player;
• all peers to the State Authority of a Master Client object.

Video Timeline

Time	Section
00:00	Introduction
00:23	Fusion Essentials overview
01:22	Script setup
01:42	RPC basics in Fusion
04:12	RPCs and late joiners
04:31	Targeted RPC setup
05:23	Synchronizing emotes with RPCs
11:03	Player enter and exit detection with RPCZone
13:32	Setting up visual zones in Unity
14:38	Testing current progress
15:01	Completing targeted RPC logic
16:55	Testing targeted RPCs
17:16	Master Client counter zone
21:38	Testing the final result

What Is an RPC?

RPC stands for Remote Procedure Call.

A normal C# method runs only in the local process. An RPC can be invoked locally and transmitted through Fusion so that it executes on selected network peers.

For example, a local player can invoke an RPC to:

• notify every player that they selected an emote;
• send a private effect to one target;
• ask the State Authority of a shared object to update a counter.

RPC behavior is controlled primarily by:

• RpcSources;
• RpcTargets;
• optional target parameters;
• channel configuration;
• tick alignment;
• local invocation settings.

RPCs Are Messages

An RPC is a network message associated with a method call.

It is useful for transient actions that do not need to exist as permanent replicated data.

Examples include:

• play a sound;
• show a temporary notification;
• trigger an animation;
• submit a button press;
• send a chat or emote event;
• request an authoritative action.

RPCs should not replace Networked properties for data that must remain available after the event.

RPCs Compared with Networked Properties

Requirement	RPC	Networked Property
One-time event	Recommended	Usually unnecessary
Persistent state	Not sufficient by itself	Recommended
Late-join synchronization	No	Yes
Temporary visual effect	Recommended	Optional
Current score	Not by itself	Recommended
Current selected emote	Can initiate the change	Stores the result
Ready status	Can submit the action	Stores the current status
Vote request	Can send the vote	Stores totals or current choices

A common pattern is:

1. Send an RPC.
2. Validate or process the event on the correct authority.
3. Update a Networked property.
4. Let Fusion replicate the resulting state.

Late Joiners

RPC history is not automatically replayed for players who join later.

For example, suppose an RPC displays an emote and sets no Networked state:

1. Player A triggers the RPC.
2. Existing peers display the emote.
3. Player B joins afterwards.
4. Player B has no record that the RPC occurred.

If the emote’s current state must be visible to Player B, store it in Networked properties.

In the sample, the RPC initiates the action while Networked properties store:

• which emote is active;
• whether a new display update should occur;
• how long the emote remains visible.

Default RPC Options

Fusion RPCs provide several configuration options.

Channel

RPCs use a reliable channel by default.

Reliable delivery is appropriate when the event must arrive, such as:

• ready actions;
• purchases;
• votes;
• important UI notifications;
• authoritative requests.

Use an unreliable channel only when losing the event is acceptable.

Potential examples include:

• frequent cosmetic effects;
• non-critical transient indicators;
• effects that will soon be replaced by newer ones.

InvokeLocal

InvokeLocal is enabled by default.

This means the RPC can execute on the same peer that invokes it when that peer is included in the target set.

Disabling local invocation can be useful when the caller should wait for remote processing rather than immediately execute the method locally.

TickAligned

TickAligned is enabled by default.

Fusion delays RPC execution until the appropriate simulation tick.

This helps preserve ordering relative to networked simulation.

For presentation-only actions that do not need tick alignment, a project may choose different behavior, but the default is suitable for most gameplay-related RPCs.

RPC Source and Target Rules

Every RPC defines:

• which peers are allowed to send it;
• which peers should execute it.

Example:

C#

[Rpc(RpcSources.All, RpcTargets.All)]
private void RPC_AllToAll(int emoteId)
{
}

RpcSources.All means any peer is allowed to invoke the RPC.

RpcTargets.All means every applicable peer executes it.

RpcSources

RpcSources controls who may send an RPC.

Common source options include:

Source	Meaning
RpcSources.All	Any peer can invoke the RPC.
RpcSources.StateAuthority	Only the peer with State Authority over the object can invoke it.
RpcSources.InputAuthority	The peer with Input Authority can invoke it where that authority model applies.

In Shared Mode, player objects commonly use State Authority to identify the peer that owns and controls that object.

RpcTargets

RpcTargets controls where the RPC executes.

Common target options include:

Target	Meaning
RpcTargets.All	Execute on all applicable peers.
RpcTargets.StateAuthority	Execute only on the object’s State Authority.
RpcTargets.InputAuthority	Execute on the peer with Input Authority where applicable.
Targeted PlayerRef	Execute only on the specified player.

The source and target rules should match the object’s authority model.

RPC Method Naming

Fusion RPC method names must include RPC as either a prefix or suffix.

Examples:

C#

RPC_ShowEmote()

C#

ShowEmote_RPC()

Names without the required RPC marker are not treated as valid Fusion RPC methods.

RPC Attribute

RPC methods use the [Rpc] attribute:

C#

[Rpc(RpcSources.All, RpcTargets.All)]
private void RPC_ShowEmote(int emoteId)
{
}

The method is declared on a NetworkBehaviour associated with a spawned NetworkObject.

RPC Parameter Types

RPC parameters must use types supported by Fusion serialization.

Common parameter categories include:

• primitive numeric types;
• bool;
• enums;
• Unity value types supported by Fusion, such as vectors and quaternions;
• PlayerRef;
• Fusion network types;
• supported NetworkString types;
• custom structs that follow Fusion’s network serialization requirements.

Avoid passing arbitrary managed objects, scene-only references, MonoBehaviours, or unsupported classes.

For custom data, define a compact network-compatible structure rather than transmitting a general C# object graph.

RpcInfo

An RPC can include an optional RpcInfo parameter:

C#

[Rpc(RpcSources.All, RpcTargets.All)]
private void RPC_AllToAll(
    int emoteId,
    RpcInfo info = default)
{
}

RpcInfo can provide metadata such as:

• the RPC source;
• local or remote invocation information;
• tick-related context;
• channel information.

In the sample, it is used to log the sender and receiver so the communication pattern is easy to verify.

Scene Overview

The tutorial scene contains three trigger zones.

Each zone uses the same RPCZone script but selects a different communication pattern.

Zone Type	RPC Pattern
AllToAll	Any peer sends to all peers.
StateAuthorityToTarget	A player’s State Authority sends to one selected player.
AllToMasterClient	Any peer sends to the State Authority of a Master Client object.

The player prefab contains:

• EmoteRPCHandler;
• EmoteDisplay;
• trigger-compatible collision components.

The scene also contains:

• MasterClientEmoteCounter;
• visual zone objects;
• world-space emote UI.

Script Responsibilities

Script	Responsibility
RPCZone	Detects the local player entering a zone and selects the RPC example.
ERPCZoneType	Identifies which communication pattern the zone uses.
EmoteRPCHandler	Contains RPC methods and synchronized emote state.
EmoteDisplay	Handles local emote visuals.
MasterClientEmoteCounter	Stores and displays the shared counter.

Separating these responsibilities keeps networking logic independent from scene presentation.

RPCZone

RPCZone is attached to each trigger zone.

When an object enters the trigger:

1. Find its EmoteRPCHandler.
2. Check whether the local peer has State Authority over that player.
3. Call TryTriggerZone.
4. Pass the configured zone type and emote identifier.

Conceptually:

C#

private void OnTriggerEnter(Collider other)
{
    if (!other.TryGetComponent(
            out EmoteRPCHandler player))
    {
        return;
    }

    if (!player.HasStateAuthority)
    {
        return;
    }

    player.TryTriggerZone(
        _zoneType,
        _emoteId
    );
}

Why Check State Authority?

Every client can contain proxy representations of other players.

Without an authority check, a remote proxy entering the trigger locally could cause the same zone action to be invoked multiple times.

The check:

C#

player.HasStateAuthority

ensures that only the client controlling that player object triggers the zone logic.

ERPCZoneType

An enum can represent the available examples:

C#

public enum ERPCZoneType
{
    AllToAll,
    StateAuthorityToTarget,
    AllToMasterClient
}

The zone selects one type in the Inspector.

TryTriggerZone can then route to the corresponding RPC method.

EmoteDisplay

EmoteDisplay handles presentation only.

It can contain:

• a world-space canvas;
• emote images;
• camera-facing behavior;
• show and hide methods.

Example API:

C#

public void ShowEmote(int emoteId)
{
}

C#

public void HideEmote()
{
}

The networking code does not need to know how the visual UI is constructed.

Camera-Facing Emote UI

The world-space emote canvas can rotate toward the local camera.

This makes the emote readable from different viewing angles.

The behavior is presentation-only and does not need network synchronization.

Only the emote identifier and visibility state need to be synchronized.

EmoteRPCHandler

EmoteRPCHandler is a NetworkBehaviour attached to the player object.

It contains:

• RPC methods;
• Networked emote properties;
• timer logic;
• change detection;
• routing for each zone type.

Networked Emote Properties

The sample uses three Networked properties.

Conceptually:

C#

[Networked]
private int CurrentEmoteId { get; set; }

[Networked]
private NetworkBool EmoteToggle { get; set; }

[Networked]
private TickTimer EmoteTimer { get; set; }

Their responsibilities are:

Property	Purpose
CurrentEmoteId	Stores the active emote.
EmoteToggle	Forces a visual refresh even when the same emote is selected again.
EmoteTimer	Controls how long the emote remains visible.

Why Use a Toggle?

Suppose the current emote ID is 2.

If the player sends emote 2 again, the ID does not change.

A change detector watching only the emote ID would not detect a new action.

Toggling a separate Networked boolean ensures that every emote activation produces a replicated state change.

Conceptually:

C#

CurrentEmoteId = emoteId;
EmoteToggle = !EmoteToggle;

Emote Timer

A TickTimer stores the remaining synchronized emote duration.

Conceptually:

C#

EmoteTimer =
    TickTimer.CreateFromSeconds(
        Runner,
        EmoteDuration
    );

All peers can evaluate the same networked timer.

When the timer expires, the emote is hidden.

Using a Change Detector

The sample uses a Fusion Change Detector from Render.

When EmoteToggle changes:

1. Read CurrentEmoteId.
2. Call ShowEmote.
3. Display the selected emote.

When the timer is no longer running:

1. Call HideEmote.
2. Remove the temporary visual.

This keeps visual updates aligned with replicated Networked state.

Render and Presentation

Render is appropriate for presentation logic based on synchronized state.

It runs in the Unity rendering flow and can update:

• UI;
• visuals;
• animations;
• effects.

Do not use Render to author authoritative gameplay state.

State changes should occur from the correct authority in simulation or RPC-processing logic.

Setting the Emote State

The sample uses a helper method such as:

C#

private void SetEmote(int emoteId)
{
    if (!HasStateAuthority)
    {
        return;
    }

    CurrentEmoteId = emoteId;
    EmoteToggle = !EmoteToggle;

    EmoteTimer =
        TickTimer.CreateFromSeconds(
            Runner,
            EmoteDuration
        );
}

Only State Authority writes the player object’s Networked properties.

Example 1: All to All

The first zone demonstrates an RPC sent from any peer to all peers.

Attribute:

C#

[Rpc(RpcSources.All, RpcTargets.All)]
private void RPC_AllToAll(
    int emoteId,
    RpcInfo info = default)
{
}

Any peer can invoke it.

Every peer executes it.

Calling the All-to-All RPC

When the local player enters the zone:

C#

RPC_AllToAll(emoteId);

Each receiving peer can log the RPC metadata.

The sample then calls SetEmote.

Because SetEmote checks State Authority, only the player object’s authoritative peer updates the Networked properties.

The resulting state is then replicated to everyone.

Why Receive on All but Write on Authority?

The RPC demonstrates delivery to every peer.

However, Networked state still follows Fusion authority rules.

Receiving an RPC does not grant permission to modify a Networked property.

The RPC target and Networked state authority are separate concepts.

All-to-All Use Cases

This pattern can be useful for:

• room-wide emotes;
• temporary announcements;
• shared presentation effects;
• chat events;
• votes where every peer needs immediate notification;
• debugging distributed messages.

For persistent results, combine the RPC with Networked state.

Example 2: State Authority to Target

The second zone sends an RPC to one specific player.

The sending peer is the State Authority of its own player object.

The receiver is identified with a PlayerRef.

Targeted RPC Parameter

Add a parameter marked with [RpcTarget]:

C#

[Rpc(
    RpcSources.StateAuthority,
    RpcTargets.All)]
private void RPC_StateAuthToTarget(
    [RpcTarget] PlayerRef target,
    int emoteId,
    RpcInfo info = default)
{
}

Although the attribute declares the general target category required by the API, [RpcTarget] routes the RPC to the specified player.

Only that player executes the RPC.

Finding a Target Player

The sample finds another active player.

A possible workflow is:

1. Iterate through active players.
2. Exclude the local player.
3. Confirm that the target has a valid player object.
4. Retrieve the target’s EmoteRPCHandler.
5. Call the targeted RPC with the target PlayerRef.

Conceptually:

C#

foreach (PlayerRef player in Runner.ActivePlayers)
{
    if (player == Runner.LocalPlayer)
    {
        continue;
    }

    RPC_StateAuthToTarget(
        player,
        emoteId
    );

    break;
}

Production logic should define how a target is chosen rather than relying on the first available player.

Targeted RPC Use Cases

Targeted RPCs are useful for:

• private notifications;
• hit markers;
• individual quest updates;
• one-player UI effects;
• invitation responses;
• private emotes;
• moderation feedback;
• player-specific error messages.

Do not use a targeted RPC for persistent private state unless that state is also stored appropriately.

Targeted RPC State

A targeted RPC can produce a local-only visual on the recipient.

If the result needs to become shared state, the correct authority must update a Networked property.

Be explicit about whether the RPC represents:

• private presentation;
• a request to update state;
• a shared event delivered to one coordinator.

Example 3: All to Master Client

The third zone sends a request from any player to the State Authority of a scene object.

The scene object is:

MasterClientEmoteCounter

In Shared Mode, the Master Client has State Authority over the object.

Master Client Counter RPC

The counter RPC uses:

C#

[Rpc(
    RpcSources.All,
    RpcTargets.StateAuthority)]
private void RPC_IncrementCounter(
    RpcInfo info = default)
{
}

Any peer can send the request.

Only the object’s State Authority executes it.

Because the object is controlled by the Master Client, the Master Client processes the counter increment.

Updating the Counter

The counter stores its value in a Networked property:

C#

[Networked]
public int Count { get; set; }

Inside the RPC:

C#

Count++;

Only the State Authority executes this code.

Fusion then replicates the updated value to the other peers.

Displaying the Counter

The counter UI can update from:

• a Change Detector;
• Render;
• an OnChangedRender callback where appropriate;
• another presentation mechanism based on the Networked property.

The important part is that the count itself is synchronized state, not an RPC-only result.

All-to-Master Use Cases

This pattern is useful for shared coordination objects such as:

• vote counters;
• ready checks;
• lobby settings;
• shared match configuration;
• team score;
• round-start requests;
• simple authoritative room state.

The receiving object should validate requests before modifying state.

Master Client Considerations

The Master Client can change if the current Master Client leaves.

Shared Mode projects should account for:

• authority transfer;
• state continuity;
• scene object configuration;
• whether the counter object remains valid;
• how new State Authority resumes responsibility.

Networked properties preserve current state when authority changes according to the object’s Shared Mode lifecycle.

Authority Still Applies

An RPC target determines where the method executes.

It does not bypass authority rules for Networked properties.

For example:

• an all-to-all RPC executes everywhere;
• only State Authority can write authoritative state;
• a State Authority-targeted RPC executes on the object’s authority;
• a targeted player RPC executes only on the specified player.

Always separate these questions:

1. Who may send the message?
2. Who executes the method?
3. Who may modify the resulting Networked state?

Setting Up the Zones in Unity

Each zone requires:

• a collider configured as a trigger;
• the RPCZone script;
• a selected ERPCZoneType;
• an emote ID;
• visible geometry or labels for testing.

Example setup:

Zone	Type
Zone 1	AllToAll
Zone 2	StateAuthorityToTarget
Zone 3	AllToMasterClient

Use different materials, labels, or colors so each behavior is easy to identify while testing.

Player Enter and Exit Detection

The sample detects players through Unity trigger callbacks.

Entry detection begins the RPC example.

Exit detection can be used to:

• reset local zone state;
• allow retriggering;
• remove instructions;
• clear local UI;
• avoid repeatedly invoking an RPC while the player remains inside.

Authority filtering remains important for both entry and exit logic.

Preventing Repeated Trigger Calls

Depending on collider setup, a zone can receive multiple callbacks.

Production implementations can prevent duplicates with:

• a local active-player set;
• an activation cooldown;
• an entry-state boolean;
• explicit exit detection;
• collider filtering;
• authority checks.

The sample relies primarily on authority and clear trigger boundaries.

Testing All-to-All

Test with at least two peers.

1. Start the first Shared Mode client.
2. Start the second client.
3. Move the locally authoritative player into the All-to-All zone.
4. Confirm that all peers log the RPC.
5. Confirm that all peers display the emote.
6. Connect a late joiner.
7. Verify that the replicated Networked state determines what the late joiner sees.

Testing the Targeted RPC

1. Start at least two clients.
2. Enter the targeted zone.
3. Check which PlayerRef is selected.
4. Inspect console logs on each client.
5. Confirm that only the target executes the RPC.
6. Confirm that non-target peers do not receive the private effect.

With only one player, no valid alternate target may exist.

Testing the Master Client Counter

1. Start the Master Client.
2. Start another peer.
3. Enter the Master Client counter zone from each player.
4. Confirm that the RPC executes only on the counter object’s State Authority.
5. Confirm that the count increases once per valid request.
6. Verify that all peers display the same Networked count.
7. Test the behavior after a Master Client change where applicable.

Logging Sender and Receiver

Use RpcInfo and local runner data to log:

• sending peer;
• receiving peer;
• local player;
• object authority;
• RPC source.

This helps verify complex source and target combinations.

Remove or reduce verbose RPC logs in production builds where they are no longer needed.

Recommended RPC Workflow

1. Identify whether the action is an event or persistent state.
2. Define the allowed sender with RpcSources.
3. Define the receiver with RpcTargets.
4. Add [RpcTarget] for one-player delivery when required.
5. Use only supported parameter types.
6. Include RpcInfo when sender metadata is needed.
7. Validate the event on the receiving authority.
8. Update Networked properties for persistent results.
9. Render visuals from synchronized state.
10. Test with multiple peers and late joiners.

Choosing RPC or Networked State

Use an RPC when:

• the action happens once;
• timing matters;
• the message is transient;
• peers need an immediate notification;
• the event does not need to be reconstructed later.

Use a Networked property when:

• the value represents current state;
• late joiners need it;
• reconnecting players need it;
• the value must survive after the event;
• changes need to be observed consistently.

Use both when an event produces persistent state.

Key Concepts

Concept	Description
RPC	Network message that requests a method invocation.
RpcSources	Defines which peers may invoke an RPC.
RpcTargets	Defines which peers execute an RPC.
[RpcTarget]	Routes an RPC to one specific PlayerRef.
RpcInfo	Metadata about the RPC invocation.
Reliable channel	Delivers the RPC reliably and is the default.
Unreliable channel	Allows message loss for non-critical events.
InvokeLocal	Controls whether the caller executes the RPC locally.
TickAligned	Aligns RPC execution with the appropriate simulation tick.
State Authority	Peer allowed to write the object’s authoritative Networked state.
Networked property	Replicated persistent state available to current and late-joining peers.
Change Detector	Detects changes in replicated properties for presentation logic.
TickTimer	Network-compatible timer used for synchronized duration.
Master Client object	Shared Mode object whose State Authority belongs to the Master Client.

Best Practices

Use this checklist when implementing Fusion RPCs:

• Use RPCs for one-time events.
• Use Networked properties for persistent state.
• Combine RPCs with Networked properties when late joiners need the result.
• Restrict RpcSources to the minimum required sender set.
• Restrict RpcTargets to the intended receivers.
• Use targeted RPCs for private feedback.
• Validate requests on the receiving authority.
• Keep RPC payloads compact.
• Use Fusion-supported serializable parameter types.
• Use reliable delivery for important events.
• Use unreliable delivery only when message loss is acceptable.
• Respect Networked property authority after receiving an RPC.
• Check State Authority before trigger-based player actions.
• Use RpcInfo for diagnostics and sender validation.
• Keep presentation code separate from networking logic.
• Test reconnects and late joins.
• Test Master Client migration where relevant.

Common Pitfalls

Pitfall	Why It Is a Problem
Treating an RPC as stored state	Late joiners do not receive past RPC calls.
Updating a Networked property from every RPC receiver	Only the correct authority may write authoritative state.
Allowing RpcSources.All without validation	Any peer can submit the request.
Sending to RpcTargets.All unnecessarily	Every peer executes code that may only be needed by one receiver.
Forgetting [RpcTarget]	A targeted RPC may not route to the intended player.
Using unsupported parameter types	Fusion cannot serialize the RPC payload correctly.
Omitting RPC from the method name	Fusion does not recognize the method as a valid RPC.
Triggering zones from proxy player objects	The same gameplay action may execute multiple times.
Storing only a temporary visual locally	Reconnects and late joiners cannot reconstruct current state.
Updating UI directly inside all networking logic	Networking and presentation become tightly coupled.
Assuming Master Client authority never changes	Shared Mode must account for Master Client migration.
Using reliable RPCs for very frequent disposable effects	Can add unnecessary reliable traffic.

Summary

Fusion RPCs send one-time events between network peers.

RpcSources defines who may send an RPC, while RpcTargets defines where it executes. A parameter marked with [RpcTarget] routes the call to one specific player, and RpcInfo provides metadata about the invocation.

The tutorial demonstrates three patterns:

• any peer sending an emote event to all peers;
• State Authority sending a targeted event to one player;
• any peer sending a counter request to a Master Client-controlled object.

RPCs are not persistent state. When the outcome must remain synchronized or be available to late joiners, the receiving authority should store it in Networked properties.

The central rule is:

Use RPCs for events and Networked properties for state.

Last updated on 16/09/2026

Back to top