Build Game Map Editor
Meng ToCommunityCreated by Meng To
- Skill
- Workflow
- 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 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
Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/mengto/build-game-map-editor/downloadUnzip 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
Fshortcut 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 onlyor 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.
Validate schema, version, manifest, bounds, flat-plane rules, and per-kind settings.
Compare every changed field against production definitions.
Map approved changes back to the smallest authoritative source modules.
Run level, navigation, collision, enemy, persistence, and editor coverage tests.
Play the affected routes and encounters in the repository-approved browser.
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.mdAdded by AutoGineer870 B
- LICENSELicence file added by AutoGineer1.0 KiB
- SKILL.md8.9 KiB
- agents/openai.yaml223 B
- references/vesperfall-implementation.md6.6 KiB
references/vesperfall-implementation.md
Vesperfall Map Editor Implementation
Use this reference only after locating the current repository root and rechecking the files. Paths, schema versions, entity counts, release versions, and deployment configuration can change.
Purpose and boundary
The Vesperfall Map Editor is a private, paused director view of the authored estate.
Route:
/map-editorInput: current production placements and settings
Draft store: browser local storage
Output: validated JSON proposal
Production effect: none until a separate source-code integration is reviewed, tested, committed, and released
Gameplay plane: X/Z with Y fixed at
0
Do not describe the editor as a live level database, multiplayer editor, game save, or automatic publisher.
Source map
Read these files before changing the editor:
app/map-editor/page.tsx: dynamic server gate and authorized editor entryapp/map-editor/editor-auth.ts: IP allowlist, password comparison, signed IP-bound sessionapp/map-editor/auth/route.ts: password POST and secure cookie creationapp/map-editor/logout/route.ts: cookie invalidationapp/map-editor/vesperfall-map-document.ts: production adapters, schema, types, validatorapp/map-editor/VesperfallMapEditor.tsx: Three.js director scene, interactions, draft lifecycle, and UIapp/map-editor/map-editor-camera.ts: deterministic focus and reduced-motion behaviorapp/map-editor/map-editor-icons.ts: canonical PNG resolverapp/map-editor/map-editor.module.css: desktop editor shell and gate styling
Follow production ownership into:
app/vesperfall-content.tsapp/vesperfall-checkpoint.tsapp/vesperfall-enemies.tsapp/vesperfall-estate.tsapp/vesperfall-enemy-zones.tsapp/vesperfall-world-expansion.tsapp/vesperfall-estate-world.tsapp/vesperfall-item-icons.tsapp/VesperfallGame.tsx
Use $author-game-levels for level-content changes and $tune-enemy-ai for gameplay AI tuning. The map-editor skill owns the editing surface and draft boundary, not the full level or AI design.
Current document contract
The current document uses:
schema
vesperfall-map-editorversion
1estate version
3local key
vesperfall.map-editor.v1history limit
50entity cap
500coordinate limit
abs(x|z) <= 200entity kinds
enemy,player-spawn,pickup,interactable, andgate
Initial entities are derived from production:
enemies from
ESTATE_ENEMY_PLACEMENTS, stage enemy kinds, archetypes, and enemy-zone anchors;player starts from every stage plus the sword-fire checkpoint;
world pickups plus one rite reward per stage;
estate interactables;
estate gates.
Enemies begin with production aggro and leash values. Patrol settings are draft-only unless deliberately integrated into the runtime source.
The validator rejects duplicate IDs, unknown kinds, non-finite transforms, nonzero Y, out-of-range X/Z, invalid aggro values, and unknown patrol modes. Import additionally requires the entity ID manifest to match the currently loaded estate.
Current interaction contract
Select in the viewport or outliner.
Selection focuses the entity without reducing an already-close zoom.
Drag a selected proxy on the ground plane.
Snap options are off,
0.1,0.25,0.5, and1meter.Wheel zoom is clamped.
Middle-drag, right-drag, or Space-drag pans.
Ffits the estate.Cmd/Ctrl+Zundoes;Shift+Cmd/Ctrl+Zredoes.Fit all and fit zone are explicit actions.
Search matches label, source ID, and zone.
Layer toggles cover enemies, player starts, items, interactables, and gates.
Selected enemies show facing, aggro, leash, patrol radius, or patrol path overlays. The inspector edits X, Z, facing, awareness timings, patrol mode and radius or points, and leash bounds. Utility entity source settings remain read-only.
A drag writes one history snapshot when it ends. Local persistence begins only after the restore attempt, preventing the production document from overwriting a valid stored draft during initialization.
Current visual contract
The scene reuses buildEstateWorld({ directorMode: true }) and production fighter or procedural enemy visuals. Every entity also receives:
a layer-colored ground marker;
a canonical PNG sprite;
an invisible selection proxy;
one root group for transform and visibility.
Canonical editor icons resolve from shipped enemy catalog cards, class portraits, checkpoint and item icons, prompt icons, and explicit fallbacks. New entity kinds or IDs must resolve to an existing PNG and pass the icon tests.
Camera focus targets:
enemy
4.1player spawn
4.4pickup
4.8interactable
4.6gate
4.1
Focus is capped at zoom 5, lasts 420 ms, and becomes immediate for reduced motion.
Current access contract
Deployment secrets:
VESPERFALL_MAP_EDITOR_PASSWORDVESPERFALL_MAP_EDITOR_ALLOWED_IPS
The editor fails closed if either is absent. The allowlist is comma-separated and exact. The server prefers cf-connecting-ip, then the first x-forwarded-for value, then x-real-ip.
The session:
uses cookie
__Host-vesperfall-map-editor;lasts 12 hours;
carries version, expiration, and normalized IP claims;
is HMAC-SHA256 signed with the configured password;
is secure, HTTP-only, strict same-site, and path
/.
Unauthorized responses render the branded gate and no canvas. Metadata must remain noindex, nofollow. Never print or snapshot real secret values.
Verification
Run the focused TypeScript tests:
node --import tsx --test \
tests/map-editor-document.test.ts \
tests/map-editor-camera.test.ts \
tests/map-editor-icons.test.ts \
tests/map-editor-auth.test.tsBuild before the rendered server test:
npm run build
node --test tests/map-editor-rendered.test.mjsThen run:
npm test
npm run lint
git diff --checkUse only the Codex in-app browser for Vesperfall browser proof. Verify:
fail-closed configuration and no-index markup without secrets;
denied-IP and password-gate states where safely testable;
the authorized editor without exposing credentials;
canonical logo and entity artwork;
selection focus, pan, zoom, frame, layer toggles, search, drag, snap, inspector, overlays, undo, redo, import, export, reset, persistence, and logout;
desktop and narrow layouts supported by the implementation;
console health and cleanup after leaving the route.
For a Vesperfall runtime change, follow the repository's current narrow-commit, exact-source release, Sites deployment, succeeded-status polling, and production-route verification process. Do not deploy a global skill-only update because it does not change the Vesperfall runtime.
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.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download build-game-map-editor.zip