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.

MATCHING SDK AND REVIEW CONTRACT

SOMETHING ONLINE ARCADE — COPY THIS BRIEF TO YOUR GAME-BUILDING AI

Build my game for Something Online Arcade using the attached starter kit.
First establish whether this is a new game or an existing game; reuse known answers.
Read README.txt, arcade.json, taxonomy.json and the actual arcade-sdk.js before coding.

NEW GAME: follow the selected creator-guides/25m.txt, 1h.txt or 4h.txt from
https://somethingonline.com/preview/ (or the selected brief included in this kit).
If no guide is selected, agree the intended player playtime before choosing one.
You, the AI builder, create all code, coherent gameplay art or polished code-drawn
visuals, backgrounds, appropriate simple animation/enemies, menus, tests/debugging,
cover, selected cabinet art and upload files. I answer short plain questions,
confirm the plan, playtest and upload; never ask me to write code, assemble files
or run developer checklists. Report a real tool blocker; never fake a ZIP or test.
Ask its relevant questions in short rounds and wait for answers: concept, style,
movement/interaction, controls, levels or session structure and applicable card
rules. Confirm the complete design, menu map and numbered asset list before coding.
The durations describe player playtime, not generation time. The starter sample
does not implement a finished campaign, card game or complete menu flow for you.
Follow that guide's WORK ORDER: design plus menu/art/motion plans; one tested
playable section with menus; incremental level/chapter and save/resume checks;
normal-control beatability and the full connected campaign; consistent art,
seconds-based animation timing and pacing review; reproduce/fix/regression tests;
then final-ZIP clean extraction and local/host checks before my upload/review.
Keep intended difficulty. Use the agreed style sheet and measure animation/frame
timing on supported targets; report unavailable checks, never promise perfect FPS.
Keep your technical inventory and evidence separate from my simple final handoff.

EXISTING GAME: follow creator-guides/existing.txt. Inspect the original and work
on a copy; preserve gameplay, art, IDs and compatible saves. A compatible browser
ZIP may be uploaded unchanged without arcade.json. Add only agreed changes or
missing integration; never replace an existing game with this sample.

Deliver a complete, self-contained HTML5 browser game. Use local JS, CSS, images,
fonts and audio with relative paths; no CDN scripts, trackers or external requests.
Never include API keys, passwords, wallet connections, payments, advertisements,
account forms, or personally identifying player data. AI-assisted development is
allowed; live AI calls need a future platform integration and are not enabled.

Import {Arcade} from ./arcade-sdk.js. Wait for its ready event, restore the provided
progress, and handle pause/resume. Use arcade.save(progress, score, saveVersion)
for JSON saves, with visible retry behavior on failure. Keep progress under 32 KB,
save no more than once per second, and preserve old save compatibility. Report
arcade.setPlaying(true) only during active gameplay; set it false on menus and game
over. Pause simulation and audio when paused. Provide mute and readable controls.
Use the existing example to confirm the SDK payload and method signatures.

Fill arcade.json with a unique lowercase game ID and release version. Select exact
classification IDs from taxonomy.json: category, 1–3 genres, era/style, modes,
player range, and up to 5 tags. Declare inputs, audio and content rating honestly.
This starter is for solo or shared-device play. Use the online board starter and
grid-lines-v1 contract for two-player line games; other online rules require a new
reviewed server template. Era is style, not release year.

Supply one original or licensed JPG/PNG/WebP cover (recommended 960x640), plus
the matching optional cabinet atlas only if selected; follow the exact template
below. Respect the agreed visual style and make titles readable. List every
external asset, its license, and actual AI-generated assets or development help.
Do not claim rights to artwork you do not own or license.

Keep the ZIP under 20 MB and 40 MB expanded, with no file over 12 MB and no more
than 300 entries. Put index.html at the ZIP root. Exclude hidden files, server files,
credentials, node_modules, source-project folders, nested archives and symbolic links.
Deliver ONE complete runtime ZIP; include arcade.json for a newly prepared build.
Supply editable source and actual controls/content/rights/AI/test reports separately;
exclude tests, development tools and unused assets from the upload ZIP.

