Generated banner for Build Game Map Editor
Generated logo for Build Game Map Editor

Build Game Map Editor

Meng ToCommunityCreated by Meng To

  • Skill
  • Workflow
  • Software development
  • MIT
  • No issues found

From the author

Build, extend, or audit production-linked browser map editors for Three.js and isometric games. Use when Codex needs to create a private director view, derive a versioned editor document from authored placements, add outliner, layer, selection, drag, snap, inspector, or camera controls, expose enemy aggro, leash, or patrol overlays, implement local draft import, export, undo, and reset, secure an editor route with IP and password sessions, or validate and release a map editor without mutating live gameplay data.
— the description by Meng To

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a structured approach to developing a paused director tool that allows designers to inspect and draft game world placements. It emphasizes maintaining a clear boundary between the editor's draft state and the authoritative production source code. By using adapters to derive editor documents from production definitions, it ensures that changes remain traceable and reversible. The skill covers the entire lifecycle, from rendering a non-interactive director scene and implementing predictable navigation to securing the editor route and integrating validated drafts back into the codebase.

What it does

  • Defines a workflow for creating a versioned, serializable editor document.
  • Provides patterns for rendering a paused director scene using production world builders.
  • Outlines requirements for secure, gated access to private editor routes.
  • Details how to implement predictable camera controls, selection, and drag-and-drop interactions.
  • Establishes a validation process for importing and exporting map data.
  • Describes how to expose gameplay-specific overlays like aggro, leash, and patrol paths.

When to use it

  • When you need to create a private director view for game designers to adjust placements.
  • When you need to build an editor that does not mutate live gameplay data directly.
  • When you need to implement secure, IP-restricted access for internal development tools.
  • When you need to ensure that editor drafts are validated against production schemas before integration.

Advantages

  • Maintains a clear separation between editor drafts and authoritative production code.
  • Ensures editor changes are traceable back to stable source IDs.
  • Provides a secure, fail-closed architecture for internal production tools.
  • Promotes a predictable, deterministic editing experience for designers.

Usage examples

“How do I structure the document for a new map editor?”
The agent will guide you to use a small, serializable document with a fixed schema, versioning, and stable entity IDs, ensuring it remains separate from Three.js objects or React state.
“How should I secure my map editor route?”
The agent will advise implementing an IP allowlist, password protection with secure cookie-based sessions, and ensuring the route is not indexed by search engines.
“What is the best way to handle entity selection in the editor?”
The agent will recommend using invisible selection proxies for raycasting, capturing pointer gestures for atomic drags, and providing predictable focus and zoom behaviors.
“How do I integrate editor changes back into the game?”
The agent will outline a process of validating the exported JSON against production definitions, performing a diff, and committing changes through the standard repository release path.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/mengto/build-game-map-editor/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip build-game-map-editor.zip -d .agents/skills

Documentation by Meng To

Build Game Map Editor

Build a paused director tool around the real game world. Let designers inspect and draft placements quickly while keeping production data, gameplay saves, and release integration explicit.

Establish the authority boundary

Inspect the repository before designing the editor:

  • Locate authoritative world, zone, encounter, spawn, pickup, gate, interactable, and enemy-AI definitions.

  • Locate the production world builder and reusable runtime assets.

  • Locate collision, navigation, flat-plane, persistence, and deployment contracts.

  • Identify the repository-approved browser, tests, release path, and access-control requirements.

Do not create an independent map source of truth. Derive the initial editor document from production definitions through adapters. Keep stable source IDs so every draft value can be traced back to authored code.

State the lifecycle in the UI and implementation:

production source -> editor document -> isolated draft -> validated export -> reviewed source integration

Treat export as a proposal. Do not claim that a draft changes gameplay until a separate integration updates authoritative source, passes gameplay tests, is committed, and is released.

Define a versioned editor document

Use a small serializable document instead of storing Three.js objects or React state.

Include:

  • a fixed schema identifier and document version;

  • a world or level version;

  • a save timestamp;

  • stable entity id, sourceId, kind, label, zone, position, facing, and typed settings;

  • explicit entity kinds such as enemy, player spawn, pickup, interactable, and gate.

Keep editor position data on the gameplay plane. For a flat-world game, use { x, y: 0, z } and reject nonzero Y rather than silently flattening imported data.

Validate at every import and integration boundary:

  • require the exact schema and supported version;

  • cap document size, file size, entity count, coordinates, and setting ranges;

  • reject duplicate IDs, non-finite values, unknown kinds, invalid bounds, and malformed nested settings;

  • require the imported entity manifest to match the current production manifest unless entity creation or deletion is an explicit feature;

  • preserve source IDs and zone ownership through edits.

Keep detailed game-specific adapters and limits outside the reusable editor component.

Render a paused director scene

Reuse the production world builder in a deliberate director or preview mode. Do not run combat, progression, persistence, enemy simulation, or live save mutations inside the editor.

  • Prefer an orthographic top-down camera for isometric or flat-world placement.

  • Render production geometry, canonical entity visuals, and canonical icons when available.

  • Add simple fallbacks when heavy assets fail, but label them as fallbacks.

  • Give each entity one root group, a visible marker, an icon or reference sprite, and a separate invisible selection proxy.

  • Raycast proxies for reliable selection and raycast a fixed ground plane for dragging.

  • Apply transform edits to X, Z, and facing while keeping Y locked.

  • Dispose geometries, materials, textures, renderers, animation frames, observers, and event listeners on teardown.

