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:

“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

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

This is intentional:

  • It makes the authority seam visible (no hidden behaviour)
  • It keeps demos runnable out of the box
  • It shows where enforcement would live in a server-authoritative setup

In real projects, you typically replace these with your own authority implementations (server/host).

Seeing a binder in a demo does not mean the system is fail-closed — it means the boundary is being shown explicitly.

Two Authority Models (by Domain)

RevFramework uses different authority policies depending on system risk.

This is intentional.

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.

Authority binders must tolerate a null owner

  • ICraftingAuthority.CanMutate(...) may receive owner == null
  • This allows clean separation between player-scoped and system-level authority

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

Health — Opt-In Authority (Gameplay State)

Health is commonly 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 — an Inspector toggle on the component. It is serialized and private, so it is set in the Inspector or on a prefab, not from code

  • When OFF (default):

  • Mutations are allowed

  • When ON:

  • IHealthAuthority is required

  • Missing or denying binders block all mutations

Why

Blocking health by default would:

  • break single-player workflows
  • add friction to prototyping

So Health defaults to permissive, and becomes authoritative only when enabled.

Status Effects — Opt-In Authority (Gameplay Modifiers)

Status Effects follow the same model as Health.

How it works

  • StatusEffectController.requireAuthority controls enforcement

  • When OFF:

  • Effects run normally

  • When ON:

  • IStatusAuthority is required

  • Missing or denying binders block ticking and mutations

Why

Status Effects are often local gameplay features. They remain permissive until authority is explicitly required.

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 authority gate
  • Economy routes all mutations through:
Economy → IValueLedger → ICurrencyService

  • When using an authority-wrapped Currency service:

  • Missing or denying binders block all mutations

Why

Silent currency mutation is a security risk

Failing closed is safer than allowing unintended changes.

Other Systems

System Authority Model Rationale If your authority throws
Crafting Permissive (service-level) Jobs, queues, scheduling Propagates
Currency Fail-closed (when enabled) Exploit-prone Logged and converted to Unauthorized
Health Opt-in Local gameplay Propagates
Inventory Permissive Commonly local Propagates
Pickups Permissive World interaction Propagates
Status Effects Opt-in Matches Health Propagates
Loot None — by design Rolling mutates nothing —

There are seven I…Authority interfaces across those six systems: Crafting carries two, the service-level ICraftingAuthority and a bench-local ICraftingBenchAuthority on CraftingWorkbench2D/3D that answers before the service gate is reached. Economy, Save and Attributes have none of their own — Economy delegates every leg to the Currency and Inventory services it is handed, and each save participant either inherits its target system's gate or deliberately bypasses it (below).

A throwing authority is always refusal-before-mutation, and only Currency converts it

In every system the authority is the first call on the gated path, so an exception leaves before anything has changed. What differs is what the caller receives. Currency catches it, logs it with Debug.LogException and returns CurOpCode.Unauthorized — "a gate that cannot answer is a gate that denies". The other five let it propagate out of the mutation, with no event, no error property and no warning.

Neither is wrong; the asymmetry is undocumented rather than accidental, and this table is where it is written down. If you implement an authority, the safe assumption is that throwing is not an escape hatch: it refuses the operation, loudly, in a way your call site has to handle.

Two systems can disagree about one action, and both be right

A status approved by IStatusAuthority ticks damage into a HealthSystem whose own IHealthAuthority refuses it. Each system enforces its own gate over its own state, which is the intended layering — but the consequence is worth knowing: the status keeps counting down while delivering nothing, its FX and lifecycle events fire normally, and the refused tick is silent to the status. Nothing reconciles the two.

The same shape applies to Economy: a Buy is a money leg governed by Currency's model and an item leg governed by Inventory's, and no authority sees the transaction as a unit. Economy compensates best-effort when one half refuses, and the compensation is itself gated.

Restore paths: three rewind, two ask

Currency and Status Effects restore through their systems' gated APIs, so a save load can be refused by an authority and is reported when it is. Health (RestoreSnapshot), Inventory (InventorySnapshots.ApplyJson) and Crafting (RestoreJobs) write directly and consult nobody — a load is a rewind rather than a request, and a gate that can refuse half of one leaves the world inconsistent. Drive those from a trusted load path. Attributes has no seam at all.

So "blocks all mutations" above means the gated mutation paths: for Health, damage, heal, kill, revive and the setters — not RestoreSnapshot.

Why Loot has no authority model at all

LootRoller.Roll(table, rng) is a pure function: it takes data, returns data, and touches no scene, no owner and no other system. There is nothing to gate, so there is no gate.

The authority question for loot is answered at the delivery boundary instead. An award only becomes state when an integration hands it to Inventory, Currency or Health — and each of those applies its own model, listed above. So a fail-closed Currency stays fail-closed when the money arrives as loot.

The practical consequence for a networked game: decide loot on the authoritative peer and deliver there. Rolling on a client is harmless — it changes nothing — but a client that also delivers is a client writing to its own wallet, and that is Currency's rule to enforce, not Loot's.

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
  • handle ownership and server logic

Netcode Integration

RevFramework is designed to integrate cleanly with common networking approaches:

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

No specific netcode implementation is included.

Use your networking layer to:

  • call mutations from an authoritative context
  • replicate results to clients
  • handle ownership and server logic

Final Word

RevFramework is a runtime framework, not a multiplayer solution.

If you want:

  • control
  • explicit rules
  • predictable behaviour

This approach will feel natural.

If you want:

  • drop-in multiplayer
  • prefab kits
  • automatic replication

This is not the right tool.

Authority is a contract, not a feature

RevFramework enforces the rules you define — nothing more, nothing less.