Skip to content

Syncing Global Variables

Alpha Workflow

Treat this as the current recommended setup path, not a final compatibility or production-readiness statement.

Info

Variable syncing is available in beta 83+

Use Network Global Variable Sync when the data should not belong to one specific networked object.

Best Fit

Global sync is often a good fit for values such as:

  • Match state
  • Shared round timer
  • Selected map name
  • Team score
  • Global feature flags used by multiple FSMs

If the value conceptually belongs to a single spawned object, prefer Syncing FSM Variables instead.

Typical Setup

  1. Add a Network Global Variable Sync component where your project manages shared network state.
  2. Choose the global variables that should replicate.
  3. Choose sync direction, sync mode, and initial sync behavior.
  4. Use FSMs to read or react to those global variables normally.

The key idea is that PlayMaker globals remain your shared state interface, while the networking component handles replication.

When to Prefer Global Sync

Prefer global sync when:

  • Multiple FSMs need the same replicated value
  • The value should outlive one specific object instance
  • The value represents session-level state rather than object-level state

Keep Ownership Clear

Even though the variable is global, the write rules still matter.

Decide early:

  • Is the server authoritative?
  • Can the owning player write the value?
  • Should clients only observe it?

Those decisions help avoid confusing bugs where a value appears to "snap back" because a different machine is the real source of truth.

Alpha Notes

Note

Internal binding details and some late-join behavior are still expected to evolve during alpha.

For early testing, start with a small set of obvious values and confirm:

  • The right side writes the value
  • Other peers receive the update
  • New joins get the state you expect

Next Steps