Udon Networking Decision Guide
Udon networking gets easier when you decide what kind of information you are moving before you write the script. A button press, a door state, a score, a player preference, and a saved inventory are different problems.
This guide gives you a practical decision path for VRChat world systems.
Start with the least networked option, then add syncing only when the world actually needs it.
- Ask whether the behavior can stay local.
- If other players need to react once, consider a network event.
- If other players need the current state, use synced variables and ownership deliberately.
Only the owner of a networked object can modify its synchronized Udon variables. If another player needs to change shared state, plan ownership transfer before serialization.
Quick Decision Table
| What you are building | Best first choice | Why |
|---|---|---|
| Personal UI panel | Local logic | Other players do not need the same UI state. |
| Local audio toggle | Local logic | Each player may want a different value. |
| Button that plays a temporary effect | Network event | The moment matters, but late joiners do not need history. |
| Door open or closed state | Synced variable | Late joiners should see the current state. |
| Scoreboard value | Synced variable | Everyone needs the current value. |
| Player preference that should survive visits | PlayerData | It belongs to the player and should be saved. |
| Per-player spawned item | PlayerObject | Each player needs their own object and optional persisted synced data. |
Local First
A surprising amount of world logic should stay local.
Good local-only examples:
- volume settings
- graphics or comfort toggles
- help panels
- tutorials or onboarding prompts
- personal UI state
- local-only sound previews
Keeping these local makes the world easier to reason about and avoids unnecessary bandwidth.
Network Events For Moments
Network events are useful when something should happen for other players now, but it does not need to be remembered as state.
Good event examples:
- play a short effect
- trigger a sound
- flash a UI notification
- start an animation moment
Do not use events as your only primary reference for a door, score, timer, game phase, or other stateful system. A late joiner may need the current state, not a past event.
Synced Variables For Shared State
Synced variables are the better fit when the value itself matters.
Use synced variables for:
- open or closed
- score
- selected option
- timer value
- game phase
- active round
- puzzle state
If your UdonBehaviour uses manual sync, call RequestSerialization() after the owner updates the synced values. If a different player needs to change those values, transfer ownership first.
Ownership Is Part Of The Design
Ownership decides who is allowed to update synced variables on a networked object.
Before you build a system, ask:
- Who starts as the owner?
- Who is allowed to take ownership?
- What happens if the owner leaves?
- Can two players fight over the same state?
- Does the UI explain who controls the system?
For many simple world systems, one object owner controls a shared state. For player-specific systems, PlayerObjects or local state may be cleaner.
Persistence Is A Different Question
Networking shares state inside an instance. Persistence saves data across visits.
Do not add persistence just because something is synced. Add persistence when a returning player should keep:
- settings
- inventory
- unlocks
- progress
- high scores
- save slots
Use VRChat Persistence, PlayerData, And PlayerObjects when the state should survive after the player leaves the world.
Common Problems
Help! Late joiners see the wrong state.
The state is probably only represented by events or local values. Store the current state in synced variables and make sure the owner serializes the update.
Help! My synced value changes locally but not for others.
Check object ownership, the synced variable setting, and whether manual sync code calls RequestSerialization() after the owner changes the value.
Help! My system uses too much networking.
Reduce update frequency, keep personal settings local, avoid syncing temporary values, and separate large saved data from fast-changing state.
Official References
The decision table is VRCreators practical guidance built from those official concepts. Exact platform behavior, supported types, and networking details should be checked in the official references before implementation.
Related Reading
- UdonSharp Guide
- VRChat Persistence, PlayerData, And PlayerObjects
- Networking Systems Prefabs
- VRChat Networking
Final Advice
The best Udon networking design is usually boring: local where possible, event-based for short moments, synced variables for state, ownership handled explicitly, and persistence only for data that truly needs to survive.
Choose The Smallest Networking Tool That Solves The Problem
Most broken Udon systems are not broken because networking is impossible. They are broken because temporary actions, persistent state, ownership, and saved data are mixed together.
Suggested Order
- Keep private UI local Menus, volume sliders, help panels, and local-only feedback usually do not need networking.
- Use events for moments Use network events for one-time actions, not state that late joiners must recover.
- Use synced variables for state Use synced variables when other players and late joiners need the current value.
Related VRCreators Guides
Common Questions
When should I use synced variables?
Use synced variables when a value represents current shared state that other players or late joiners need to see.
When should I use network events?
Use network events for one-time actions such as playing an effect or triggering an animation, not as the only record of persistent state.
