Skip to content

Sending Events Over the Network

Alpha Workflow

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

Network events let one machine trigger FSM behavior on another machine without manually rebuilding the transport logic in each FSM.

Common Uses

Use network events when you want to:

  • Trigger an FSM transition remotely
  • Tell spawned objects to play an effect or animation
  • Notify clients that something happened on the server
  • Forward a player action into authoritative game logic

Typical Workflow

  1. Identify the object that should receive the event.
  2. Make sure it is a valid network object with a NetworkObject and Netcode Object Proxy.
  3. Use the appropriate networking action to send an event.
  4. In the receiving FSM, handle that event like any other PlayMaker event.

This keeps the FSM mental model familiar: the networking layer transports the event, and the FSM still reacts through normal transitions.

When to Use Events Instead of Variable Sync

Use network events when the important thing is that something happened.

Examples:

  • TAKE_DAMAGE
  • OPEN_DOOR
  • START_MATCH
  • PLAY_HIT_FLASH

Use variable sync when the important thing is that a value stays consistent over time.

Examples:

  • Current health
  • Team score
  • Equipped weapon index
  • Match timer state

Design Tip

Try to keep event names gameplay-focused rather than transport-focused.

For example, prefer:

  • RESPAWN_PLAYER
  • LOCK_OBJECTIVE

Over names like:

  • SEND_RESPAWN_RPC
  • CLIENT_NOTIFY_LOCK

That makes your FSM easier to understand even if the networking implementation changes later.

Alpha Notes

Note

Exact event routing details, failure reporting, and some edge-case behavior may still change during alpha.

If an event workflow feels awkward to explain, that is useful product feedback.
It often means the action naming, targeting model, or inspector UX could be improved.

Next Steps