SOMETHING ONLINE ARCADE — BRING YOUR EXISTING GAME

This guide works for a game made by a human, AI, or both. AI assistance is optional; follow the checklist yourself or give this brief to a development assistant.

First ask for the existing game ZIP or source/export, its engine and version, target devices, its controls, and whether it already has local/cloud saves, scores or online services. Ask what I want changed; assume gameplay, art and style should remain as they are.

Inspect before editing. Work on a copy and keep the original archive/source untouched. Identify the entry page, referenced assets and current build instructions. If it is already a supported self-contained browser export, try that ZIP through the normal uploader first. A missing arcade.json alone does not require a rebuild.

For a desktop-only executable or source project, explain the required browser export or port before doing it. Do not pretend an EXE, native server or arbitrary multiplayer backend can be uploaded as a browser game. Inspect dependencies and propose the smallest compatible change.

Connect only missing platform functions using the existing SDK: startup, pause/resume, mute, saves and score reporting. Preserve the old save format or describe an explicit migration. Compare the adapted build with the original controls, sizing, audio, progression and score behavior. Do not replace a working game with the starter example.

For a new title use a unique game ID; for an existing title choose My games → Upload new version so ownership and game identity stay attached. Use a new release version. Keep the last published build available while the update is reviewed.

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.