# arcade.fun creator brief

Copy this into your project and use it with a coding assistant or a team. Start
with a polished playable slice, then expand the systems that create interesting
decisions. One HTML file is optional: complete browser builds are welcome.

## The promise

- Title, audience and one sentence describing the player fantasy:
- The interesting decision in the first 30 seconds:
- What a new player learns in five minutes:
- What an expert is still discovering after 20 hours:
- The one mechanic that makes the game recognizably its own:

## Systems and depth

- Core loop (action -> feedback -> reward -> new decision):
- Three interacting systems (for example movement, environment and equipment):
- Meaningful tradeoffs, counters and ways a losing player can adapt:
- Enemy behaviors, encounters, objectives and difficulty progression:
- Progression/unlocks, build variety and what persists between sessions:
- Data schemas for maps, missions, items, dialogue and encounters:
- Editor/content tools the team needs:
- Expansion seams for biomes, factions, modes, campaigns or player creations:
- Fair competitive loadouts; purchases must not secretly change match strength:

## A world that can grow

- World/level structure and what loads first:
- Later region/asset loading within the hosting budget:
- Art direction, silhouettes, animation, sound and readable feedback:
- Accessibility: remapping, touch targets, subtitles, reduced motion and
  alternative inputs where appropriate:
- Save schema/version, import/export and migrations:
- Required backend services and who operates them:
- Loading, offline and lost-connection behavior:

## Technical plan

- Engine and exported browser build folder:
- SDK mode or independent web build (see the creator handbook):
- Simulation versus rendering, input, UI, audio and content modules:
- Device, frame-time, memory and download budgets:
- Asset licenses, provenance and compression:
- Release, playtesting, rollback and compatibility process:
- Tests for interesting rules, saves and competitive outcomes:

## Optional two-player competition

Platform matchmaking/escrow is planned, not live. See multiplayer.md. Never use
arcade.pay() for stakes: it sends purchases to the creator.

- Free practice mode and how two humans play:
- Exact rules, duration, win/tie conditions and server-verifiable actions:
- Authoritative simulation, input limits, tick rate and replay format:
- Hidden information/randomness and how cheating is prevented:
- Region, latency and controller/sensor compatibility:
- Draft mint/network, stake tiers and explicit funding consent:
- Equal stakes, 5% combined-pool burn, 95% winner payout:
- Draw/void full refunds, no burn; deadlines and disconnect/forfeit rules:
- Spectator/replay rules that preserve private match information:

## Milestones

1. Playable slice: one satisfying complete session with strong feedback.
2. Depth: interacting systems, multiple viable strategies and playtest notes.
3. Expansion: data-driven content, performance budgets and versioned saves.
4. Browser release: compiled build, device checks, upload and review.
5. Optional competition: free online verification and devnet tests once platform
   services exist; real-token release requires separate approval.

## Prompt for a coding assistant

Build the game in this brief for arcade.fun. Begin with a complete playable
slice and a modular project that can expand. Preserve interesting tradeoffs,
readable feedback and player agency. Separate simulation, rendering, inputs,
content and persistence. Follow documented browser build limits and SDK
capabilities. Ship compiled browser files with relative asset paths. Explain
how to run, build, playtest and extend it. Implement only available APIs;
treat proposed matchmaking, cloud saves and escrow as future adapters. Keep
free play fully functional without them.