Testing your game

A reviewer plays every version on a phone before it goes live. If you test the same things first, your game sails through. There are two places to test:

• On your own computer, while you build. The SDK runs in standalone mode and shows test ads.
• In the portal, after you upload. The Test it button plays your uploaded zip in a phone frame, exactly as Twiddle Play hosts it.

Test on your own computer#

Double-click or local server?#

The quickest test is to double-click index.html. That opens it from file://, which works for simple games made of plain <script> tags and images.

Use a local server when your game uses any of these, because browsers block them on file://:

• ES modules (<script type="module">, anything built with Vite or webpack);
• fetch() or XMLHttpRequest to load your own JSON, levels or sounds;
• engines that load assets with fetch (KAPLAY, Phaser, PixiJS, Three.js, Godot, Unity and most others).

Start one from your game folder with either of these:

npx serve .

python3 -m http.server 8080

Then open the address it prints, like http://localhost:8080.

Read the console#

Open the browser's developer tools (F12, or Cmd+Option+I on a Mac) and look at the Console.

• One 404 for /sdk/v1/twiddleplay.js is expected. That file only exists on Twiddle Play; your own twiddleplay-sdk.js loads instead.
• Every other red line is a bug. Fix it before you upload.
• Lines starting with [TwiddlePlay] are the SDK telling you what it did, like why an ad was skipped.

Test ads on your computer (standalone mode)#

On your computer, TwiddlePlay.env is 'standalone' and every full-screen ad call shows a test overlay:

• a dark screen labelled INTERSTITIAL · TEST or REWARDED · TEST;
• the text "Test ad — real ads show only in the Twiddle Play app";
• a countdown from 3, after which it closes by itself.

While the overlay is up, your game gets pause and mute, then resume and unmute, exactly like in the app.

Standalone mode copies the app's rules:

To test your interstitial straight away, use the portal preview instead: its ad limits are off unless you turn them on.

Test pause and mute without an ad#

Switch to another browser tab, wait a few seconds, and come back. The SDK sends pause + mute when the page is hidden and resume + unmute when it comes back, in every environment. Your game should:

• freeze completely (timers too) and go silent;
• carry on exactly where it was, without a jump;
• keep the sound off if the player had muted it with your own sound button.

Test on a phone-sized screen#

In Chrome's developer tools, click the device toolbar icon (or press Cmd+Shift+M / Ctrl+Shift+M) and pick a phone, or type a size. Reviewers check at 360×740. Then:

• use touch mode (the cursor turns into a circle) and play a full round;
• try a small phone (360×640) and a tall one (412×915);
• rotate if your game's orientation is Any.

Test it in the portal#

After you upload a zip, open your game's Versions tab and press Test it on the version. Your game opens full screen in a phone frame, served from the same game server players' phones download from.

What's on screen:

• The phone frame. It starts in your store page's orientation.
• Portrait / Landscape buttons at the top. Flip them to check both if your orientation is Any.
• Restart (the circular arrow) reloads the game and clears the log.
• Open in a new tab runs the same files outside the frame, in standalone mode, with the SDK's own test ads and limits.
• Close (the X, or Esc).
• SDK activity on the side (below the phone on small screens). It shows "Waiting for the SDK…" until your game's SDK says hello, then Connected. Every call appears with a timestamp: ready(), hasRewarded() → true, showInterstitial(): showing a test interstitial, Sent pause + mute to the game, and so on.

Ads in the preview#

• Test ads count down from 3 inside the phone frame.
• A rewarded test ad has a Close early (no reward) link. Use it to check that your game gives no reward when rewarded is false.
• App ad limits is a checkbox above the log, off by default. While it's off, every showInterstitial() shows a test ad, so you can check your interstitial at once. Tick it to apply the app's timing (none in the first 60 s, at least 90 s apart, at most one per 3 minutes). The log then says why a call was skipped, like skipped by the app rules: no ads in the first 60 s (12 s so far).
• showBanner() shows a test bar below the game (or above it), and the game area shrinks by its height, like in the app. Check that nothing gets cut off, and that the bar is gone once play starts.
• If your game's ads are off, the panel says "Ads are off for this game, so every ad call answers “no”." Every ad call returns no, and hasRewarded() returns false. Check that your game still plays well that way.
• exit() shows a message: "In the app this closes the game."

What the preview can't show you#

• Real ads. Real ads only run in the Twiddle Play app.
• Your phone's real speed. Your laptop is much faster than most phones. See the performance checklist.
• Real touch. A mouse is not a thumb. Try the game on an actual phone (log in to the portal on your phone and press Test it there), or at least use touch mode in your browser's device toolbar.

Keep your game smooth#

Phones are slower than your laptop. Many also redraw the screen 90 or 120 times a second instead of 60, and in the Twiddle Play app your game runs at the phone's fastest rate. Six habits keep a game smooth on all of them:

1. Cap the canvas at 2×. Phones report a devicePixelRatio of 3 or more. A canvas that big has over twice the pixels to fill every frame, and nobody can see the difference. Use Math.min(devicePixelRatio, 2).
2. Move things by time, not by frame. Measure how many seconds passed since the last frame (dt) and move by speed * dt. Then your game runs at the same speed at 60 and 120 frames a second, and a slow frame doesn't slow the game down.
3. No shadowBlur or filter in your game loop. Both blur pixels on every draw, which is very slow on phones. Draw the glow once into a small canvas, then copy it with drawImage.
4. Reuse objects (a "pool"). Creating bullets, sparks or arrays every frame makes the browser stop now and then to clean up, which shows up as a hiccup. Make them once and reuse them.
5. Keep images small. Use WebP or compressed PNG, no bigger than you draw them. A 4000 px background on a 400 px screen just wastes memory and loading time.
6. Stop on pause. During an ad, or when the player leaves the app, stop updating. On resume, reset your frame clock so nothing jumps.

