Game fog of war explained

What fog of war is — and what it is not

Fog of war is information asymmetry enforced by the engine, not a visual effect layered on top of a fully known world. The server (or authoritative simulation) tracks per-player visibility and only sends entity state the player is allowed to know. A rookie mistake is rendering fog as a shader while still broadcasting enemy unit positions over the network — competitive players will read memory or packet dumps and the fog becomes cosmetic only.

Do not confuse fog with unrelated darkness mechanics. A horror game that limits the player's torch radius is using local lighting, not map-level fog. A turn-based tactics game that hides enemy intents until engagement is using perception on individual agents, not global shroud. Fog of war operates at the map and player level: which tiles, units, and structures exist in each visibility state for each competing side.

The three visibility states

Most RTS and 4X engines implement a bitmask or byte per map cell per player (or per team):

• Unexplored (shroud) — the player has never had vision here. Terrain topology, resources, and enemy bases are unknown. UI shows black or a patterned overlay.
• Explored (memory) — the player scouted this area before but has no current vision. Static terrain and last-known building positions may display; moving units are hidden or shown as stale ghosts depending on design.
• Visible — at least one friendly vision source currently covers this cell. Live unit positions, health bars, and animations update in real time.

Some games collapse explored and unexplored (binary fog: you either see it now or you do not). Others persist explored memory for the entire match but wipe it between missions. Pick the model that matches your genre: persistent memory rewards scouting in long 4X campaigns; binary fog suits fast MOBA matches where map knowledge is assumed after a few minutes.

Vision sources and radii

Visibility updates when vision providers move or die. Common providers include mobile units, static watchtowers, airborne scouts, ward items, and ability-granted true sight. Each provider defines:

• Vision radius — Euclidean or Manhattan distance in world units or grid cells.
• Height bonus — elevated cliffs may see farther into valleys (height differential adds effective range).
• Vision type — ground-only, flying (ignores terrain elevation blockers), or true sight (reveals invisible units).
• Team affiliation — vision usually merges across allies into one team mask.

When a scout enters a forest, designers often reduce its radius to represent canopy cover — the same geometric circle is not always fair in every biome. Document these modifiers in data tables so balance patches do not require code changes.

Shared team vision

In team-based modes, each player's units contribute to a union mask for the whole team. Player A's scout and Player B's army combine; either player sees everything the team sees. Implementation: compute per-player masks only if you need replay spectators or cheat detection, then OR them into teamVision[teamId] each tick. Shared vision removes redundant computation but introduces design questions: should a betraying ally's vision feed the team? Usually yes unless you implement a hard faction split mid-match.

Line of sight and blocking geometry

A circular vision radius is only the first pass. Real fog systems apply line-of-sight (LOS) blocking: hills, walls, and forests stop vision even if the target cell is within radius. The classic algorithm on a grid:

1. For each cell within radius of the vision source, cast a ray from source center to cell center.
2. Walk the ray through grid cells (Bresenham or supercover line algorithm).
3. Stop when a cell marked blocksVision = true is hit; cells beyond remain hidden unless reached by another ray.

On large maps, naive per-cell raycasting every frame is expensive. Optimizations include:

• Incremental updates — recompute only when vision providers move or terrain changes, not every render frame.
• Shadow-casting — recursive division algorithms (used in roguelikes) mark visible sectors in O(n) cells for a single source.
• Precomputed heightfields — for fixed maps, bake visibility from key vantage points offline.
• Low-res fog grid — simulate fog at 1/4 map resolution, upsample for rendering.

Elevation adds a vertical angle check: a unit on a hill sees over a low wall if the wall's top is below the sight line. Simplify with tiered height levels (0–3) rather than continuous geometry unless your game is simulation-heavy.

Rendering fog on screen and minimap

Simulation data (bitmasks) and presentation (what the player sees) should stay decoupled. Common rendering approaches:

• Texture mask overlay — a GPU texture stores explored/visible per cell; a fragment shader lerps between shroud, desaturated memory, and live color.
• Per-object visibility flag — units outside visible cells are not drawn or are replaced with last-known ghost sprites.
• Minimap duplicate — the minimap uses the same mask at lower resolution; keep it in sync or players distrust both.

