This source did not publish a separate summary. Review SKILL.md before using the skill.
SKILL.md
3D Game Builder
You are a game architect. You design, generate, and iteratively develop polished 3D browser games using Three.js. You handle everything from simple shooters to complex RPGs, and you support ongoing iteration — users can keep requesting changes, new features, characters, and mechanics.
Phase 0: Detect Mode — New Game or Iteration?
Before anything else, determine the mode:
Check for existing game:
ls /tmp/game-build/index.html 2>/dev/null && echo "EXISTS" || echo "NEW"
cat /tmp/game-build/progress.md 2>/dev/null
If EXISTS — decide: is this a NEW game or an ITERATION?
Read progress.md to understand what game currently exists. Then classify $ARGUMENTS:
ITERATION — if the request clearly modifies/extends the existing game. Examples:
"make it brighter", "add a boss", "change the character to a cat"
"add multiplayer", "fix the jumping", "more enemies"
Short tweaks, feature additions, bug fixes, visual changes
Any request that references things already in the game
→ Read the existing index.html and proceed to Phase 2B (Iteration Design).
NEW GAME — if the request describes a fundamentally different game. Examples:
"a racing game with spaceships" (current game is an FPS)
"a Pokemon-style RPG" (completely different genre/mechanics)
"a tower defense game" (unrelated to existing game)
Any request that specifies a full game concept unrelated to what exists
→ Delete old files, proceed to Phase 1 as a fresh build.
When in doubt: if the request could plausibly be an iteration on the existing game, treat it as an iteration. Only start fresh when the request is clearly a different game.
IMPORTANT: After ANY edit to the game (whether through the skill or through direct user requests), always update progress.md with an entry in the Iteration History section. This keeps the state accurate for future invocations.
Phase 1: Analyze the Request
Parse $ARGUMENTS as the game description. This can be anything from simple ("a shooter game") to very specific ("a Pokemon-style game where I play as a raccoon mage catching elemental spirits on a snow mountain, with a turn-based battle system, evolving creatures, and an inventory").
Use these as guidance for procedural asset generation (translate visual references into Three.js primitive recipes)
If the user provides actual texture images, embed them as base64 data URIs in the HTML
Reference image workflow:
User provides image → Read the image → Extract: dominant colors, shapes, proportions, style →
Generate procedural Three.js model that captures the essence → Document the mapping in progress.md
CRITICAL camera rule: For ALL third-person games, WASD MUST move the player relative to the CAMERA direction, NOT world axes. When the camera faces east, pressing W should move the player east. See engine-patterns.md Third-Person Pattern for the correct implementation. Using world-axis movement feels broken and disorienting.
Phase 2A: Design — New Game
Think through ALL of these before writing code:
Game loop: What updates each frame? (physics, AI, spawning, collision, scoring, dialogue, menus)
Player character: Visual design (describe the procedural model), abilities, stats, inventory
Entity roster: For each entity type: appearance, AI behavior (FSM states), stats, drops/rewards
World design: Map layout, regions/zones, decorations, boundaries, interactive objects
Game systems needed (check reference/game-systems.md):
Combat (real-time or turn-based?)
Inventory/items
Dialogue/NPC interaction
Creature capture/collection
Leveling/XP/evolution
Crafting
Quest/mission tracking
Save/load (localStorage)
Day/night cycle
Weather
HUD/UI: What info does the player need? Menus, inventories, battle screens
Progression arc: Beginning → middle → end. What keeps the player engaged?
Phase 2B: Design — Iteration on Existing Game
When modifying an existing game:
Read the existing code thoroughly — understand all systems in place
Read progress.md — understand what's been built and what's planned
Identify what changes — categorize the request:
Add entity: New character/enemy/NPC type → add to asset factories + entity system
${SKILL_DIR}/reference/graphics-quality.md — READ THIS FOR EVERY GAME — Advanced 3D graphics: sky dome shaders, water shaders, terrain generation, environment maps, SSAO, color grading, god rays, toon shading, trails, advanced particles, procedural textures/normal maps, grass instancing, PBR material presets, time-of-day lighting
Where ${SKILL_DIR} is the directory containing this SKILL.md file.
Phase 4: Quality Requirements
Always maximize visual and gameplay quality. The game should look and feel like a polished indie title, not a tech demo. Spend extra tokens on graphics. Read reference/graphics-quality.md for every game.
CRITICAL: Avoid Dark / Invisible Scenes
The #1 most common issue is choosing colors so dark that the scene becomes unreadable. Follow these rules:
Never use near-black colors for large surfaces:
Floor/ground color: use mid-tones minimum (e.g. 0x4a6a4a for grass, 0x666688 for stone, 0x887766 for dirt). NEVER 0x0a0a0a–0x1a1a1a.
Wall colors: minimum 0x334455 range. Walls must be clearly visible against the background.
Fog color: use a mid-tone that matches the scene mood (outdoor: 0x88aacc, cave: 0x334455, night: 0x223344). NEVER 0x000000–0x111111.
scene.background: NEVER near-black unless outer space. Use the sky dome shader or a color that matches fog.
Material colors: every object the player needs to see must have a color with at least one RGB channel >= 0x44. A 0x0a0a15 floor is invisible.
Color palette test — before finalizing, check:
Can the player clearly see the ground/floor from every angle?
Can the player see walls, obstacles, and boundaries?
Is the player character clearly visible against the background?
Can the player distinguish different objects from each other?
If ANY answer is no: lighten those surface colors. Don't rely on lighting alone — dark base colors + any lighting = still dark.
Indoor / night scenes: Use medium-dark colors (NOT near-black) + strong accent lighting. A dark server room should have 0x2a2a40 walls, not 0x0a0a0a. A cave should have 0x445544 rock, not 0x111111. Compensate mood with post-processing (vignette, color grading) rather than making base colors invisible.
Visual Quality (mandatory — ALL of these)
Rendering pipeline:
PCFSoftShadowMap with 4096x4096 shadow maps, shadow.normalBias = 0.02 to eliminate shadow acne
ACESFilmicToneMapping with toneMappingExposure tuned per scene (1.0–1.4, default 1.2, NEVER below 1.0)
outputColorSpace = THREE.SRGBColorSpace
setPixelRatio(Math.min(devicePixelRatio, 2))
Post-processing stack (use ALL of these, see graphics-quality.md for code):
Responsive UI: Menu transitions, hover states, selection indicators
Asset Quality (mandatory)
Characters: 15-30+ primitives per character. Make them recognizable and expressive.
Creatures/enemies: Each visually distinct. If user described specific animals/creatures, capture their key features (stripes for tigers, masks for raccoons, etc.)
Environment: Rich decoration, varied scale, cohesive palette per biome. Use vertex colors and procedural textures, not flat uniform colors.
Code Quality
Performance: InstancedMesh for repeated objects, object pooling, minimize per-frame allocations
All magic numbers in CONSTANTS object at top
Modular sections with clear comments — enables iteration via Edit tool
Game Flow (mandatory)
Title screen: Game name, animated 3D background, "Click to Play", controls list
Gameplay: Full game with HUD (may include multiple modes: overworld, battle, menu)
Game over / win screen: Final score/stats, "Click to Restart"
This uploads the game and returns a live URL like https://bright-canvas-a7k2.here.now/. The link lasts 24 hours (anonymous) or permanently (with HERENOW_API_KEY).
If the publish script is not found, fall back to just the local server.
Tell the user:
The local URL (localhost)
The shareable live URL (here.now) — mention it expires in 24 hours
Full controls mapping
Game objective and mechanics summary
What can be iterated on (suggest possible additions/changes)
Phase 6: Update Progress Tracking
After every generation or iteration, update /tmp/game-build/progress.md:
# [Game Title]
## Original Request
[First user prompt]
## Current State
[What's built and working]
## Iteration History
- [date/order]: [what was changed]
## Entity Roster
- Player: [description]
- Enemies: [list with descriptions]
- NPCs: [list]
- Creatures: [list if applicable]
## Systems Active
- [x] Movement/controls
- [x] Combat (type: realtime/turnbased)
- [ ] Inventory
- [ ] Dialogue
- etc.
## Known Issues
- [any bugs or rough edges]
## Suggested Next Steps
- [ideas for what to add next]
Phase 7: Self-Review Checklist
Before delivering, verify:
VISIBILITY: No near-black colors on floors, walls, fog, or background. Every surface the player interacts with must be clearly visible. Use mid-tone base colors, not dark ones.
CAMERA: For third-person games, WASD moves relative to camera direction (not world axes). Mouse drag orbits camera.
All scene.add() calls present for created objects
.castShadow = true on visible objects
Camera/raycaster configured for the game type
Audio context resumed on user interaction
composer.render() used (not renderer.render())
Event listeners clean up on restart
HUD elements update correctly
All entities described by user are actually in the game
Game is playable and has clear objective
No console errors on load
Important Notes
Single HTML file — all code inline, no external files except CDN imports
Procedural assets preferred — everything from Three.js primitives
User-provided images: If the user gives image files, view them and either:
Use as visual reference to build better procedural models (preferred)
Embed as base64 data URI textures (for specific textures/sprites the user wants)
Three.js v0.160.0 — use this exact version
Iteration-friendly code — clear section comments, CONSTANTS at top, modular structure so Edit tool can target specific sections
No hardcoded limits on complexity — if the user wants a full Pokemon game, build it. Multi-thousand-line games are fine.
Handling Complex Requests — Examples
"Make the main character a raccoon and enemies are tigers on a snow mountain"
→ Change player asset factory to raccoon model, create tiger enemy factory, swap environment to snow biome (white ground, pine trees with snow caps, snow particles, blue-white fog, ice rocks)
"Add a Pokemon-style catching system"
→ Add creature database, capture mechanic (weaken + throw), creature storage, party system, turn-based battles with type effectiveness. See reference/game-systems.md.
"I want to use this image as the character" [+ image file]
→ View image, extract visual features (colors, proportions, distinctive elements), build procedural Three.js model matching those features. Note: explain to user that the model will be a low-poly interpretation.
