MAKE IT SMALL.
MAKE IT PLAY.

Tiny games. Clear rules.

Build for a thumb, a quick attempt, and one more go.

POW!BOX is a mobile-first social toy box for making, sharing and playing tiny browser games. The application lives at https://pow.box and is invite-only. Below, the POW!BOX application that loads and frames a game is called the host. This site is the public developer guide. Reading it needs no account, and nothing here grants access to the application.

Today POW!BOX is a small, curated arcade. Every game in the catalogue was built with or reviewed by the POW!BOX team before it went live. Creator access is rolling out in stages, and public self-publishing is not yet available. This guide describes the current stage.

• Players: join by private invitation, browse short gameplay previews, play, replay and challenge friends.
• Creators: work with the POW!BOX team on a compatible game, test it, and hand it over for review.
• Agents: help a creator author and test a candidate, on that creator’s explicit instruction. This site supplies instructions, not a publishing API.

Creator paths today

A staged rollout. Today, onboarding is by invitation from the POW!BOX team.

• Supported now: a creator the POW!BOX team has invited builds a game in a project the team provides. The team reviews the candidate and decides whether and when it goes live.
• Supported now: an agent assists that creator inside the provided project, limited to the actions in the agent section below.
• Not yet available: public sign-up as a creator, uploading a game through the application, linking an agent to the application, or publishing without review.

There is no public creator application form today. If you are interested in making games for POW!BOX, the contact section at the end of this guide explains the only route that exists today. In the current stage, a game becomes playable on POW!BOX only after the team has reviewed it and released it.

A reviewed game is released as an immutable version. A live version is never edited in place: a change produces a new candidate, which goes through review again.

The player experience

The game gets the screen. The host handles the rest.

• A player opens a private invitation on their phone. Once in, the feed shows a curated order of short gameplay previews, not a personalized recommendation engine.
• Swipe through the feed and tap Play. Games use portrait touch controls, one visible mechanic and a clear first objective. The host owns loading, exit and safe areas.
• End a run, try again, save the game, or use the share and challenge controls the host offers. Scores are casual client reports, not verified competition results.

The supported play experience is phone-first. Desktop can be useful while developing, but keyboard games, landscape-only games, device-motion controls and complex multi-touch input are outside the creator contract. Adding the application to a home screen depends on browser support, and offline play is not guaranteed.

Compatibility expectations

Use the project the team provides. Keep the bundle small.

your-game/
  src/game.ts       # game logic
  game.json         # release manifest
  assets/           # local game assets

Built handoff:
  game.js
  game.json
  assets/

Games are written in TypeScript against PlayCanvas 2.23.0 and the POW!BOX SDK. The project the POW!BOX team provides supplies both as externals, so your game imports them instead of bundling them. The import names in that project may differ from the product name; use the imports the project provides. Never bundle the engine or SDK, never load them from a CDN, and never add another renderer, wrap the game in custom HTML, or depend on a backend or remote executable.

• The shared runtime (the engine and SDK the host provides, currently version v1) renders with WebGL2. Both 2D and 3D scenes must fit the same portrait, single-canvas, pointer-event contract.
• Game JavaScript: at most 60 KiB gzipped. Critical assets: at most 300 KiB in total, and only listed critical assets may block the first frame. Assets live under assets/. No video textures or external fonts.
• Use canvas pointerdown, pointermove and pointerup only. Start gameplay on the first pointer input; no splash screens or menus. Respect the host’s top and bottom safe areas.
• Hand over exactly the built game files and local assets. No source maps, secrets, repository metadata or dependency folders in the handoff. Keep asset licenses and dependency provenance available for review.

Feed previews are short, muted gameplay clips attached to a reviewed version. They carry no audio, so do not design a game whose preview depends on sound, and do not add remote or unlicensed music.

Manifest reference

game.json describes the game. It does not grant authority.

Manifest version is 1. Use a stable lower-case, hyphenated slug and do not rename it once a version has been released. The creator value is a display handle, never authenticated ownership. The downloadable JSON Schema describes the same format the POW!BOX team validates against.

