SOMETHING ONLINE ARCADE — 25-MINUTE GAME DESIGN BRIEF

The target is approximately 25 minutes of enjoyable player playtime, not AI generation time. This is a starter and design brief, not a finished game of that length.

YOUR JOB AS THE AI BUILDER: create the entire agreed game: code, coherent gameplay art or polished code-drawn visuals, simple animations, backgrounds, menus, tests/debugging, cover, selected cabinet art and the complete upload files. I answer plain questions, confirm a concise plan, playtest the finished result and upload it. Do not ask me to write code, assemble files, fill technical manifest fields or run developer checklists. You perform the build/test/fix cycle; recommendations, placeholder screens and an asset list alone are not the finished game. If your tools cannot create an asset, ZIP or required test evidence, explain the specific blocker honestly instead of inventing completion.

WORK ORDER: (1) Ask questions and confirm design, menus, art and motion plans. (2) Build one representative playable section with working menus and test it before expanding. (3) Build and test each level/chapter incrementally, including saves and resume. (4) Verify normal-control beatability, the connected campaign route, menus and applicable card rules. (5) Review consistent final art, animation timing and measured pacing. (6) Fix defects, add regression checks and retest affected behavior. (7) Package the final ZIP, extract it cleanly and run local/host checks. (8) Deliver evidence for my own uploaded-build playtest, disclosures and review request. Keep a passed/failed/not-run checkpoint at each stage; fix blocking problems when found rather than carrying them into later stages.

FIRST: ask a short first round of relevant questions, then wait. Ask at most three plain questions per round, choosing from: What does the player do, and what games inspire the idea? Which genre and viewpoint fit? What art style, era, colors, mood and references should guide it? How should movement or card/board interaction feel? Which devices and controls: keyboard, mouse, touch, gamepad? Is play solo, shared-device or online? Reuse answers already supplied; do not repeat questions or ask me for technical manifest fields.

SECOND: ask only relevant follow-ups in short rounds, waiting for answers. Agree win/lose conditions, difficulty, combat or puzzle rules, story, unlocks, checkpoints, accessibility (remapping, readable text, motion/flashing options), audio and art ownership. Offer a few understandable choices where I am unsure, recommend sensible defaults for undecided details and omit irrelevant questions. Ask whether I want a matching optional cabinet skin or the standard cabinet; respect my choice.

LEVEL QUESTIONS: for a level-based game, ask exactly how many authored levels I want, their structure and goals, difficulty progression, level selection/unlocking, checkpoints, replay and endings. Agree a numbered level list; a suggested challenge count is not an answer on my behalf. For endless or procedural games, agree session goals, generator constraints, progression and representative test seeds instead of inventing a fixed level count or completion time.

CARD QUESTIONS: if this is a card game, agree the named rules and variant, minimum/maximum players, human/AI opponents and AI difficulty, solo/shared-device/online expectations, teams and seating. Ask about hidden-hand privacy; number of decks, deck size, suits/ranks/jokers and card effects; shuffle/deal and dealer/seat rotation; turn order and legal moves; scoring, ties, win/loss and end-round rules; rounds/match length, rematches/redeals, leaving and resuming. Agree readable card faces, backs and table art, and whether any existing owned styles are requested and actually supported. Do not promise platform inventory/shop integration.

SUPPORTED PLAY: the browser kit supports solo/shared-device play. The online kit supports only two-player line boards through grid-lines-v1. Online card games and other rules need a separately reviewed server template; explain this before implementation and agree a supported scope. Do not invent a backend or describe simulated opponents as online players.

Confirm a concise design before implementation: core loop, controls, rules, progression, the numbered level or session plan, save checkpoints, complete menu map and a numbered asset list with filenames, dimensions and counts. Respect my chosen visual style; avoid automatically imposing a palette. Keep the initial mechanic count manageable.

ART AND MOTION PLAN: agree one style sheet covering the chosen palette, scale/proportions, pixel density or resolution, lighting, fonts, UI, card faces/backs, cover and cabinet. Reuse consistent assets; record intentional variants instead of accidental style changes between levels. Specify movement speeds, animation durations in seconds, hit/contact events, audio cues and loop boundaries before production. Drive time from elapsed seconds or a fixed simulation clock, never from the number of rendered frames; display refresh must not change game speed.

