uloggdDevelopers
Developer portaluloggd
Get startedResourcesArcade
Developer portaluloggdArcadeHostingThe frameSDKIdentityVerifying in other languagesData eventsTestingReview policyPrivacy dutiesEngines

Arcade

Put a web game you host in front of uloggd's players, inside uloggd, with a verified identity for each player who agrees.

Arcade plays web games on uloggd.com. You host the game on your own HTTPS origin; uloggd lists it, frames that URL on a page built for it alone, and, when the player agrees, gives the game a short-lived identity signed by uloggd. uloggd never hosts, proxies or serves a game's files.

Arcade is an invite-only preview. Publishing is open to the accounts on the preview list. The docs and the SDK are open to everyone, so a game can be built and tested on the mock before its developer is invited (see Preview status).

How it fits together

  • The game is your site, on its own origin: one subdomain per game. It runs in a sandboxed frame on https://uloggd.com/{lang}/arcade/{slug}/play, cross-site to uloggd.
  • The SDK, @uloggd/arcade-sdk, talks to the uloggd page around the frame. It learns the context, asks the player for consent, gets identity tokens, goes fullscreen, and hears when the game is about to close.
  • Your server verifies identity tokens offline, against uloggd's public keys, and receives data events when a player revokes, forgets the game, changes the nickname or deletes the account.
  • The portal, in your app's Arcade section, has five pages: Overview, where you enable Arcade, Store page, Releases, Player data and Development URL, where you open the game in uloggd from your own machine. Every change to the store page and every new URL is reviewed by a named moderator before players see it.

What players see, and what you receive

  • Players must be signed in to play. During the preview an Arcade player is at least 16, and every game carries a ClassInd self-rating from L to 16, enforced at launch.
  • The game receives a per-game id (sub), different in every game, and a nickname the player chooses. Never the email, the uloggd account, the age or a birth date.
  • Your servers see the player's IP address and browser, as any site does. The store page and the first-play notice tell the player so.
  • There is no monetization in v1: no purchases and no ads.

Who can publish

The database checks every condition when you enable Arcade on an app:

  • the account is on the preview list;
  • two-factor authentication is on, and this session signed in with it;
  • the email is verified, and the account is at least 30 days old;
  • you are 18 or older;
  • you accepted the current Arcade developer terms;
  • the account is not banned from the site, and staff have not blocked it from publishing.

An Arcade app is one of your developer apps, so it counts toward the 10 apps an account may have. Enabling Arcade reserves the app's slug, the address of its store page.

When the terms change. uloggd records the version of the Arcade developer terms you accepted, with a hash of its text. When a new version comes out, Overview asks you to read and accept it. Until you do, you can still edit drafts, check URLs, use the development URL, withdraw a submission and remove a game, and your games already live stay live; but submitting a release or the store page, and making a release live, answer 403 forbidden with reason terms_required.

A publishing block. Staff can block an account from publishing. A blocked account cannot enable Arcade, edit, check, submit or make live anything, or save a development URL: those answer 403 forbidden with reason publisher_blocked. It can still withdraw a submission and remove a game. To ask for a block to be reviewed, write to the contact on the About us page.

Preview status

  • During the preview, publishing is invite only: Arcade can be enabled only on the apps of an account on the preview list, and an account outside it gets not_allowlisted.
  • To ask for an invitation, write to the contact on the About us page.
  • The identity key in use is arc-2026-10 (see Current public keys).
  • The SDK is at version 0.2.0: ES modules, CommonJS, and a build for a plain script tag (see SDK).

Quick start

  1. Create a Vite project with npm create vite@latest, and install the SDK, which is on npm: npm install @uloggd/arcade-sdk. Create the client as in the example below.
  2. Run npm run dev. Opened directly on localhost, the SDK runs on its mock, offline: a fake player, fake tokens, every command answered. See Testing.
  3. Prepare the app in the portal. Under Applications, open the app and, in its Arcade section, enable Arcade on Overview. Save draft on the Store page and, under Releases, create a New release with the URL the game will have once deployed. A draft is enough for now.
  4. Test inside uloggd with the development URL. Under Development URL, set http://localhost:5173/ with that draft as the base release, then Open on uloggd: the game plays in uloggd's own player while it still runs on your machine (see Development URL).
  5. Get the hosting ready. Add public/.well-known/uloggd-arcade.json with the app id the portal shows (see The proof file) and send the header Content-Security-Policy: frame-ancestors https://uloggd.com 'self' (see Let uloggd frame it). Deploy to any HTTPS host, one origin per game.
  6. On your server, copy the snippets from Identity, which verifies identity tokens, and from Data events, which receives data events.
  7. Back in the portal, on the release, Check URL, Test and Submit for review, and submit the store page for review too.
  8. After approval, Make live. Players find the game once its store page is approved and a release is live.
import { createArcadeSDK } from "@uloggd/arcade-sdk";

const arcade = createArcadeSDK({
  appId: "YOUR_APP_ID",
  mockWhenStandalone: true,
});
const { context } = await arcade.ready();
console.log(context.mode, context.locale);

No bundler? The SDK also ships as one file for a plain script tag: see SDK.

The store page and releases

  • The store page holds the name, tagline, description, images, tags, rating, and who answers for the players' data. There is one draft at a time, and players keep seeing the approved version until a moderator approves the next. Only a higher rating takes effect as soon as you submit.
  • Releases are what a moderator reviews: the entry URL, the capabilities, the scopes, the orientation and platforms, the third parties the game loads and why, the data events URL, and notes for the reviewer. A draft release can be edited; a submitted one never changes. A new URL, scope, capability, third party or data events URL is a new release, and the live release keeps playing meanwhile. Withdraw takes a submitted release back out of the queue.
  • Make live puts an approved release in front of players. It checks the URL again first, and refuses when the hosting provider changed since the approval or the approval is more than 90 days old. To roll back, make the previous live release live again; anything older goes back through review, with Resubmit as a new release.
  • Remove from Arcade, on Overview, ends the listing for good. The slug and the origin are never given to anyone else, and the evidence is kept for 180 days. A developer app with an Arcade app cannot be deleted until it is removed from Arcade, drafts included: until then, deleting it is refused with 409 conflict and reason remove_from_arcade_first.

Submitting a release, making one live, submitting the store page and removing the app need a session that signed in recently, with two-factor, and each one sends you an email. An older session gets 403 forbidden with reason reauthentication_required: sign in again.

The API behind the portal

The portal reads and writes through the /api/v1 routes documented in Resources: Arcade. Every route that touches your apps or a player's games is session only, and refuses a key with 403 forbidden. The directory, the store pages and the identity keys are public.

Where to go next

  • Hosting: the origin, the URL rules, the proof file and the check.
  • The frame: the sandbox, permissions, storage and launch parameters.
  • SDK: every command, event, error and close code, and the mock.
  • Identity: the token, how to verify it, and the public keys.
  • Verifying in other languages: the same checks for servers that do not run JavaScript, and the refusal codes.
  • Data events: what your server receives when a player revokes, forgets the game, changes the nickname or deletes the account.
  • Testing: the mock, test mode and the development URL, before you submit.
  • Review policy: what reviewers check and the refusal reasons.
  • Privacy duties: the controller fields and what the terms ask of you.
  • Engines: no bundler, Vite, Phaser, Construct 3, Godot 4 and Unity.

Hosting

Where the game lives, the rules its URL must pass, and the checks uloggd runs against it.

On this page

How it fits togetherWhat players see, and what you receiveWho can publishPreview statusQuick startThe store page and releasesThe API behind the portalWhere to go next