Implement Fog Of War
Meng ToCommunityCreated by Meng To
- Skill
- Tool integration
- Software development
- MIT
- No issues found
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
This skill provides a structured approach to building a fog of war system in Three.js. It emphasizes a clear separation between the simulation layer, which handles deterministic perception and obstacle intersection, and the presentation layer, which uses a shader-based overlay to render radial and wall-aware fog. The system relies on a fixed-size lookup texture to store angular visibility data, ensuring that gameplay logic remains decoupled from visual effects.
What it does
- Defines a deterministic perception model for player and enemy vision ranges.
- Calculates obstacle-aware line of sight using vertical and horizontal footprint intersections.
- Generates a 1D lookup texture to store angular visibility distances.
- Renders a soft fog overlay using a single full-screen shader material.
- Integrates visibility state with gameplay mechanics like targeting and enemy rendering.
- Provides guidelines for managing fog lifecycle, telemetry, and state transitions.
When to use it
- When implementing visibility systems for orthographic or isometric action games in Three.js.
- When you need to synchronize enemy perception with visual fog of war.
- When building a system that requires consistent visibility rules across different gameplay states.
- When you need to optimize visibility calculations for both desktop and mobile environments.
Advantages
- Maintains a single source of truth for both gameplay logic and visual presentation.
- Prevents visual artifacts like spokes or seams through angular smoothing.
- Ensures consistent behavior by separating simulation presence from rendering visibility.
- Uses a bounded architecture that avoids unnecessary render targets or complex scene graph modifications.
Usage examples
- “How do I define a new sight blocker for the fog of war system?”
- You define a SightObstacle object with an ID, XZ coordinates, radius, and vertical span, then add it to the active obstacle collection used by the perception system.
- “How should I handle enemy visibility in the fog?”
- Use the perception result to toggle the enemy's presentation layer visibility while keeping the actor root active for simulation purposes.
Install
Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/mengto/implement-fog-of-war/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip implement-fog-of-war.zip -d .agents/skills
Documentation by Meng To
Implement Fog of War
Build fog of war as a shared perception system with a restrained presentation layer.
Preserve the architecture
Keep these responsibilities separate:
Let deterministic CPU perception own ranges, obstacle intersections, and gameplay visibility.
Encode the player's angular visible distances into one fixed-size lookup texture.
Let one full-screen shader turn that lookup into soft radial and wall-aware fog.
Let gameplay consume perception results directly; never infer combat truth from fog pixels.
Read mechanics.md before implementing or changing the algorithm. It records the proven obstacle model, shader composition, calibrated values, state rules, enemy behavior, lighting constraints, and telemetry.
Inspect before editing
Locate the authoritative player position, camera, obstacles, scene lifecycle, frame loop, targeting, enemy perception, and render layers.
Confirm the gameplay ground model. The proven corner-unprojection method assumes a locally horizontal plane; use authoritative surface or terrain reconstruction when elevation varies across the visible area.
Find existing scene fog, post-processing, renderer creation, review modes, menus, captures, transitions, and disposal paths.
Read the current tests and recent fog/perception commits before changing constants or ownership.
Confirm whether obstacle state changes at runtime. Reuse the same active obstacle collection used by navigation or collision when its geometry is suitable for sight.
Check the working tree early and preserve unrelated changes.
Implement in dependency order
1. Define perception truth
Represent each sight blocker with a stable footprint, vertical span, and active state.
Intersect a 3D sight segment or ray with both the horizontal footprint and vertical span.
Ignore inactive blockers and cover below the eye-to-target sight line.
Expose:
point-to-point perception for enemies, targeting, and attacks;
a deterministic angular distance fill for the fog lookup.
Use explicit player and enemy ranges. Allow them to differ when the encounter design needs enemies to acquire beyond the player's reveal edge.
2. Build the visibility lookup
Allocate the distance array, byte pixels, and data texture once.
Cast a fixed number of evenly spaced horizontal rays around the player's eye point.
Normalize hit distances by the player vision radius and quantize them into a one-row red-channel texture.
Use linear filtering, horizontal repeat wrapping, no mipmaps, and a bounded mobile/desktop ray budget.
Refresh after meaningful player motion or a short maximum interval. Do not allocate in the frame loop.
3. Render one soft overlay
Use one clip-space plane and one transparent shader material.
Reconstruct each fragment's ground-plane position from the four camera-corner intersections.
Combine:
a clear inner radius and soft outer radial falloff;
a feathered wall boundary sampled from the angular lookup.
Smooth obstacle visibility across neighboring angles. Weight wall fog below the outer radial fog so blockers read as atmosphere, not opaque wedges.
Combine radial and obstacle fog with
max, then cap final opacity.Disable depth test, depth write, and tone mapping; render after the world.
Do not introduce a second renderer, render target, composer, or per-ray meshes.
4. Integrate gameplay
Keep simulation presence separate from presentation visibility.
Hide unrevealed enemy renderables through layers or a presentation-only mechanism; do not toggle the actor root if root visibility also controls lifecycle or simulation.
Exclude unrevealed enemies from target lock, aim selection, nearest-target search, HUD counts, and player hit eligibility.
Hide telegraphs that would leak an unseen enemy.
Let enemy acquisition and attacks use their own range plus the same line-of-sight truth.
Clear an active target lock as soon as perception invalidates it.
Cache perception within a simulation phase and refresh after movement when downstream systems need current positions.
5. Integrate state and lifecycle
Enable fog only during active gameplay.
Disable it for menus, inventory, review/capture modes, paused or non-playing states, and stage transitions unless the product explicitly requires otherwise.
Disable it before any early-render branch so a previous frame cannot leak into another state.
Keep atmospheric scene fog separate from fog of war.
Dispose the overlay geometry, material, and lookup texture on teardown.
Publish compact telemetry for ray budget, enabled state, ranges, visible enemies, target visibility, line of sight, and measured distance.
Tune in the right order
Validate obstacle geometry and eye height.
Validate player and enemy ranges.
Set the fully clear inner radius.
Set the outer radial falloff and maximum opacity.
Set wall-edge softness.
Add angular smoothing until spokes disappear.
Reduce obstacle darkness until walls feel like occlusion rather than black rays.
Adjust ray budgets only after visual correctness and measured performance.
Do not hide bad obstacle data with extra blur. Do not make the entire scene darker to compensate for weak visibility boundaries.
Validate
Read validation.md before claiming completion. Run:
pure perception and opacity tests;
structural render-budget contracts;
integration tests for targeting, layers, lighting, and state;
project lint and build;
real desktop and mobile browser checks in the Codex browser.
Use normal gameplay for visual verification when review modes intentionally disable fog. Judge motion, camera movement, wall edges, gates, seams, and menu transitions—not only a still frame.
Protect the proven qualities
Keep the inner play area readable.
Keep the maximum darkness restrained.
Keep walls soft and free of visible radial spokes.
Keep the angle seam invisible.
Keep dynamic gates synchronized with sight.
Keep enemy behavior fair even when enemy vision exceeds player reveal.
Keep one authoritative visibility model and one bounded overlay.
Files
- ATTRIBUTION.mdAdded by AutoGineer857 B
- LICENSELicence file added by AutoGineer1.0 KiB
- SKILL.md6.5 KiB
- agents/openai.yaml221 B
- references/mechanics.md13.8 KiB
- references/validation.md8.1 KiB
references/validation.md
Fog-of-war validation
Contents
Validation order
Pure perception tests
Fog math tests
Structural contracts
Gameplay integration tests
State and lifecycle tests
Browser verification
Performance verification
Current Vesperfall proof
Completion evidence
Validation order
Run validation from cheapest to most integrated:
Pure perception math.
Pure fog visibility and opacity math.
Source or AST structural contracts.
Gameplay integration tests.
Lint and production build.
Desktop browser verification.
Mobile/coarse-pointer browser verification.
Performance sampling.
Do not tune the shader around a broken obstacle test.
Pure perception tests
Use small synthetic obstacle fixtures. Cover:
an unobstructed target exactly at the player range;
a target just outside the player range;
enemy range greater than player range;
a target between the player and enemy ranges;
the same target blocked by a wall;
an active full-height wall;
the same gate obstacle inactive;
low cover below the sight line;
an origin inside an obstacle;
a zero-length query;
negative range or padding clamped safely;
deterministic repeated angular fills;
an angular ray that hits a known wall distance;
an angular ray with no hit returning the maximum range.
Assert withinRange and lineOfSightClear separately. A single visible assertion cannot explain why a case failed.
Fog math tests
Keep the math callable outside WebGL.
Radial visibility
Assert:
a point well inside the clear radius has visibility
1;a point between clear and vision radii is strictly between
0and1;a point outside vision radius has visibility
0.
Wall boundary
For a known wall hit distance, assert:
visibility before the wall exceeds visibility at the feather;
feather visibility exceeds visibility behind the wall;
sufficiently far behind the wall reaches zero obstacle visibility.
Opacity composition
Assert:
clear inner-space opacity is
0;wall-edge opacity is above clear opacity;
behind-wall opacity exceeds wall-edge opacity;
behind-wall opacity stays restrained;
beyond-range opacity equals maximum opacity;
angular softness remains large enough to prevent spokes;
obstacle darkness remains bounded.
For the proven Vesperfall calibration, behind-wall opacity should remain at or below 0.14, while the outer radial boundary reaches 0.38.
Structural contracts
Protect the bounded renderer architecture:
exactly one fog
ShaderMaterial;no fog-specific
WebGLRenderer;no
EffectComposer;no
WebGLRenderTarget;no per-ray meshes;
one full-screen plane;
one data texture;
desktop ray count greater than mobile;
desktop ray count no greater than
256;mobile ray count at least
96;maximum opacity in a restrained range such as
0.28–0.42;five neighboring angular samples present;
radial and obstacle fog combined with
max;no allocations inside the hot update loops beyond ephemeral scalar or stack values.
Prefer semantic tests of exported functions. Use source contracts only for architecture that is otherwise expensive to instantiate under Node.
Gameplay integration tests
Protect these behaviors:
player-visible enemies can be selected and locked;
enemies outside player range cannot be selected;
walls invalidate player targeting;
losing perception clears target lock;
hidden enemies do not contribute to player-facing enemy counts;
hidden telegraphs do not render;
actor roots stay simulation-visible;
presentation layer masks change instead of actor-root visibility;
base layer masks restore when visibility returns;
enemy perception uses enemy range;
enemies can acquire between player and enemy ranges;
walls still block extended enemy vision;
enemy attacks require a clear sight line when intended;
dynamic gates update both fog and AI perception.
Test enemy presentation independently from enemy simulation. An enemy behind fog may continue pursuing, returning, taking damage, or dying according to game rules.
State and lifecycle tests
Assert that fog:
enables during normal active gameplay;
disables in the character menu;
disables with inventory open;
disables in review and capture modes;
disables while the game is not playing;
disables during stage transitions;
cannot leak through an early menu render;
restores after returning to gameplay;
updates after camera resize;
disposes its geometry, material, and texture exactly once.
If atmospheric scene fog also changes across these states, test it separately.
Browser verification
Use the Codex browser, never Chrome.
Use normal gameplay if review modes intentionally disable fog. If a dedicated fog fixture exists, confirm that it does not bypass perception or fog state.
Desktop
Enter gameplay and verify the inner combat area remains clear.
Walk toward the outer reveal edge and confirm a smooth radial fade.
Circle a pillar or wall and watch the boundary move.
Stop near a wall and look for dark angular spokes.
Cross the
0/2πdirection around the player and look for a seam.Open and close a gate; confirm occlusion follows its active state.
Let an enemy move behind cover; confirm its model and telegraph hide without freezing its simulation.
Lose and regain target lock through a wall.
Open inventory and the character menu; confirm no overlay leak.
Trigger a stage transition and return to gameplay.
Mobile or coarse pointer
Repeat the visibility checks at the mobile ray budget. Confirm:
no obvious new spokes;
no seam;
no fog lag while walking;
stable frame pacing;
the published ray count matches the mobile budget.
Telemetry read-back
Read the live canvas dataset or equivalent diagnostics and capture:
fogOfWarEnabled;fogOfWarRays;playerVisionRadius;enemyVisionRadius;visibleEnemyIds;target visibility;
enemy-can-see-player;
line of sight;
target distance;
return reason.
Use telemetry as supporting evidence, not as a substitute for looking at the rendered result.
Performance verification
Verify:
one renderer and one animation loop;
stable draw-call increase from a single overlay;
fixed texture width;
no frame-loop geometry, material, texture, or renderer construction;
CPU visibility recalculation no more often than the movement/time gate;
camera and player uniforms still update smoothly between lookup refreshes;
desktop and mobile ray counts remain bounded;
disposal removes GPU resources;
no post-processing was added only for fog.
Profile while moving near obstacle-dense areas. A stationary empty scene is not representative.
Current Vesperfall proof
The current targeted command is:
node --import tsx --test \
tests/fog-of-war.test.ts \
tests/perception.test.ts \
tests/vfx-lighting.test.tsIt covers:
radial and wall opacity math;
five-tap angular smoothing and restrained wall darkness;
desktop/mobile ray budgets;
one overlay without composer, render target, or second renderer;
player and extended enemy ranges;
active walls, inactive gates, and low cover;
deterministic angular fills;
layer-based enemy presentation;
shadowless moonlight and visibility ownership;
renderer, animation-loop, and cleanup boundaries.
Also run the repository's lint, build, and broader test commands before shipping a change. Keep targeted proof separate from full-suite or live-deployment proof.
Completion evidence
Report:
changed files;
constants or formulas changed and why;
pure test results;
integration test results;
lint result;
build result;
desktop browser state tested;
mobile browser state tested;
telemetry values observed;
performance observations;
known baseline failures kept separate;
commit and deployment proof when the project requires them.
Do not claim visual success from unit tests alone. Do not claim live success from a local build.
Requirements and compatibility
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Security
No issues found by our static scan· No issues found
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- Created by
- Meng To
- Publisher
- Meng To (Community)
- Source
- MengTo/Skills · agent-skills/codex/implement-fog-of-war · commit 5ea1661
- Licence
- MIT License (redistribution allowed)
- LICENSE (added by AutoGineer from LICENSE)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
AutoGineer is not affiliated with or endorsed by Meng To.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download implement-fog-of-war.zip