CREATE THE COMPLETE GAME: across the staged checkpoints, implement all agreed gameplay code and create coherent original or properly licensed backgrounds/backdrops, characters, objects, UI and effects, using polished code-drawn visuals where suitable. Make levels feel alive with simple idle/movement/action animations and transitions appropriate to the genre. If enemies fit and we agree, create two or three distinct enemy roles with readable behavior; omit enemies for games that do not need them. Carry the same style through the entire game, menus, cover and selected cabinet skin. The numbered inventory guides your production; do not hand it back as work for me or substitute generic placeholders for the agreed finished visuals.

PACING TARGET: Aim for about 25 minutes: 3 minutes learning, 17 minutes of varied challenges, and a 5-minute finale. Start with one strong mechanic and roughly 4–6 distinct challenges; adapt this to the genre.

Use those timings as estimates, not quotas. Do not pad the game with waiting, forced grinding, repeated empty rooms or excessive difficulty. Endless/score-attack games need an agreed session or campaign goal rather than a false completion time. Measure representative playthroughs and report actual times and uncertainty.

IMPLEMENT THE MENUS: build the complete appropriate flow, including title, new game and continue, mode/difficulty/level selection where relevant, controls/rules, settings/audio/accessibility, pause/resume/restart/quit, results, replay/rematch and return to Arcade. Omit inapplicable actions; do not leave inert placeholders or promise unavailable features. Make continue/unlocks reflect actual saves, confirm actions that discard progress, and setPlaying(false) on menus and results. These are implementation requirements for the new game, not features supplied by this brief or sample.

BUILD CHECKPOINTS: build movement or a turn, one representative playable section or match and its working menus first; test this checkpoint before expanding. Then build and test each authored level or chapter incrementally, retaining working checkpoints and tracking what is actually finished. For longer campaigns, agree and test one chapter at a time, including save/resume within each chapter and across every chapter boundary. Do not postpone menu creation or chapter tests until all content is built.

MENU TESTS: interact with every presented action and route using its supported controls. Check opening, back/escape, focus, selection, disabled/locked states, confirmations, pause/resume, settings/mute, new/continue, restart/quit, results and replay/rematch. Check repeated transitions and return to Arcade; a screenshot or a button existing in the source is not an interaction test.

EVERY AUTHORED LEVEL: keep one test row per agreed level, with build/version, test method, actual result and evidence. Play each from start through completion using normal controls, without teleporting, forced wins or skipping obstacles. Test representative play, success/failure where possible, death/retry, checkpoints, save/resume, progression/unlocks and the final ending where applicable. Record a justified not-applicable result for absent mechanics. Automation/solver checks may supplement playthroughs but must be labelled separately; never label unplayed levels or chapters complete. For procedural content record tested seeds, boundary cases and generator checks without claiming every random world was played.

BEATABILITY: demonstrate at least one intended route through every authored level using normal controls and the agreed rules/difficulty, with the resources a real player can obtain. Check checkpoint restarts, resource depletion, required keys/items and progression for softlocks; a failed attempt must retain a valid retry or recovery route. Preserve intended difficulty and rules rather than weakening the game to make a test pass. For procedural levels, verify generator reachability/resource constraints and play representative recorded seeds, without claiming exhaustive random-world testing. Before calling a longer game complete, play the full connected campaign route from a fresh start to its ending, including transitions and checkpoint/save/resume continuity; disconnected level tests alone are insufficient.

CARD TESTS: test the agreed player counts and modes, shuffle/deal and deck conservation (no unintended lost/duplicate cards), legal/illegal actions and turn order, hidden-hand privacy, scoring/ties, end-round/end-match, dealer rotation, rematch/redeal reset and save/resume. Check AI moves follow the same rules. Any supported online claim needs actual multi-client tests of the supported contract; local simulation alone is not online evidence.

COVER AND CABINET ART: make one original or properly licensed game cover (recommended 960 x 640), and, if selected and available, a matching classic-upright-v1 skin: exactly one static opaque 1024 x 1024 PNG at cabinet/skin.png, at most 4 MiB. Read the actual cabinet-template.json and layout-guide.svg from https://somethingonline.com/preview/creator-cabinet-kit.zip; follow all six named regions, shared side/back art and physical obstructions. Do not guess UVs, create new cabinet geometry or supply separate panel images. Review the cover and the actual rotating cabinet preview on every side for cropping and readable artwork; if unavailable, report that review as not run. Keep editable art sources separate and include only the agreed runtime art, with no spare variants, guides, models or mockups. The standard cabinet needs no skin.