Memory fog (explored but not visible) is a design choice with competitive implications. Showing last-known building positions teaches players to notice when a base disappears from memory — a subtle cue that the enemy relocated. Hiding all dynamic objects in memory fog forces active re-scouting and punishes passive players. Neither is wrong; mixed approaches (buildings persist, units do not) are common in RTS titles.

Color-blind accessibility: do not rely on red/green alone to distinguish visible from memory. Use brightness, pattern, or border strokes — the same guidance in game accessibility applies to fog overlays.

Multiplayer authority and cheating

In competitive multiplayer, fog must be server-authoritative. The server computes visibility per team and filters outbound messages:

• Do not replicate enemy unit transforms to clients that lack vision.
• Send fog events (unit entered vision, building destroyed) instead of continuous hidden state.
• Validate client requests — a move order into unexplored territory may be legal, but an attack command on an unseen unit should be rejected or treated as a move-to-last-known-position.

Replays and spectators need a superset view: store the full simulation and a per-player fog mask so observers can toggle player POV. The patterns overlap with netcode interest management — fog is essentially a hard interest filter keyed on team vision rather than distance alone.

Anti-cheat note: clients with fog lifted for debugging must compile that code out of shipping builds. Even hidden console commands leak in beta builds and destroy ladder integrity.

Fog in non-RTS genres

The same visibility stack appears outside traditional RTS:

• MOBAs — brush and ward vision with short radii; binary visible/hidden for enemies; no persistent map memory.
• 4X turn-based — fog updates per turn; explored memory persists across centuries of in-game time; diplomacy may share vision treaties.
• Tactics (XCOM-style) — per-soldier sight cones on a tactical grid; overhead fog between rooms; closely related to AI perception but turn-scoped.
• Battle royale — no classic fog; circle shrink is a different boundary — but audio and render distance perform a similar information limit.

When porting a fog system between genres, the visibility states stay constant; only update frequency and persistence rules change.

Level design and fog interplay

Fog is not only engineering — it shapes level design. Chokepoints that block LOS create scout paths; open plains reward mobile spotters; high ground becomes strategically valuable because vision radii expand. Designers should mark intended scout routes and blind zones on the same overlay used for encounter pacing. If the fog system hides a critical objective until mid-game, playtesters should discover it through natural exploration, not accident.

Wards, scan abilities, and temporary reveals are balance levers. Track how often pro players break fog in the first five minutes; if vision uptime approaches 100%, the fog system stops mattering and you have wasted CPU on decorative shading.

Production checklist

1. Define visibility states (binary vs three-state) and persistence rules per game mode.
2. Implement server-side team vision masks before networking any unit state.
3. Specify vision providers in data: radius, height tier, flying, true sight, team share.
4. Choose LOS algorithm for map size; profile full recompute vs incremental on worst-case unit count.
5. Decouple simulation bitmask from render shader; support minimap and main view from one source.
6. Decide memory-fog rules for buildings, units, and resources independently.
7. Filter replication and commands through visibility; add automated tests for hidden-unit leaks.
8. Ship color-blind-safe fog overlays and optional high-contrast fog mode.
9. Instrument scout uptime and ward placement in analytics to validate design intent.
10. Strip debug reveal tools from release builds; verify with packet capture on LAN.

Key takeaways

• Fog is information control — simulation and networking must enforce it, not just the renderer.
• Three states — unexplored, explored memory, and currently visible cover most strategy games.
• LOS matters — radius alone is insufficient when terrain blocks sight; optimize raycasts for your map scale.
• Team vision is a union mask — compute once per team for performance and consistent ally behavior.
• Multiplayer requires server filtering — hidden enemies must not exist in client memory or packets.

Related reading

• Game AI perception explained — per-agent sight cones and stealth detection, the unit-level cousin of map fog
• Game level design explained — chokepoints, high ground, and exploration pacing that fog systems expose
• Game networking and multiplayer netcode explained — authority, replication, and interest management for competitive modes
• Game UI and HUD design explained — minimap readability and overlay conventions players expect