{"skill":{"slug":"game-development","displayName":"Game Development","summary":"Design and ship browser-playable games from no-build Three.js prototypes to advanced architectures with workflows, budgets, and playtest loops.","description":"---\nname: Game Development\nslug: game-development\nversion: 1.0.0\nhomepage: https://clawic.com/skills/game-development\ndescription: Design and ship browser-playable games from no-build Three.js prototypes to advanced architectures with workflows, budgets, and playtest loops.\nchangelog: Initial release with browser-first workflows, architecture patterns, project templates, and advanced game system playbooks.\nmetadata: {\"clawdbot\":{\"emoji\":\"🕹️\",\"requires\":{\"bins\":[\"node\",\"python3\"],\"env\":[]},\"os\":[\"darwin\",\"linux\",\"win32\"]}}\n---\n\n## Setup\n\nOn first use, read `setup.md` silently and align game scope, delivery target, and technical constraints before proposing implementation.\n\n## When to Use\n\nUse this skill when users want to create playable games with agents, especially instant browser games with Three.js that run without a compile step. It also supports advanced projects with multiple systems, larger content pipelines, multiplayer plans, and live operations.\n\n## Architecture\n\nMemory lives in `~/game-development/`. See `memory-template.md` for setup and status fields.\n\n```\n~/game-development/\n|-- memory.md                     # Current project state, scope, and delivery profile\n|-- concept-briefs.md             # Game concepts, target audience, and pillar ideas\n|-- user-preferences.md           # User taste, constraints, and style preferences\n|-- system-decisions.md           # Technical decisions and tradeoffs\n|-- playtest-log.md               # Session findings, issues, and balancing actions\n|-- roadmap.md                    # Milestones and release checkpoints\n`-- release-notes.md              # What changed between iterations\n```\n\n## Quick Reference\n\nUse the smallest relevant file for the current task.\n\n| Topic | File |\n|-------|------|\n| Setup flow | `setup.md` |\n| Memory template | `memory-template.md` |\n| Genre and loop selection | `game-types-and-loops.md` |\n| No-build browser path with Three.js | `browser-threejs-fast-path.md` |\n| Project folder blueprints | `project-structure-blueprints.md` |\n| Systems architecture and state design | `systems-and-state.md` |\n| Asset/content pipeline and tooling | `content-pipeline.md` |\n| Multiplayer and live operations | `multiplayer-and-live-ops.md` |\n| QA, balancing, and launch checklist | `qa-balance-launch.md` |\n\n## Requirements\n\n- Runtime for local preview scripts: `node`\n- Optional tools for offline asset processing: `python3`\n- Browser target for quick iterations: Chrome, Edge, Safari, or Firefox\n\nPrefer local and static workflows first. Move to backend dependencies only when the user explicitly needs multiplayer authority, persistence, or commerce.\n\n## Data Storage\n\nLocal notes stay under `~/game-development/` and should capture:\n- the current game concept and loop assumptions\n- the user preferences and non-negotiable constraints\n- technical architecture choices with reasons\n- playtest findings, balancing deltas, and release decisions\n\nKeep notes concise and operational. Store decisions and outcomes, not long transcripts.\n\n## Core Rules\n\n### 1. Lock the Delivery Profile First\nChoose one profile before coding:\n- Browser Instant: no-build HTML/CSS/JS delivery, fastest iteration, easiest sharing\n- Browser Structured: TypeScript or bundler workflow with modular architecture\n- Engine Path: Unity, Unreal, or Godot when editor tooling and content scale justify it\n\nDo not mix profiles in one milestone unless the user asks for migration.\n\n### 2. Start From a Vertical Slice, Not a Full Game Plan\nAlways build a playable loop in this order:\n- input\n- movement\n- objective\n- fail state\n- restart\n\nA complete five-minute loop is more valuable than ten untested systems.\n\n### 3. Treat Browser Performance as a Product Requirement\nFor browser-first games, define budgets before adding content:\n- frame target and frame-time budget\n- draw calls and shader complexity budget\n- texture and audio memory budget\n- mobile fallback quality tier\n\nIf a feature breaks the budget, simplify first and optimize second.\n\n### 4. Separate Deterministic Core Logic From Presentation\nKeep rules deterministic and testable:\n- game state transitions\n- hit and scoring logic\n- progression and economy math\n\nRender, VFX, and animation should observe state, not own truth.\n\n### 5. Use Progressive Complexity\nSystem order for agent-driven delivery:\n- loop and controls\n- feedback and readability\n- enemy or puzzle variation\n- progression layer\n- social or online features\n\nOnly unlock the next layer after the previous one is playable and measured.\n\n### 6. Make Playtesting Continuous\nEach milestone must include:\n- test objective\n- expected player behavior\n- observed friction\n- one concrete balancing action\n\nNo new feature batch should be accepted without a playtest note.\n\n### 7. Preserve Reusable Project Knowledge\nUpdate local memory after major decisions:\n- concept changes\n- preference updates\n- architecture pivots\n- launch risks\n\nThis allows agents to continue work without repeating discovery.\n\n## Common Traps\n\n- Building menus, inventory, and cosmetics before core loop validation -> large scope with no fun proof\n- Tying physics and gameplay directly to frame rate -> inconsistent behavior across devices\n- Importing heavy 3D assets too early for browser targets -> unusable mobile experience\n- Skipping input latency and camera readability checks -> players quit despite stable FPS\n- Adding multiplayer before single-player loop quality -> expensive complexity without retention value\n- Ignoring save and state recovery strategy -> broken sessions and user frustration\n\n## Security & Privacy\n\nData that stays local:\n- concept notes and user preferences under `~/game-development/`\n- project decision logs and playtest outcomes\n\nData that may leave your machine only if explicitly requested:\n- source code pushed to remote repositories\n- asset uploads to CDN or build hosts\n- backend telemetry or analytics events\n\nThis skill does NOT:\n- force external services for simple browser prototypes\n- require paid APIs for baseline game creation\n- recommend production launch without performance and playtest evidence\n\n## Related Skills\nInstall with `clawhub install <slug>` if user confirms:\n- `threejs` - 3D rendering patterns and WebGL resource hygiene\n- `javascript` - core scripting patterns for browser game logic\n- `typescript` - safer large-scale game codebases and tooling\n- `unity` - engine path for editor-heavy and cross-platform pipelines\n- `unreal-engine` - high-fidelity pipeline when advanced rendering is required\n\n## Feedback\n\n- If useful: `clawhub star game-development`\n- Stay updated: `clawhub sync`\n","topics":["Game","Browser"],"tags":{"latest":"1.0.0"},"stats":{"comments":0,"downloads":1367,"installsAllTime":51,"installsCurrent":9,"stars":0,"versions":1},"createdAt":1772707178350,"updatedAt":1778491734013},"latestVersion":{"version":"1.0.0","createdAt":1772707178350,"changelog":"Initial release with browser-first workflows, architecture patterns, project templates, and advanced game system playbooks.","license":null},"metadata":{"setup":[],"os":["darwin","linux","win32"],"systems":null},"owner":{"handle":"ivangdavila","userId":"s178jdk12x4qj3gs2se3etxf3h83h7ft","displayName":"Iván","image":"https://avatars.githubusercontent.com/u/81719670?v=4"},"moderation":null}