Game Development

## Setup

On first use, read `setup.md` silently and align game scope, delivery target, and technical constraints before proposing implementation.

## When to Use

Use 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.

## Architecture

Memory lives in `~/game-development/`. See `memory-template.md` for setup and status fields.

```
~/game-development/
|-- memory.md                     # Current project state, scope, and delivery profile
|-- concept-briefs.md             # Game concepts, target audience, and pillar ideas
|-- user-preferences.md           # User taste, constraints, and style preferences
|-- system-decisions.md           # Technical decisions and tradeoffs
|-- playtest-log.md               # Session findings, issues, and balancing actions
|-- roadmap.md                    # Milestones and release checkpoints
`-- release-notes.md              # What changed between iterations
```

## Quick Reference

Use the smallest relevant file for the current task.

| Topic | File |
|-------|------|
| Setup flow | `setup.md` |
| Memory template | `memory-template.md` |
| Genre and loop selection | `game-types-and-loops.md` |
| No-build browser path with Three.js | `browser-threejs-fast-path.md` |
| Project folder blueprints | `project-structure-blueprints.md` |
| Systems architecture and state design | `systems-and-state.md` |
| Asset/content pipeline and tooling | `content-pipeline.md` |
| Multiplayer and live operations | `multiplayer-and-live-ops.md` |
| QA, balancing, and launch checklist | `qa-balance-launch.md` |

## Requirements

- Runtime for local preview scripts: `node`
- Optional tools for offline asset processing: `python3`
- Browser target for quick iterations: Chrome, Edge, Safari, or Firefox

Prefer local and static workflows first. Move to backend dependencies only when the user explicitly needs multiplayer authority, persistence, or commerce.

## Data Storage

Local notes stay under `~/game-development/` and should capture:
- the current game concept and loop assumptions
- the user preferences and non-negotiable constraints
- technical architecture choices with reasons
- playtest findings, balancing deltas, and release decisions

Keep notes concise and operational. Store decisions and outcomes, not long transcripts.

## Core Rules

### 1. Lock the Delivery Profile First
Choose one profile before coding:
- Browser Instant: no-build HTML/CSS/JS delivery, fastest iteration, easiest sharing
- Browser Structured: TypeScript or bundler workflow with modular architecture
- Engine Path: Unity, Unreal, or Godot when editor tooling and content scale justify it

Do not mix profiles in one milestone unless the user asks for migration.

### 2. Start From a Vertical Slice, Not a Full Game Plan
Always build a playable loop in this order:
- input
- movement
- objective
- fail state
- restart

A complete five-minute loop is more valuable than ten untested systems.

### 3. Treat Browser Performance as a Product Requirement
For browser-first games, define budgets before adding content:
- frame target and frame-time budget
- draw calls and shader complexity budget
- texture and audio memory budget
- mobile fallback quality tier

If a feature breaks the budget, simplify first and optimize second.

### 4. Separate Deterministic Core Logic From Presentation
Keep rules deterministic and testable:
- game state transitions
- hit and scoring logic
- progression and economy math

Render, VFX, and animation should observe state, not own truth.

### 5. Use Progressive Complexity
System order for agent-driven delivery:
- loop and controls
- feedback and readability
- enemy or puzzle variation
- progression layer
- social or online features

Only unlock the next layer after the previous one is playable and measured.

### 6. Make Playtesting Continuous
Each milestone must include:
- test objective
- expected player behavior
- observed friction
- one concrete balancing action

No new feature batch should be accepted without a playtest note.

### 7. Preserve Reusable Project Knowledge
Update local memory after major decisions:
- concept changes
- preference updates
- architecture pivots
- launch risks

This allows agents to continue work without repeating discovery.

## Common Traps

- Building menus, inventory, and cosmetics before core loop validation -> large scope with no fun proof
- Tying physics and gameplay directly to frame rate -> inconsistent behavior across devices
- Importing heavy 3D assets too early for browser targets -> unusable mobile experience
- Skipping input latency and camera readability checks -> players quit despite stable FPS
- Adding multiplayer before single-player loop quality -> expensive complexity without retention value
- Ignoring save and state recovery strategy -> broken sessions and user frustration

## Security & Privacy

Data that stays local:
- concept notes and user preferences under `~/game-development/`
- project decision logs and playtest outcomes

Data that may leave your machine only if explicitly requested:
- source code pushed to remote repositories
- asset uploads to CDN or build hosts
- backend telemetry or analytics events

This skill does NOT:
- force external services for simple browser prototypes
- require paid APIs for baseline game creation
- recommend production launch without performance and playtest evidence

## Related Skills
Install with `clawhub install <slug>` if user confirms:
- `threejs` - 3D rendering patterns and WebGL resource hygiene
- `javascript` - core scripting patterns for browser game logic
- `typescript` - safer large-scale game codebases and tooling
- `unity` - engine path for editor-heavy and cross-platform pipelines
- `unreal-engine` - high-fidelity pipeline when advanced rendering is required

## Feedback

- If useful: `clawhub star game-development`
- Stay updated: `clawhub sync`