Networking

Fog of War separates authoritative entity relevance from client terrain presentation. The server runs target visibility and withholds hidden network state. Each client independently renders fog from the allied source state it is permitted to receive. Textures, visibility grids, and explored payloads are never synchronized during play.

Authoritative model

On the server:

1. authenticate each connection before assigning its FogObserverSettings;
2. register authoritative sources, targets, obstacles, concealment volumes, and modifiers;
3. step the server FogWorld at the chosen gameplay tick rate;
4. apply FogVisibilityDecision.IsNetworkRelevant or GetInterestDeltas to the transport's replication set;
5. apply EvaluateAction independently to targeting and combat requests.

On each client, replicate only allowed entity state and compact allied source state. Register those sources in a local presentation FogWorld, set ObserverMask for the selected team, and let the client generate its own textures. The source identity, faction, active state, archetype ID, and normal movement replication are sufficient for most projects.

An observer without authenticated configuration must see no tracked enemy targets. Source and target owner IDs must come from server connection or network-object ownership, not from client-provided masks. Friendly owned objects and the server itself can remain relevant by explicit policy.

Netcode for GameObjects

Install a Unity 6-compatible Netcode for GameObjects package before importing Netcode for GameObjects Integration.

FogNgoInterestManager owns a server simulation and uses per-connection NetworkShow and NetworkHide. FogNgoObserver registers authenticated observer state. FogNgoVisibilityTarget starts hidden from unconfigured observers. FogNetworkVisionSource synchronizes only server-owned team and active state for client presentation; the project's NetworkTransform or movement system supplies position.

The sample is a MOBA-style current-vision arena with a Team A player, a server-authoritative Team B enemy, wall-blocked LOS, and instant local observer switching. Its sphere player and capsule enemy use CharacterController.Move, so their patrol and manual movement collide with the same wall geometry that blocks sight. It also covers host plus two clients, distinct teams, late join, team swap, death, respawn, despawn, disconnect, reconnect, and independent client textures. Its owner-request demo switch exists only for interactive buttons and is denied by default. In production, call the authoritative setters only after validating the game rule on the server.

Netcode for Entities

Import Netcode for Entities Integration at any time. The sample assembly remains disabled when DOTS is absent, so importing it cannot break project compilation. Kiwi then offers to install the editor-compatible official com.unity.netcode package and its transitive Entities dependency through Unity Package Manager. Choose Keep Disabled to defer installation, or use Tools > Kiwi Studios > Fog of War > Install Netcode for Entities Dependencies later. The assembly enables itself after both packages resolve.

Use one Unity netcode stack per project with the currently validated package releases. Netcode for GameObjects declares Unity.Netcode.Editor, while Netcode for Entities declares Unity.NetCode.Editor; Unity treats those names as duplicate assembly identities. The Kiwi installer detects NGO and refuses to install Entities into the same project, leaving the imported sample disabled instead. This is an official-package coexistence boundary rather than a Kiwi runtime restriction. Use separate projects to evaluate both adapters, or recheck the exact Unity packages before replacing one transport with the other.

FogNfeInterestSystem is server-only and drives GhostRelevancy. Add authenticated FogNfeObserverData to each connection entity; until it exists, tracked fog targets fail closed. Add the source, target, obstacle, or concealment authoring component to the corresponding server ghost or scene object. Source and target ownership derive from GhostOwner, while observer ownership derives from NetworkId.

Both SetIsIrrelevant and SetIsRelevant modes are supported. The integration tracks only the connection and ghost pairs it owns so it does not remove another relevancy system's entries. Deterministically order other systems that can write the same pair.

Custom transports

The core has no networking-package dependency. Use one authoritative FogObserverHandle per connection and one FogTargetHandle per replicated target. Reuse a caller-owned list with GetInterestDeltas; apply each reveal or hide to the transport. A full query is also available for late join and recovery. Generation-safe handles reject stale pooled identities.

Do not use the client's terrain texture or local query as a security boundary. If the transport sends hidden coordinates before the server applies relevance, no visual effect can remove them from client memory. See Competitive vision architecture for concealment and action rules.