Keep visual layers independent from editor data. Layer visibility may hide roots and overlays, but it must not delete or rewrite entities.

Make navigation and selection predictable

Provide:

  • click-to-select and select-to-focus;

  • outliner search by label, source ID, and zone;

  • kind layers with visible object counts;

  • fit-all and fit-zone actions;

  • wheel zoom with project-specific limits;

  • middle-, right-, or Space-drag pan;

  • an F shortcut to frame the map;

  • reduced-motion-aware camera focus.

Focus the selected point and zoom in enough to identify it. Never zoom out when focusing an entity the user is already viewing closely. Cancel focus animation when the user starts manual camera input.

Keep pointer gestures atomic:

  • capture the pointer during drag or pan;

  • preserve the entity-to-pointer offset;

  • snap X and Z using the selected increment;

  • update the draft during drag;

  • create one undo entry when the drag ends, not one entry per pointer move;

  • treat a click without movement as selection and focus.

Expose gameplay meaning in the inspector

Show identity, canonical asset path, source ID, zone, position, facing, and source settings for every entity.

For enemies, expose only settings that have a clear gameplay contract:

  • aggro radius and acquisition timing;

  • target-loss and boundary-linger timing;

  • hold, area, or path patrol modes;

  • patrol radius or explicit waypoint path;

  • leash bounds and return tolerance.

Draw facing, aggro, leash, patrol-area, and waypoint overlays in world space. Keep overlay colors and legend labels consistent.

Make source-owned settings read-only unless the editor has a validated write-back path. Do not turn arbitrary runtime state into editable JSON.

Keep drafts reversible and isolated

Use immutable document snapshots and a bounded history.

  • Restore a valid local draft before enabling automatic persistence.

  • Ignore an invalid local draft and report that production source was loaded.

  • Clear redo history after a new edit.

  • Timestamp committed edits and exported files.

  • Validate before export and import.

  • Reject oversized, unreadable, schema-invalid, or manifest-mismatched imports.

  • Require confirmation before resetting all draft changes.

  • Keep gameplay saves, account state, and server state outside the draft store.

  • Display Draft only or equivalent status persistently.

If collaborative editing, server persistence, or source write-back is requested later, design it as a separate authenticated workflow with conflict handling, audit history, and explicit publish approval.

Gate private production tools

Treat a private URL as insufficient protection.

  • Render the route dynamically and set noindex, nofollow.

  • Fail closed when access configuration is absent.

  • Apply an exact IP allowlist using the trusted edge IP header for the deployment.

  • Compare passwords without an early-exit plaintext comparison.

  • Sign short-lived session claims with HMAC or an equivalent server-side mechanism.

  • Bind the session to the allowed client IP and expiration time.

  • Store the token in a secure, HTTP-only, strict same-site cookie.

  • Reject oversized credentials and malformed tokens.

  • Keep passwords, allowlists, and signing material in deployment secrets; never bundle, log, export, or test-snapshot them.

  • Do not render the editor client or canvas for unauthorized requests.

  • Provide a POST logout action that invalidates the cookie.

Test missing configuration, denied IP, wrong password, valid token, wrong IP, wrong secret, expiration, and logout.

Integrate a reviewed draft

Read the exported document as a diff keyed by stable source ID.

  1. Validate schema, version, manifest, bounds, flat-plane rules, and per-kind settings.

  2. Compare every changed field against production definitions.

  3. Map approved changes back to the smallest authoritative source modules.

  4. Run level, navigation, collision, enemy, persistence, and editor coverage tests.

  5. Play the affected routes and encounters in the repository-approved browser.

  6. Commit and release through the repository's normal path.

Never copy a draft wholesale into production without understanding which system owns each field.

Verify the editor

Add deterministic tests for:

  • production-to-document coverage by entity kind;

  • stable IDs, schema validation, flat-plane enforcement, bounds, and setting ranges;

  • canonical icon or model resolution and shipped-file existence;

  • camera focus, zoom limits, and reduced motion;

  • undo, redo, drag atomicity, snap, local restore, import, export, reset, and manifest checks;

  • access configuration, exact allowlisting, password comparison, token binding, expiry, cookie flags, and fail-closed server rendering.

Then run targeted tests, full tests, build, lint, and diff checks. In the approved browser, verify unauthorized and authorized states, outliner and layer behavior, selection and focusing, drag and snap, inspector edits, overlays, undo and redo, local restore, import and export rejection paths, reset confirmation, logout, desktop layout, mobile or narrow layout if supported, console health, and renderer cleanup.

Read references/vesperfall-implementation.md when working in Vesperfall or when a concrete production implementation map is useful.

Files

ATTRIBUTION.md

Attribution

This folder is an unmodified copy of the Agent Skill "build-game-map-editor", distributed by AutoGineer (https://autogineer.com/agent-skills).

The skill's own files are unmodified copies. AutoGineer is not affiliated with or endorsed by the author or the publisher.

Files added by AutoGineer

  • ATTRIBUTION.md: this file, written by AutoGineer

  • LICENSE: copied from LICENSE

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/game-development/build-game-map-editor · 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 or Meng To.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download build-game-map-editor.zip