Skip to content

Authority in RevFramework

RevFramework does not implement networking, replication, prediction, rollback, or reconciliation.

Instead, it provides authority hooks — clean seams where you decide who is allowed to mutate state, using whatever netcode or architecture your project requires.

We give you the keys.
You handle the authority, networking, and integration.

What “Authority” Means Here

In RevFramework, authority answers one question only:

“Is this caller allowed to mutate state right now?”

Authority: - Does not replicate state
- Does not synchronize clients
- Does not perform prediction or rollback

It simply gates mutations.

Demo Scenes & Binders (Why You’ll Sometimes See Them)

Some sample scenes include permissive authority binders even when the system does not require authority by default.

This is intentional:

  • It makes the system’s authority seam visible (no hidden behaviour).
  • It keeps demos runnable out of the box while still showing where enforcement would live in a server-authoritative setup.
  • In multiplayer projects, you typically replace permissive binders with your own authority implementations (server/host).

Seeing a binder in a demo does not mean the system is “always fail-closed” — it means the demo is being explicit about the authority boundary.

Two Authority Models (by Domain)

RevFramework intentionally uses different authority policies depending on the risk profile of the system.

This is not drift — it’s domain-specific design.

🛠️ Crafting — Service-Level Authority (Jobs & Scheduling)

Crafting authority may be evaluated without an owner context.

Some crafting mutations (job scheduling, station caps, queue control) are service-level operations rather than per-entity actions.

For this reason: - ICraftingAuthority.CanMutate(...) may receive owner == null - Authority binders must tolerate a null owner - This allows clean separation between player-scoped authority and system-level authority.

This is expected behaviour and not an error condition.

If no ICraftingAuthority is assigned to the service, Crafting runs in permissive (single-player) mode by design.

🩸 Health — Opt-In Authority (Gameplay State)

Health is frequently used in: - single-player games - prototypes - AI simulations - editor tools

Because of this, Health uses opt-in authority.

How it works

  • HealthSystem.requireAuthority controls enforcement
  • When OFF (default):
  • Health mutations are allowed
  • Binders are ignored
  • When ON:
  • Health resolves IHealthAuthority
  • Missing or denying binders block all mutations

Why

Blocking health by default would: - break single-player workflows - add friction to prototyping - confuse non-multiplayer users

So Health defaults to permissive, and becomes authoritative only when you ask for it.

✨ Status Effects — Opt-In Authority (Gameplay Modifiers)

Status Effects are frequently used for: - buffs and debuffs - damage-over-time / heal-over-time - crowd control - local gameplay effects - editor and demo tooling

For this reason, Status Effects use opt-in authority, matching the Health system.

How it works

  • StatusEffectController.requireAuthority controls enforcement
  • When OFF (default):
  • Status ticks and mutations are allowed
  • Authority binders are ignored
  • When ON:
  • Status resolves IStatusAuthority
  • Missing or denying binders block all mutations and ticking

Why

Making Status Effects authoritative by default would: - break single-player workflows - complicate prototyping - add unnecessary friction for local gameplay

So Status Effects default to permissive, and become authoritative only when explicitly enabled — exactly like Health.

💰 Currency & Economy — Fail-Closed Authority (Transactional State)

Currency and Economy represent high-risk state: - purchases - shops - rewards - exploits

For these systems, authority is fail-closed when enabled.

How it works

  • Currency is the authoritative gate.
  • Economy does not implement a separate authority interface.
  • All Economy mutations flow through:
Economy → IValueLedger → ICurrencyService
  • When using an authority-wrapped Currency service stack:
  • Missing or denying binders block all Economy mutations
  • This prevents accidental exploits when authority is forgotten.

Why

Silent currency mutation is a security bug. Failing closed is safer than “it still worked”.

📦 Other Systems

System Authority Model Rationale
Crafting Permissive unless explicitly bound (service-level) Jobs, queues, scheduler & offline logic
Currency Fail-closed when wrapped Exploit-prone
Health Opt-in Commonly local gameplay state
Inventory Permissive by default Commonly local; authority shown in demos for transparency
Pickups Permissive by default World interaction
Status Effects Opt-in Matches Health; enforced only when explicitly enabled

What RevFramework Does NOT Provide

To be explicit:

  • ❌ Networking
  • ❌ Replication
  • ❌ Client prediction
  • ❌ Rollback / reconciliation
  • ❌ Netcode SDK integration

You are expected to: - call mutations from an authoritative context - replicate results using your netcode of choice - resolve ownership/server logic yourself

Netcode Integration

RevFramework has been designed to integrate cleanly with:

  • Unity Netcode for GameObjects (NGO)
  • Mirror
  • Fusion
  • Custom RPC layers

See Samples → NetcodeSamples for illustrative patterns.

These are teaching examples, not production netcode.

Final Word

RevFramework is a runtime framework, not a multiplayer solution.

If you want: - full control - explicit rules - predictable behaviour

This approach will feel familiar.

If you want: - drop-in multiplayer - prefab kits - magic replication

This is not the right tool.

Authority is a contract, not a feature.
RevFramework enforces the authority rules you define — nothing more, nothing less.