Skip to content

Ownership and Server-Only FSMs

Alpha Workflow

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

Networking becomes much easier to reason about when each FSM has a clear execution role.

A Simple Role Model

When designing an FSM, ask:

  • Should this logic run on the server only?
  • Should it run only on the owning client?
  • Should it run on every peer but read shared replicated state?

Making that decision early is usually more important than any single action setting.

Server-Only FSMs

Use server-only FSMs for logic such as:

  • Validating gameplay actions
  • Spawning and despawning authoritative objects
  • Updating authoritative match state
  • Deciding whether a client request is allowed

This is often the clearest place to put rules that should not depend on a client being honest.

Ownership Checks

Ownership checks help answer whether the current machine is allowed to drive an object or a write.

Typical uses include:

  • Only let the owning player send a local input event
  • Only let the server apply a final health change
  • Only let the owner update cosmetic state for their own avatar

A Practical Pattern

A common alpha-friendly pattern is:

  1. Client collects local input.
  2. Client sends a network event or request.
  3. Server validates and updates authoritative state.
  4. Synced variables or server-driven events inform everyone else.

This keeps trust boundaries easier to explain and test.

Be Careful With Client-to-Server Writes

Authority Expectations May Evolve

Security and authority expectations for client-to-server writes are not final in this alpha. Be cautious about assuming that any client-originated write is safe by default.

If you are unsure, prefer:

  • Server-authored values
  • Server-side validation
  • Explicit ownership checks before write actions

Next Steps