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.

For this reason:

  • ICraftingAuthority.CanMutate(...) may receive owner == null
  • Authority binders must tolerate a null owner
  • 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

  • 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
Crafting Permissive (service-level) Jobs, queues, scheduling
Currency Fail-closed (when enabled) Exploit-prone
Health Opt-in Local gameplay
Inventory Permissive Commonly local
Pickups Permissive World interaction
Status Effects Opt-in Matches Health

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.