# Creator platform plan

The goal is one expandable browser-game project across three creation styles. A creator should
never have to abandon a working game or pay for a rewrite to move from prompting into code.
This document separates the foundation shipped now from the larger tools still to build.

## 1. Fully prompted games

**Best version:** an interview turns a strong idea into a short design document, scoped milestones
and a complete playable slice. A creator describes a result, plays it, points out a problem and
iterates. The assistant understands installed modules, inputs, saved progress and existing code.
Before a build it should estimate scope/credits; after a build it should explain what changed,
what to test and which milestones remain. Every change is recoverable.

**Available foundation:** detailed brief, four starters, project credits/top-ups, AI multi-file
revisions, persistent jobs, per-build charges, runtime errors, Phone/Desktop previews, saved
versions, restore, source export and reviewed updates. Installed toolbox API examples travel
with source context. All generation requires an explicit build request.

**Next:** editable milestone board, build-size estimate, structured playtest feedback, image/audio
asset pipeline with provenance, automated smoke checks and repair suggestions. Acceptance: a new
creator reaches a playable first loop from a brief, can reproduce a reported issue, and can revert
without losing working mechanics or saved progression. Never promise an entire MMO in one prompt.

## 2. Prompt + manual work

**Best version:** the game is visible beside an inspector, scene/content tree and code editor.
Selecting an object exposes tuneable properties; edits update source/data visibly. Creators can
ask AI to change one system, review a file diff, accept or discard it, and keep their own code.
Reusable packages carry versions, dependencies, permissions, docs, examples and license metadata.

**Available foundation:** Build together mode, source editor, file/folder import, API examples,
pinned module copies, conflict refusal, history/restore and AI requests against the latest saved
source. AI work cannot race manual saves. Manual edits must be saved before a build.

**Next:** editable JSON/content inspector, scene/layer tree for supported 2D templates, level/map
editor, visual collision/animation controls, richer editor navigation, draft diffs before applying
AI output, package update comparisons and migration helpers. Acceptance: make the same content
change manually or through AI without corrupting the project; preserve modified package files.

## 3. Pure manual building

**Best version:** a useful browser IDE for small games and an excellent import/publish pipeline
for bigger engines. Local development and in-app editing share manifests, test tools, device
declarations, preview permissions and stable update links. A studio account never requires AI use.

**Available foundation:** Code mode, free source saves/previews/review, template ZIPs, first-party
modules, folder/file imports, version restore and ZIP export. Complete compiled engine builds can
use the existing upload flow with larger limits. Only browser source is executed, in a separate-
origin frame; importing a plugin does not execute it on the application server.

**Next:** asset manager with size/compression reports, engine-specific export guides, optional CLI
and repository sync, source diagnostics, collaborator permissions, staging previews and release
checklists. Acceptance: import a real web build, test it, publish it and update its existing URL
without using AI credits. Binary assets and large exports remain in the upload pipeline until
an asset-aware studio storage system is implemented.

## Shared toolbox and economy

The initial bank has six editable modules: multi-touch/keyboard input, versioned local saves,
particles/reduced motion, procedural sound, idle/upgrade math, and game-token creator purchases.
All starter/module code is first-party MIT licensed. An installation records version and hashes;
these describe copied source, not a security certification or automatic update channel.

Next packages should cover entities/physics adapters, finite-state enemies, dialogue/quests,
inventory/crafting, tile maps, accessible menus, localization and controller support. Each needs
a runnable example, explicit capabilities, browser/device tests, bounded resource use and an
upgrade path. User-submitted plugins require source/license review, capability declarations,
version pinning and package abuse handling before a public marketplace. Do not execute arbitrary
plugin/npm code on the platform server.

For game tokens, the available wallet-confirmed purchase bridge is suitable for optional session
cosmetics/support. Durable entitlements need a separate server-side finalized-receipt verifier,
replay protection and account ownership. Holder checks, inventory and token sinks need their own
reviewed APIs and integer-amount rules. Never derive authoritative balances from browser saves.
Token launches, revenue analytics and refunds are separate explicit workflows.

Real wagers/prizes remain gated on escrow, verified outcomes, exact burn/payout/refund handling,
security review and eligibility controls. The proposed match economy burns 5% of a decisive
combined pool and pays 95%; draws/voids refund without burn. Nothing in this toolbox enables it.
Private staging experiments remain staging-only. Open-join worlds and simulated SOL competitions
must not be promoted to production by adding a template.

## Credits and quality

Sell clear project credit packs from the workspace, preserve exact invoice/receipt verification,
show available/reserved/charged amounts and recover uncertain sends before offering another
purchase. The current pack is 2 million credits for 0.25 SOL, with input/output weights disclosed.
Future bundles/subscriptions must preserve project accounting, avoid double charges and explain
credit expiry/transfer/refund policies before checkout. Do not sell an unsupported provider promise.

“Arcade AI” is product branding. Accurate provider/source-processing disclosure stays in Privacy.
The current provider stays server-configured; changing marketing copy must never silently change
quality, billing weights, source permissions or the underlying selected model.

## Ideas adapted from Roblox

Roblox combines [playable templates](https://create.roblox.com/docs/resources/templates), a
[searchable Toolbox](https://create.roblox.com/docs/projects/assets/toolbox),
[versioned reusable packages](https://create.roblox.com/docs/projects/assets/packages),
[Studio playtesting](https://create.roblox.com/docs/studio/testing-modes), and an
[in-editor Assistant](https://create.roblox.com/docs/assistant/guide).
The useful principle is to put reusable content, source, iteration and testing in the same
workspace. Arcade's first implementation is a browser-source toolbox; it is not a Roblox engine,
3D scene editor, public asset marketplace or collaborative multiplayer development environment.

## Web, installable web and desktop

Keep instant browser play as the entry point. Plan an optional installed library and desktop
creator workspace when downloaded games, local assets and selected-folder workflows justify it.
Share identity, content versions, the SDK, review and save contracts across surfaces. A desktop
wrapper alone does not provide better performance, anti-cheat, cloud saves or native engine support.
See the [web + desktop platform plan](client-roadmap.md) for the capability comparison, runtime
candidates, security boundary, staged experiments and explicit release gates. No client is shipped.

## Release sequence and exit checks

1. **Shared foundation (this release):** three modes, free manual loop, pinned source toolbox,
   playable starters, token docs, credit purchase visibility, isolated preview and review updates.
   Check unpaid manual save/publish, wallet isolation, module conflicts, stale revision refusal,
   restore, paid build accounting and both phone/desktop layouts.
2. **Content authoring:** inspector, map/scene tools, asset import and focused AI diffs. Prove source
   round-trips and manual/AI parity before adding more editor complexity.
3. **Trusted services:** durable inventory/entitlements, documented game-server adapters, package
   update workflow and creator diagnostics. Verify authority/replay boundaries end to end.
4. **Ecosystem:** reviewed third-party packages, collaboration, repository/engine integrations,
   more project sizes and credit options. Add limits and observability before broad rollout.

Measure time to first playable loop, successful preview rate, restore success, device playtest
completion, credit cost per accepted revision, publish/update success and creator retention.
Balance acquisition with games that remain enjoyable and maintainable after their first launch.