41 browser games, one canvas codebase: how we ship them to a dozen portals

We build HTML5 games on a plain JavaScript canvas — no engine, no plugins — and
ship them through the Playgama Bridge SDK. This is what we actually learned
building them, and where the costs turned out to be.

The build is the easy part

A canvas game is a zip with an index.html. Ours are 0.6–3.8 MB. The portals
work to size budgets of 50 MB (MSN Games) and 30 MB (YouTube Playables), so
the headroom is what makes passing portal review possible at all.

<!-- index.html of a real build -->
<script src="https://bridge.playgama.com/v2/stable/playgama-bridge.js"></script>
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no, viewport-fit=cover" />
<title>VERTIKA</title>

No bundler step worth mentioning, no asset pipeline, no engine version to
negotiate with anyone. The whole game is game.js plus a folder of sound files.

The bridge is the interesting part

The Bridge SDK is a thin layer over the platform — storage, ads, leaderboards,
achievements, social — and it is not an engine. It does not take over your
game loop, and it degrades gracefully when a capability is not available.

That matters more than it sounds. The same zip runs on our own sandbox and on
20+ partner portals, and on each of them the bridge exposes a different subset:

// what actually differs between portals, and why a thin layer beats a full SDK
const canSave = await bridge.storage.isAvailable?.();   // false on some portals
const lb = await bridge.leaderboards.submit("main", score); // no-op if unsupported

You write against the bridge once and the game works everywhere. Written by
hand, that would have been twenty adapters to maintain.

One caveat worth stating plainly: the bridge is loaded from a CDN, so a portal
that blocks third-party scripts will break the build. We check for
window.bridge before initialising and fall back to a no-op mode, which is why
the games still run when the bridge never arrives.

Distribution is a catalog problem, not a marketing problem

Once a game passes moderation into the Playgama catalog it syndicates out to
the partner portals on its own. The work is metadata — genre, supported
languages, orientation, cover art — because the catalog filters by it, and a
game that describes itself badly does not surface in the right slots.

This is the part that is easy to underestimate. We had working builds with
mediocre metadata, and the difference in impressions was not subtle.

Localisation is not optional

Our games ship in 14 languages. The partner requirements make that concrete:
VK and Playhop want Russian, most of the rest want English, and YouTube
Playables wants a build that works in both orientations.

The moment you add a second language you also have to handle text expansion.
German is roughly 30% longer than English, and a button that fit in English
will not fit in German. We do the layout work once and let the strings expand
rather than trying to squeeze them:

// layout maths that assumes the longest translation, not the average one
const label = t("pause");           // "Pause" / "Pausieren" / "Пауза"
el.style.minWidth = `${label.length * 0.62}rem`;  // ~0.62rem per glyph

The second thing that bites is that a canvas game has no text nodes at all —
every label is drawn by us. We keep a string table per language and re-render
on locale change, and we test the longest locale (German) rather than English.

Audio as files, not as a library

Sound is generated at build time and shipped as files, decoded by the browser's
own audio stack:

index.html
game.js
sfx/
  hit.ogg
  hit.webm
  ...

Two reasons. It keeps the bundle small — no audio library, no synthesis code
in the hot path. And it means the same audio behaves identically on every
portal, which matters when you are comparing retention numbers between them.
It also means there is no audio middleware to break on a portal that does not
like your WebAudio usage.

The honest part: retention is the hard problem

Portals filter on average playtime — MSN wants 300 seconds, YouTube Playables
wants eight minutes — and our shorter games fall short of those thresholds even
though the same games hold up fine in playtests.

Building the game and getting it seen are two different problems, and only one
of them is solved by making a better game. We spent a long time on the wrong
one.

What we would do differently

• Ask about the portal's thresholds before tuning the game. We tuned for "feels good" and then discovered that the retention gate is a specific number of seconds.
• Ship the metadata with the build, not after it. Cover art, genre and language list are part of the upload, not an afterthought.
• Budget for the long tail of orientations. Half the ports want both landscape and portrait; the ones that only want landscape are the ones that let you skip the safe-area work.

Try them

Two examples, both run in the browser with no download:

• RIFT — a breakout roguelike where upgrades persist between runs: https://playgama.ai/play/j22cyzwj6qcatb
• Chameleon — a colour puzzle where you eat the flies that match your colour: https://playgama.ai/play/wds6cs2cg5xmao

The thing I keep going back and forth on is the 14-language requirement. It is
a lot of string work for games that are not primarily story-driven, and some of
the ports only care about one language. Has anyone here shipped a small game in
many languages, and was it worth it?

The games

All of them run in the browser, have a Russian + English interface (14 languages
in total) and work on a phone. Click a title to play — no download, no ads wall,
just a playable build.

Every build is also on itch.io with a Play on Playgama link, and the whole
catalog sits on Playgama itself.