Svelte Game Writer

Build small, single-player browser games end-to-end in SvelteKit + TypeScript running in Docker. Focus on local gameplay only (no multiplayer, no backend services).

Quick intake

Ask only what is needed to proceed:

• Game type and core loop (e.g., runner, puzzle, shooter)
• Rendering mode (DOM/SVG vs Canvas)
• Input targets (keyboard, mouse, touch)
• Target device (desktop, mobile, both)
• Art/audio constraints (placeholders OK?)
• Testing scope (unit only vs unit + e2e)

If any answer is unclear, ask a brief clarification and offer to proceed with automatic defaults if the user prefers.

Workflow

1. Plan

   • Summarize the core mechanics in 1–2 sentences.
   • Define win/lose conditions and progression.
   • List game states/scenes (e.g., menu, play, pause, game-over).
   • Identify data structures and update frequency (fixed timestep vs variable delta).

2. Scaffold

   • Use the SvelteKit + TypeScript Docker scaffold in assets/bare-docker-app/ and copy it into the project root.
   • Keep dependencies minimal and local-only.
   • Provide both Docker dev (hot-reload) and release (nginx) flows.
   • Add test tooling: Vitest + @testing-library/svelte; Playwright for smoke tests.

3. Implement core loop

   • Use requestAnimationFrame with a fixed timestep accumulator for deterministic logic.
   • Separate update(dt) from render(); avoid heavy work in Svelte reactive statements.
   • Keep game state in a plain object/store; expose read-only to UI.

4. Input + UI

   • Centralize input handling (keyboard/pointer) and normalize to actions.
   • Keep UI (score, lives, menus) in Svelte components; keep simulation logic framework-agnostic.

5. Assets

   • Use placeholders by default; allow easy swap via a simple assets.ts map.
   • If audio is required, gate playback on first user interaction.
   • Docker bare scaffold lives in assets/bare-docker-app/ (SvelteKit + TypeScript, dev+prod Docker, nginx release).

6. Testing

   • Unit test pure logic: collisions, scoring, state transitions.
   • Component test HUD/menus with Testing Library.
   • Optional Playwright smoke test: load page, start game, verify canvas/UI renders.
   • If MCP is available, prefer Playwright MCP and use browser_take_screenshot for visual confirmation.

7. Deliver

   • Provide run/test commands and a brief README-style usage note.
   • Call out constraints (no multiplayer/server) and suggested extensions if requested.

Project structure (default)

• src/lib/game/ core logic (state, systems, input)
• src/lib/game/render/ rendering helpers (canvas, sprites)
• src/lib/ui/ Svelte components (HUD, menus)
• src/routes/ entry
• src/app.d.ts SvelteKit types
• tsconfig.json TypeScript config
• tests/ unit + component tests
• e2e/ Playwright smoke tests (optional)

Implementation patterns

Game loop (fixed timestep)

• Keep a state object with positions/velocities/flags.
• In tick(now) accumulate delta and call update(fixedDt) in a loop.
• Render with interpolation factor alpha if needed.

Input mapping

• Map raw events to actions (left, right, jump, fire).
• Store current and edge states (pressed, justPressed).

Scene/state machine

• Use a simple enum + switch to drive scene transitions.
• Keep transition logic in update(); UI observes current scene.

Testing guidance

• Use deterministic seeds for random elements in tests.
• Mock performance.now and requestAnimationFrame for unit tests.
• Prefer small pure functions for collision, spawning, and scoring.

TypeScript reliability guidelines

• Type all public module boundaries (inputs/outputs) and shared state objects; avoid any.
• Use readonly for immutable state snapshots and as const for action enums.
• Prefer discriminated unions for game states/scenes and exhaustive switch with never.
• Use satisfies to validate configuration objects without widening types.
• Keep math/physics in pure, typed functions; make side effects explicit.

Constraints

• Do not design or implement multiplayer, servers, or backend APIs.
• Do not switch away from SvelteKit + TypeScript + Docker unless the user explicitly changes scope.
• If the user requests those, explain the constraint and offer a single-player alternative or ask to switch scope.

Output quality checklist

• Game starts, runs, and ends deterministically.
• Controls feel responsive and are documented.
• No console errors at idle or during play.
• Tests pass locally with provided commands.