Netcode Samples (Example Only)¶

⚠️ Important Disclaimer
These files are illustrative only. They show the minimum authority‑gating pattern for popular netcode stacks.
They are not a drop‑in multiplayer solution. You are responsible for replication, prediction, reconciliation, and game‑specific rules.

HealthSystem is netcode‑agnostic. It does not depend on NGO, Mirror, or Fusion.

What these samples cover¶

Authority gating via IHealthAuthority binders (per stack).
Server‑authoritative damage flow using a minimal “ServerProxy” per stack.
Where to place the binder (same GO as HealthSystem is recommended).

They do not cover: replication of health values, prediction/rollback, reconciliation, or your game’s damage rules.
Those are up to your chosen stack and architecture.

Folder layout¶

Demos/
  NetcodeSamples/
    NGO/
      HealthAuthorityBinder_NGO.cs
      NgoHealthServerProxy.cs
    Mirror/
      HealthAuthorityBinder_Mirror.cs
      MirrorHealthServerProxy.cs
    Fusion/
      HealthAuthorityBinder_Fusion.cs
      FusionHealthServerProxy.cs

Each folder is self‑contained and can be copied into a project that already uses that netcode.

Enabling the samples (Scripting Define Symbols)¶

To compile a stack’s sample code, add the corresponding define:

NGO: REV_USE_NGO
Mirror: REV_USE_MIRROR
Fusion: REV_USE_FUSION

Unity: Project Settings → Player → Other Settings → Scripting Define Symbols (per platform).

If a define is missing, the sample scripts for that stack won’t compile by design.

Authority quick start¶

Single‑player / local testing - Leave HealthSystem.requireAuthority = OFF. Done.

Authoritative multiplayer 1. Turn ON requireAuthority on each HealthSystem you intend to mutate via netcode. 2. Add exactly one binder that implements IHealthAuthority to the same GameObject: - NGO: HealthAuthorityBinder_NGO - Mirror: HealthAuthorityBinder_Mirror - Fusion: HealthAuthorityBinder_Fusion 3. (Optional) For legacy call‑sites, the binder assigns health.HasAuthority = () => HasAuthority(health);

If requireAuthority is ON and no binder is found, mutations will be denied and a warning will be logged once.

Typical flow (all stacks)¶

Client requests damage via an RPC to Server/StateAuthority.
Server validates authority using your IHealthAuthority binder.
Server applies damage via HealthSystem.TryTakeDamage(in ctx).
(Optional) Server sends a lightweight RPC to clients for UI/VFX.
Replication of health values is handled by your stack (SyncVar/NetworkVariable/Networked).

Per‑stack notes¶

NGO (Netcode for GameObjects)¶

Use a NetworkVariable<int> (or your preferred pattern) to replicate current/max health.
Server RPC to request damage; Client RPC for feedback is optional.
Binder: HealthAuthorityBinder_NGO (Owner=ON, Server=ON is a sensible default).

Mirror¶

Use [SyncVar] or custom messages for replication.
Command from client to server for damage; ClientRpc for feedback is optional.
Binder: HealthAuthorityBinder_Mirror (hasAuthority or server).

Fusion¶

Use [Networked] properties for replication or server‑broadcast RPCs.
RpcSources.InputAuthority → RpcTargets.StateAuthority for damage requests.
Binder: HealthAuthorityBinder_Fusion (InputAuthority or StateAuthority).

Troubleshooting¶

“No authority” warnings — Turn requireAuthority OFF (SP) or add the correct binder (MP).
No replication on clients — You must replicate yourself (SyncVar/NetworkVariable/Networked property).
Prediction/lag comp — Out of scope for these samples; follow your stack’s docs.
Compilation errors — Ensure the right Scripting Define Symbol is set for the stack you’re using.

Support stance¶

These files are provided as keys and illustrative examples only.
RevFramework does not provide replication, prediction, rollback, or reconciliation.

In single-player: use the local binder or disable authority checks.
In multiplayer: you are responsible for wiring replication and gameplay rules in your chosen netcode stack.

Multiplayer support is explicitly out of scope for RevFramework.