A great arcade can hold a ten-second obsession or a world worth exploring for years. Build deep systems, memorable worlds and games players can keep discovering. Bring a complete browser build, or start with our voice and camera SDK.
Creator Studio lets you brief Claude Opus 5.5, generate a modular game, play it immediately, edit files, restore versions and keep expanding the same project. Activation costs 0.25 SOL and includes 2,000,000 AI credits (1 per input token, 5 per output token). The balance and source stay with your signed-in wallet. Submit finished versions for review and update the same game after launch. Studio projects support up to 128 source files and 2 MB per version; complete engine exports use the upload flow below.
The one-file starter is a starting point. Upload a complete web build with multiple scripts, maps, art, audio and data. Browser exports from Unity, Godot, GameMaker, Construct, Defold, PlayCanvas, RPG Maker, Phaser, three.js and other engines are welcome.
Independent web build
Bring your engine
Use keyboard, mouse, touch, gamepad or your own browser controls. Your game runs on the games origin in a frame, or in its own tab when it needs threads. You can use your own backend; uploading a game hosts its browser files, not a server.
Independent builds do not automatically receive SDK input, recording or wallet integration. Declare external services and permissions for review.
Arcade SDK build
Play with voice & motion
The arcade owns the microphone, camera and wallet UI. Your sandboxed game receives readings, reports a score and integrates with the arcade lifecycle. Bundle libraries and assets locally; this mode cannot call external services.
SDK builds can also have multiple files. The upload server injects the SDK when it detects its calls. The in-page test bench is for one self-contained HTML file.
Build for the browser. Compile TypeScript, JSX and engine source before uploading. Use relative asset paths so the game works in a versioned subfolder.
Package the exported folder. Put index.html at its root and zip it. Whole-project zips with an existing dist, build, out or www folder are also detected; the platform does not compile your source.
Test the exported build. Check phones and laptops, resize, input permissions, audio, loading and failures. SDK games should also test start, pause, resume and repeat play.
Upload for review. Supply controls, instructions, cover art and any external service requirements. Keep the private manage link. Updates wait for review while the approved version stays live.
Current default limits: 250 MB uploaded, 600 MB unpacked, 8,000 files. These are caps, not recommended initial downloads. The single-file test bench has a separate 1 MB limit. Threaded exports use their own tab; plan them as independent web builds because the embedded SDK bridge needs the arcade parent.
A small interface, room for big ideas
Use the arcade lifecycle.
arcade.on('start', () => {
/* reset and begin */
arcade.score(0);
});
arcade.on('frame', ({ voice, hands, face }) => {
if (!arcade.running) return;
// Map readings to your own input actions.
});
arcade.on('pause', () => { /* freeze simulation */ });
arcade.on('resume', () => { /* resume safely */ });
arcade.ready({ mic: true, hands: false, face: false });
// When the score changes: arcade.score(currentScore);
// When the run ends: arcade.gameOver(finalScore);
Register handlers before calling ready. Read loudness and pitch from voice, fingertips and gestures from hands, and expressions from face. The SDK sends readings, never raw microphone audio or camera images. video: true can show the arcade camera behind a transparent game.
Token integration is optional: arcade.token, arcade.wallet, connectWallet(), pay(amount, note) and buyToken(). Handle a missing token or wallet, declined payments and repeat sessions. Keep a complete free play path.
Purchases and stakes have different flows.arcade.pay() sends an in-game purchase to the creator. It provides no matchmaking, escrow, refunds, winner payout or burn. A client score cannot authorize a token prize.
Build mechanics that change one another: movement and terrain, equipment and enemy behavior, resource choices and exploration. Give players viable strategies, counters and surprising discoveries. Add progression that opens decisions.
Content through tools
Describe levels, quests, items, enemies and dialogue as data. Build an editor or validation script once, then let designers expand the game. Keep a stable content schema and room for new modes, biomes and campaigns.
Scale through structure
Separate simulation, rendering, input, UI, audio, assets and saves. Load a small first session; load later regions on demand. Pool busy objects, budget textures and audio, and profile the exported build on real target devices.
Longevity through care
Version saves, plan migrations, provide export/import where practical and keep old saves playable. Test readability, touch controls, reduced motion, remapping and sound alternatives. Playtest the first minute and the twentieth hour.
Browser storage is not a platform cloud-save guarantee. Treat it as best effort, handle denied storage and avoid putting secrets there. Account saves, persistent worlds and authoritative multiplayer need backend services; the arcade does not provision those today.
For a larger game, use the creator brief and project prompt. Specify a complete playable slice, interacting systems, content tools, performance budgets and an expansion plan. Then iterate from real play.
Proposed platform capability · not live
Two players. Equal stakes. A 5% burn.
A player chooses how many of the game's tokens to stake. Matchmaking finds another human who accepts the same stake and rules. Both fund a match escrow. The verified winner receives 95% of the combined pool; the remaining 5% is permanently burned.
Example: 100 tokens each → 200-token pool → 10 burned → 190 paid to the winner. The winner gains 90 tokens after recovering their stake. A draw or void returns both stakes with no burn. Network fees and account rent are separate.
Choose and pair. Free practice, public stake tiers or a private invite. Match the exact game/build/rules, network, token mint, stake, region and input class. Queueing moves no funds.
Accept and fund. Both see the same quote, deadlines and rules in platform UI. Their wallets authorize exact deposits into the match vault. Start after both deposits are finalized and both players are ready.
Play a verifiable match. A reviewed server validates actions and keeps replay evidence. The game client renders play; it cannot declare a payable winner.
Burn and pay atomically. A decisive result burns 5% through the token program and pays 95% to the winner. Publish a finalized receipt. A new match always needs fresh consent.
Before play, an expired funding or ready deadline returns deposited stakes in full. During play, reconnect grace and a server-proven forfeit follow the accepted rules. Platform failure or an unverifiable result gives a void/refund. An unresolved on-chain deadline must allow refunds without the arcade server.
Keep game rules independent of wallet code. Define fixed-step state, validated inputs, snapshots and a reproducible result. Voice and camera readings can be fabricated by a modified browser, so sensor-only games need additional review before real stakes.
Online matchmaking, authoritative rooms and Solana match escrow still need implementation and review. The old Base escrow prototype has no 5% burn and is not used here. Proposed APIs and manifests do not enable real-token play.
Each player contributes the amount below. The burn is 5% of both stakes together. On a draw or void, each gets their deposited stake back and the burn is zero.
Example uses a 6-decimal token. No wallet or real tokens are involved.
Combined pool
200 tokens
Burned · 5%
10 tokens
Winner receives · 95%
190 tokens
Winner's net gain
90 tokens
The helper uses integer base units and rejects rounding. Stakes must be divisible by 10 base units for an exact 5% burn; for this example the smallest step is 0.00001 tokens. It checks the combined pool against the u64 token amount limit. A real implementation must independently enforce these rules in escrow.
Write down rules, stake tiers and deadlines for review.
Draft; not loaded by platform
What the platform should provide next
Let creators spend their time on the game.
These are development priorities, not available services or delivery promises. The current arcade hosts reviewed browser files on one server; it does not yet host arbitrary game backends or persistent worlds.
Free multiplayer toolkit. Authoritative rooms, private invites, matchmaking, a two-client local harness, latency/disconnect simulation, a reference duel and replay inspection.
Reusable match economy. Pretend-balance tests, then devnet escrow, platform-owned consent, exact deposits, fixed burn/payout, receipts and permissionless refunds. Real-token launch requires security and eligibility/jurisdiction review.
Persistence and worlds. Account-linked versioned saves, inventories, achievements, content manifests, asset delivery and approved server adapters with quotas and migrations.
Creator operations. Extend the studio's previews, source history, restore and runtime error panel with performance reports, crash reporting, replay debugging and a compatibility dashboard.
Expansive play. Approved content packs and world editors, spectator tools, seasons and tournaments after matchmaking, moderation and settlement can support them reliably.
The platform should carry the shared infrastructure. Creators should have the tools to build games with depth, scale, personality and years of room to grow.