{
  "manifestVersion": 1,
  "slug": "my-game",
  "name": "My Game",
  "creator": "@creator",
  "description": "One sentence about the game.",
  "orientation": "portrait",
  "runtime": "v1",
  "entry": "game.js",
  "scoreMode": "highest",
  "instruction": "Tap to do the one thing this game is about.",
  "objective": "Reach 10 points.",
  "controls": "Tap anywhere.",
  "permissions": [
    "save",
    "scores",
    "challenges",
    "share",
    "analytics"
  ],
  "criticalAssets": [
    "assets/icon.svg"
  ],
  "icon": "assets/icon.svg",
  "themeColor": "#E9FF32",
  "balance": {}
}

• name: 2–40 characters. instruction: 8–80 characters. objective and controls: 4–80 characters each. Describe one immediately understandable mechanic.
• orientation is portrait; entry is game.js; runtime names the shared runtime (currently v1). scoreMode is highest, lowest or none.
• permissions may contain save, scores, challenges, share and analytics, without duplicates. Declare only what the game needs; the host still decides what is allowed.
• criticalAssets lists up to 64 paths under assets/. icon points to a local PNG, WebP or SVG. No traversal, absolute paths or remote URLs.
• description, themeColor and balance are optional. description is at most 240 characters. themeColor is a six-digit hex color. balance holds number, string or boolean tunables that the game can read at runtime through game.release.balance; changing it creates a new candidate.
• The preview clip is added by the POW!BOX team during review. Do not add one yourself.

Download the manifest JSON Schema ↗

SDK lifecycle

Start. Draw. Ready. Play. Clean up.

// The project template supplies the Platform and engine (pc) imports.
const game = await Platform.start({ canvas });
const app = await game.createApp(pc);
// Load the manifest’s critical assets and draw the first frame.
app.once('postrender', () => game.ready());

// Implement these handlers for your game:
game.on('pause', pauseRun);
game.on('resume', resumeOrRestartRun);
game.on('exit', stopTimersAndRemoveInput);
// The SDK also destroys its app on exit.

// When a run ends:
game.scores.submit(score);
game.gameOver({ score });

This is an outline, not a complete game: the canvas, score and handlers belong to your implementation. Pause stops the simulation. Resume must support replay after game over. Exit stops timers and releases resources.

• game.ready() signals that critical assets are loaded and the first frame is drawn. Call it once; repeated calls are ignored.
• game.save.get() and game.save.set(state) store small JSON progress for the current player and game. Keep serialized state under 32 KiB. Do not store personal or cross-game information.
• game.scores.submit(score) and game.gameOver({ score }) accept bounded integer scores from 0 to 2³¹−1. Client scores are not suitable for prizes or money.
• game.challenges.create({ score }) asks the host to create a challenge. game.challenge holds incoming challenge context; it is not the creation method.
• game.share.open() asks the host to open its share control. Game code never creates or distributes invitations.
• game.analytics.event(name, props) records bounded gameplay events. Names use lower-case letters, digits and underscores (2–41 characters); invalid names or properties over 1 KiB are dropped silently. Never include personal information.
• Running the game outside the host uses an in-memory guest. That proves the game runs, not that saving or player identity work inside the application.

Submitting a game for review

Make the candidate reproducible. Make the handoff easy to review.

A submission is a handoff to the POW!BOX team, not an upload. Work in the project the team provides, which includes its own build, validation and test commands. Run those commands only inside that project.

• Include the source, the manifest, local assets, the built game files, asset and dependency provenance, test results and a short change summary with reproducible steps.
• Test on real phones with current mobile browsers: orientation, safe areas, pointer cancellation, background and foreground, repeated play and exit. Note the device, browser and any failures.
• Exercise save size limits, first-frame readiness and error behavior. Check network activity for unexpected remote requests; a compatible game makes none.
• Check the handoff for permitted files and imports only. Review the instruction, objective, controls and gameplay for an understandable first attempt, not just test counts.
• State known limitations honestly. Browser emulation is not proof of phone performance.

A passing build is not a release. Every game is reviewed against this guide before release: the POW!BOX team looks at gameplay, media, code and licenses and decides whether the candidate joins the catalogue. Rights, credit and content expectations are agreed privately during onboarding; nothing on this site grants or transfers rights.

Agent scope & checklist

A public guide is not an access grant.

The application has no agent connection, agent login or agent API today. An agent’s role is limited to helping a creator, on that creator’s explicit instruction, inside the project the creator provides.

Allowed on a creator’s instruction:

• Read this public documentation and the project files your creator has given you.
• Implement a compatible game candidate inside the editable files of that project.
• Run the project’s local build, validation and gameplay tests.
• Prepare a review handoff with source, built files, asset provenance, test results and known limitations.