All six in one small game loop:

const canvas = document.querySelector('canvas');
const ctx = canvas.getContext('2d');

// 1. Sharp, but at most 2 canvas pixels per CSS pixel
function fit() {
  const dpr = Math.min(window.devicePixelRatio || 1, 2);
  canvas.width = Math.round(innerWidth * dpr);
  canvas.height = Math.round(innerHeight * dpr);
  ctx.setTransform(dpr, 0, 0, dpr, 0, 0); // draw in CSS pixels
}
addEventListener('resize', fit);
fit();

// 3. A glow drawn once (instead of shadowBlur every frame)
const glow = document.createElement('canvas');
glow.width = glow.height = 64;
const g = glow.getContext('2d');
const grad = g.createRadialGradient(32, 32, 0, 32, 32, 32);
grad.addColorStop(0, 'rgba(255, 220, 120, 1)');
grad.addColorStop(1, 'rgba(255, 220, 120, 0)');
g.fillStyle = grad;
g.fillRect(0, 0, 64, 64);

// 4. A pool of 100 sparks, made once and reused
const sparks = [];
for (let i = 0; i < 100; i++) sparks.push({ alive: false, x: 0, y: 0, vx: 0, vy: 0 });

function spawnSpark(x, y) {
  for (const s of sparks) {
    if (s.alive) continue;
    s.alive = true;
    s.x = x; s.y = y;
    s.vx = Math.random() * 200 - 100; // pixels per second
    s.vy = -200;
    return;
  }
}

// 6. Stop while paused, and don't jump on resume
let paused = false;
let last = 0;
TwiddlePlay.on('pause', function () { paused = true; });
TwiddlePlay.on('resume', function () { paused = false; last = 0; });

// 2. Move by elapsed time
function frame(now) {
  requestAnimationFrame(frame);
  if (paused) return;
  const dt = last ? Math.min(0.05, (now - last) / 1000) : 0; // seconds, at most 0.05
  last = now;

  ctx.clearRect(0, 0, innerWidth, innerHeight);
  for (const s of sparks) {
    if (!s.alive) continue;
    s.vy += 400 * dt;   // gravity
    s.x += s.vx * dt;
    s.y += s.vy * dt;
    if (s.y > innerHeight) s.alive = false; // back into the pool
    ctx.drawImage(glow, s.x - 16, s.y - 16, 32, 32);
  }
}
requestAnimationFrame(frame);
canvas.addEventListener('pointerdown', function (e) { spawnSpark(e.clientX, e.clientY); });

The sample games on Twiddle Play follow the same habits. Run through the checklist below before you submit.

Performance checklist#

Most players have mid-range Android phones. Check these before you submit:

• Steady frame rate. Use requestAnimationFrame and move things by elapsed time (dt), not by a fixed amount per frame.
• Sharp but not huge. Scale your canvas by devicePixelRatio, but cap it at 2: Math.min(devicePixelRatio, 2). Many phones report 3, which makes the canvas over twice as big for little visible gain.
• No garbage every frame. Avoid creating new arrays and objects inside your game loop. Reuse them.
• Cheap effects. shadowBlur, big filters and full-screen gradients redrawn every frame are slow on phones. Pre-render glows into an image once.
• Small images. Use WebP or compressed PNG. A background never needs to be bigger than 2048 px. Pack small sprites into one atlas.
• Small audio. Use OGG or MP3, mono for sound effects. A 3-minute WAV music file can be 30 MB; the same in MP3 is about 3 MB.
• Quick start. Show something within a second, even if it's a loading bar.
• Small download. Players download your whole zip. The upload page warns you when the game unpacks to more than 60% of the limit. Smaller is better on mobile data.
• Memory. Unload what you don't need. If the page runs out of memory in the app, the game closes with "The game stopped unexpectedly."

Touch and layout checklist#

• Big targets. Buttons at least 48×48 CSS pixels (44 at the very least), with space between them. Fingers are much less precise than a mouse.
• Touch and mouse both work. Pointer events (pointerdown) handle both with one listener.
• No page scrolling or zooming. Use touch-action: none on your canvas and a viewport meta tag. See Troubleshooting.
• Nothing important at the very edges. Rounded corners and camera cutouts can hide the outer few pixels. Keep buttons and scores away from the edges.
• Fits every screen. Resize your canvas when the window size changes (a banner appearing or going away changes it too), and try short and tall phones.
• Orientation. Pick the right one in your store page: Portrait, Landscape or Any. The app locks the screen to it. With Any, your game must handle rotation at any moment.
• No pop-ups. alert(), confirm() and prompt() are blocked in the preview frame, and they look out of place anyway. Draw your own dialogs.
• No hover-only controls. Phones have no hover.

Before you submit#

Run through this once with your final zip, in Test it:

1. The game loads without errors and SDK activity says Connected, then ready().
2. You can play from the start to a level end, and to a loss.
3. Your interstitial shows at a level end (limits off), and the game continues correctly after it.
4. Your rewarded button appears only when hasRewarded() is true. A full watch gives the reward; Close early (no reward) gives nothing.
5. Pause and mute work: the game freezes and goes quiet during every test ad.
6. If you use a banner: it shows only on menus and between rounds, the game re-fits when it appears, and it's gone when play starts.
7. Restart, then reload: saved progress is still there.
8. Both orientations look right, if you chose Any.

Then submit. The review guidelines list everything the reviewer checks.