ART AND ANIMATION REVIEW: compare every level, UI, card, cover and cabinet with the agreed style sheet; check readability and intentional variants. Verify smooth motion and the specified speeds/durations, hit/contact events, audio synchronization and seamless intended loops. Test pause/resume and background-tab return without skipped events, sudden jumps or accelerated gameplay. Check the supported target refresh rates, including 30/60/120 Hz where available; record the actual display/target rate, device/browser and measured frame times. Label simulated/throttled checks and unavailable targets honestly; do not claim perfect FPS or unmeasured smoothness. Measure representative playtime after these changes and compare it with the agreed pacing without padding or erasing intended difficulty.

DEBUGGING AND REGRESSION: for each defect, record reproduction steps, build, seed/save and device as relevant, expected versus actual behavior, and useful console logs or frame timings. Isolate the root cause, apply the fix, add a focused regression check and rerun affected menu, level, card, save, art or animation checks. Use the same reproduction to confirm the original failure is resolved; record unresolved defects and checks not run. Repeat this cycle when problems appear and finish it before packaging; if final-package checks reveal a defect, fix it and rebuild/retest the affected evidence against the new final ZIP.

FINAL ZIP CHECK: extract the exact final ZIP into a clean folder and boot it through a local web server, then test that same build in the creator workshop isolated preview when access is available. Check for missing assets and uncaught errors; full-window layout, resizing/focus, every declared input and supported phone/device layout; host pause/resume and mute; exit/re-entry and timer/listener/graphics cleanup; SDK ready, saves, restore and score reporting. Check fresh and existing progress with a suitable test host; preview saves are session-local and are discarded on close, so do not claim cloud persistence from a preview. Repair failures and rerun affected checks before calling the build ready.

DELIVERY AND EVIDENCE: deliver one complete uploadable runtime ZIP, with editable source and the report supplied separately. Exclude tests, development tools and unused assets from the runtime ZIP. Report controls, changes, rights/AI disclosures and the actual menu, level/session, card-rule, boot, save and art results for the final build. Distinguish automated checks, normal-control playthroughs, visual review, failures and checks not run, including tool/access limits. Measure representative playtime separately and report uncertainty. A passing package check or this brief does not prove a complete game; do not declare ready while required checks are failed or unrun. Keep the technical inventory and evidence separate from my simple handoff: download the game ZIP, read the controls, playtest and upload it; no manual file assembly or developer checklist. I personally test the uploaded build, confirm disclosures and request publication.

CURRENT PLATFORM REFERENCES

Workshop: https://somethingonline.com/preview/creator.html#creator-guide

Browser starter: https://somethingonline.com/preview/creator-kit.zip

Unity C# / Java web-export kit: https://somethingonline.com/preview/creator-engine-kit.zip

Supported two-player line-board kit: https://somethingonline.com/preview/creator-multiplayer-kit.zip

Read the matching README, actual SDK, manifest example and taxonomy. If you cannot inspect the kit or original game, ask me to attach it. Never invent an API or claim a ZIP/test exists when it does not.

Use local assets and relative paths, responsive full-window sizing, declared keyboard/touch/gamepad controls, pause/resume, mute and checkpoint saving through the existing SDK. Pause simulation and sound when the host pauses; release timers, listeners and graphics on exit. Test mouse/touch focus and resizing.

Keep stable game IDs and compatible saves on updates. Keep score rules comparable or explicitly version a changed scoring scheme. Player accounts, ownership, scoreboards and purchases belong to the platform, not a replacement login inside the game.

Ship one complete browser-game ZIP with its runtime files at the root. Include arcade.json for automatic details when preparing a new build; it is optional for an existing compatible ZIP. Without it, the workshop stores confirmed details beside the unchanged uploaded ZIP. Do not claim metadata automatically adds save/score integration.

Confirm actual rights and any AI use honestly. AI is optional. Do not embed credentials, external services, wallets, payments or live AI calls. Supply only agreed original/licensed art and audio. Keep the supplied upload limits and supported engine/multiplayer rules.

Upload & check build → isolated preview → Send for review. Preview saves do not change player saves. Regular submissions follow the beta/final review process. The verified site owner has a separate audited Publish as owner action for their own tested submissions; this is not a shortcut for every developer. Scanning and build checks still apply.

Return the complete ZIP, controls, changes, rights notes and actual test results. I personally confirm disclosures, test the uploaded version and request publication. Never publish automatically.