Not allowed by this guide:

• Publish, upload, promote or change the visibility of any game. There is no public submission endpoint today, and release decisions rest with the POW!BOX team.
• Request, collect or use invitation links, sign-in material, cookies or any other player’s data.
• Use game-side fetch, WebSocket, remote imports, ads, payments, third-party analytics, service workers, eval, runtime code loading or your own backend.
• Read cookies or browser storage, access the parent or top document, or imitate messages from the host.
• Treat this guide, a passing test or a manifest creator field as permission to publish.

[ ] Confirm the creator’s instruction and work only in the project they provided.
[ ] Edit only game logic, the manifest and local assets.
[ ] Keep the engine and SDK external; respect manifest rules and size budgets.
[ ] Test touch input, first frame, pause, replay and exit on a phone-sized viewport.
[ ] Run the project’s validation, type check, lint, tests and build; report failures instead of working around them.
[ ] Review asset licenses, remove private data and prepare the candidate handoff.
[ ] Stop before release: review and release decisions rest with the POW!BOX team.

The plain-text and JSON versions of this guide are generated from the same source as this page. Automated readers can fetch them over HTTPS; no cookie or account is needed. Some default client user agents are rejected, so send a descriptive User-Agent header as in the example. This site accepts no uploads, forms or requests of any other kind.

curl --fail --user-agent 'my-game-agent/1.0' \
  https://dev.pow.box/agent/guide.txt

curl --fail --user-agent 'my-game-agent/1.0' \
  https://dev.pow.box/agent/guide.json

Player data & game capabilities

The host owns identity. Games get a small, bounded set of capabilities.

Players are signed in to the POW!BOX application through their invitation; they never sign in to a game. A game receives only basic profile context for the current player plus the bounded capabilities listed in the SDK section: small per-game saves, score reports, challenge and share requests routed through the host, and bounded gameplay events.

• A compatible game does not read cookies or browser storage, reach the parent document, make network requests, show ads, take payments or run code loaded at runtime. Review checks for all of these.
• Games receive no sign-in material, no contact details and no social graph. The only information about another player is the handle and score of the challenger when the game was opened from a challenge.
• Saves are limited to 32 KiB per player per game. Analytics properties are limited to 1 KiB per event. Scores are clamped to a bounded integer range.
• Today’s catalogue consists of games reviewed by the POW!BOX team against this guide.

Privacy & safety

Treat an invitation like a key. Keep private links out of reports and prompts.

• Access is by private invitation and is tied to the device that accepted it. Keep at least one signed-in device; there is no email or messaging account recovery today.
• Never post an invitation link or a device link (the one-use link that adds another phone to your account) in an issue, screenshot, chat group or agent prompt. If you think a link has leaked, stop it from Settings & invitations in the application if the option is shown, and ask your inviter for a fresh one privately.
• Never share cookies or other sign-in material with anyone, including an agent.
• A game should never ask for personal information, and should never store it in saves or analytics events.
• To report a broken game, use the Flag control on the game in the application. Include the game title, approximate time, device and browser, expected behavior and simple steps to reproduce. Crop screenshots to remove names and private links.

This documentation site sets no cookies, has no sign-in, runs no service worker and loads nothing from other origins. It never loads game code and provides no route into the application.

Contact & interest

No public support inbox yet. Use the channel you already have.

• Players: use the Flag control on a game inside the application, or contact the person who invited you.
• Creators already working with the POW!BOX team: use the private channel through which you were onboarded for questions, handoffs and escalation.
• Interested developers without an existing channel: there is no public support inbox, form or creator sign-up today. The only route is through someone already in contact with the POW!BOX team, such as a member who invited you or a creator you know; ask them to pass your interest on privately. Check this guide for updates; its version and date appear in the footer.

If this guide and the running application disagree, stop the dependent task and raise the discrepancy through that channel. Never infer permission from an old example.

Not available yet

Current availability, not a roadmap.

• Public creator sign-up, in-app game uploads and self-service publishing.
• An agent connection to the application or an agent API.
• Player-made recordings and audio in previews.
• Email or messaging account recovery and guaranteed offline play.
• Authoritative competitive scores, prizes, payments, ads and multiplayer backends.

This guide describes the current stage of the rollout and is updated as availability changes. Until it changes, assume anything listed here is unavailable.