NEW-GAME COMPLETION CHECKS
Implement and interactively test the selected guide's full appropriate menu flow:
title, new/continue, relevant mode/difficulty/level choices, rules/controls,
settings/audio/accessibility, pause/resume/restart/quit, results, replay/rematch
and return to Arcade. Every presented action must work; omit inapplicable actions.
Record evidence for EVERY authored level played from start to completion using
normal controls, with failure/retry, checkpoints, saves, progression and endings
where applicable. A forced win or solver is not a normal-control playthrough.
For procedural games report tested seeds and generator checks, not exhaustive play.
For card games also test the agreed player modes, deck conservation, turn/legal
move rules, hidden-hand privacy, scoring/ties, round endings, rematches and saves.
This kit does not add online card support; other online rules need separate approval.
Unpack the exact final ZIP into a clean folder and boot it via a local web server.
Check missing assets/errors, supported controls and layouts, resize/focus,
host pause/mute/exit and cleanup, SDK saves/restore and score reporting. Test the
same build in the isolated workshop preview when access is available. Its saves
are session-local; do not claim persistent cloud saves from a preview session.
Review actual cover/cabinet art. Separate automation, normal-control playthroughs,
visual review and checks not run in the report. Fix failures and rerun affected
checks; do not declare ready with required checks failed or unrun. These instructions
require implementation and evidence; they do not prove a future game has passed.

Regular creator release path: private draft → upload checks → isolated test → human
safety review → Beta Arcade testing → qualified votes → final administrator review.
Beta saves remain in memory for one session and award no tickets. Each regular
creator version starts its own testing and votes. Never claim a build is published or safe merely
because structural checks passed or players voted for it.


TWO WAYS TO FINISH — ONE UPLOADABLE ZIP
COPY FOR MY AI: open https://somethingonline.com/preview/creator.html#creator-guide,
choose this kit's game type, then Copy for my AI. The AI asks a few plain questions,
uses the linked kit and returns ONE complete game ZIP, with arcade.json inside.
If it cannot download the kit, attach this exact kit. Never claim an unbuilt ZIP.
STEP BY STEP: use the same workshop's Step by step guide. Build/test the game,
keep all required runtime files and the completed arcade.json at the ZIP root,
then choose that one ZIP. The workshop reads the manifest; review its details and
complete rights/AI disclosures personally. A separate manifest upload is optional.

OPTIONAL CABINET SKIN — EXACTLY ONE NEW IMAGE
Classic upright pilot: cabinet/skin.png, one static opaque 1024 x 1024 PNG, <=4 MiB.
Read https://somethingonline.com/preview/creator-cabinet-kit/cabinet-template.json
and download https://somethingonline.com/preview/creator-cabinet-kit.zip first.
Follow its exact six named regions, shared side/back art and physical obstructions;
never guess UVs or generate separate panel images. Add cabinetSkin with templateId
classic-upright-v1 and texturePath cabinet/skin.png to the manifest. Keep the game's
existing one cover unchanged; for a new game make one cover.png at 960 x 640.
Thus required submission art is one cover plus one atlas, not extra variants.
Agree any gameplay-art filenames, dimensions and count before creating those.
Do not put the template GLB, guides, example skin, nested kits, extra covers,
mockup renders or unused image versions in the game ZIP. The platform supplies
the model. Skin availability is server-gated; use the standard cabinet if off.
Respect an explicit standard-cabinet choice; it needs only the cover, no atlas.
Inspect the actual rotating cabinet preview on every side for readable art and
cropping; if unavailable, report that review as not run. Keep editable art separate.


CURRENT UPLOAD AND REVIEW WORKFLOW — OCTOBER 20, 2026

A compatible existing browser game does not need AI or a starter-kit rebuild. arcade.json is optional: when absent, the workshop suggests entry/cover files and stores your confirmed details alongside the unchanged ZIP. A manifest helps automatic form filling; it does not automatically add pause, saves or scores. Keep the existing SDK contracts.

For a new build prepared using this kit, include a completed arcade.json for convenience. For an update, choose My games → Upload new version and preserve the game ID, ownership and compatible save format. Never replace the original source or uploaded archive in place.

Scanning, structural checks, isolated testing and review still apply. Regular creators use the beta/final review process. The verified site owner may use the audited Publish as owner option for their own tested submissions without beta votes; other developers do not gain that permission. No kit or passing scan publishes a game automatically.

NO-AI PATH: follow Step by step in the workshop and download creator-guides/existing.txt for an existing game. Only declare AI assistance when it was actually used.

GUIDED NEW GAMES: creator-guides/25m.txt, creator-guides/1h.txt and creator-guides/4h.txt contain the staged questions and complete menu, level, card, final-ZIP and artwork requirements. Follow the selected guide, then implement and test the agreed game. The matching browser starter ZIPs are creator-kit-25m.zip, creator-kit-1h.zip and creator-kit-4h.zip. These playtime targets are estimates to measure, not a claim that the sample is a finished campaign. Never publish automatically.
