You Sold a Leaderboard. The Licensed Build Emits No Score. Settle That Before You License HTML5 Games.

Before you license HTML5 games for a tournament, prize draw or sponsor leaderboard, settle one question: does the build emit a score your servers can read?

On most catalogue titles, the honest answer is no. Not "no, but we can add it" — just no, because nobody ever asked the game to tell anyone anything, and the file you licensed is finished.

This gets discovered late, and always in the same order. Somebody sells a weekly tournament to a carrier, or a sponsor buys a branded leaderboard for a six-week flight, or a retail client wants a high-score board on the booth tablet. The deck says "leaderboard across our games catalogue". The integration ticket says "read the score from the game and POST it to our API". Then an engineer opens the build in a browser, watches the console during a full playthrough, and sees nothing at all come out of it.

The fix at that point is a conversation with the licensor about custom work, on a timeline that was set by a campaign start date somebody already sold. It is entirely avoidable. The whole thing is one line in a scope document, asked three months earlier.

🧱 A Cross-Origin iframe Is a Wall, and Scores Do Not Climb It

Start with the mechanics, because they decide everything downstream. A licensed HTML5 title normally arrives in one of two shapes: a hosted URL on the licensor's infrastructure that you embed, or a folder of files you host yourself.

If it is a hosted URL, the game runs in a different origin from your page. The browser's same-origin policy means your portal cannot reach into that frame and read a variable, inspect the DOM, or hook a function. The only sanctioned channel between the two is window.postMessage, and it is one-way in the sense that matters: the game has to choose to send something. If the build was never written to post a message on game over, no amount of listener code on your side will produce one. You are not blocked by a permission you can grant. There is nothing being sent.

If you host the files yourself, you are at least same-origin, which opens a door — you can, in principle, instrument the page. But the bundle is minified, often engine-generated, and the licence usually forbids modifying the build. "We'll just patch it" is a plan that ends with a support ticket saying your copy behaves differently from every other licensee's, and a clause you signed saying you would not do that.

So the practical question is never "can we read the score". It is "does this specific title already send one, and if not, who is allowed to make it send one".

📡 The Standard Portal SDK Was Built for Ad Breaks, Not Score Events

Here is why so many otherwise well-built titles emit nothing useful. The instrumentation the web games industry standardised on is about advertising, not achievement.

Look at what a portal SDK actually asks a developer to wire up. Poki's documentation describes gameplayStart() and gameplayStop() as the way a game says when the player is and is not playing, and commercialBreak() as the signal for a natural stopping point where an ad could run — with the guidance that gameplayStart() fires on the player's first input rather than on page load. That is a complete, sensible event vocabulary for deciding when to interrupt somebody. It carries no information whatsoever about how well they did.

A build that has been through that integration is not un-instrumented. It is instrumented for a different job. When it lands in your catalogue, you inherit the ad-break vocabulary and none of the scoring.

The exception proves the rule. CrazyGames does publish a leaderboard integration: a game calls submitScore() through their SDK, and there is a separate server-side API for developers who want to validate a score in their own backend before submitting it. Note what that is, though. It is a score submitted into that platform's leaderboard, on that platform's terms. A title you see with a working leaderboard on a big web portal is not evidence that the copy you license will hand its scores to you. Frequently it is the opposite: the scoring path exists, and it points somewhere that is not your database.

When you evaluate a catalogue, "has a leaderboard" is a property of a deployment, not of a build. Ask which one you are buying.

🔐 A Score the Browser Reports Is a Score the Player Could Have Chosen

Suppose you get past the first problem and the build does post a score. You now have a second one, and it is older than HTML5: anything computed on the player's device is declared by the player's device.

The industry's own defaults tell you how seriously this is taken. CrazyGames requires games to submit both the plain score and an AES-GCM encrypted copy, generated with a base64-encoded 32-byte key and a random 12-byte initialisation vector — and their documentation is explicit that the client is told the submission succeeded either way: "the server response is always successful and validation is applied in our back-end." Silent server-side rejection is not paranoia. It is what you build when you know a share of submissions are fabricated and you would rather not tell the fabricator which ones you caught.

Carry that into your own project. If your leaderboard is for bragging rights on a portal, a tampered top score is an annoyance, and you can cap, cull and move on. The moment a prize hangs on the number, the number is evidence, and a client-declared value is weak evidence. Realistic options, in the order most operators should consider them:

• Take the score out of the prize logic. Award entries into a draw for playing, not for winning. Legally simpler, technically trivial, and immune to score tampering.
• Verify the top of the board, not the whole board. Shortlist the leaders, re-run them under observation or against a replay, and publish that rule in the terms before launch.
• Insist on server-authoritative scoring for the specific titles in the competition. This is a real engineering ask, it is rarely present in casual catalogue builds, and it is priced accordingly.

Whichever you pick, pick it before the mechanic is sold, because it changes what you need from the licensor.

🧩 Four Competitions, Four Very Different Data Requirements

"We want a leaderboard" covers four products that share almost no plumbing. Sorting your case into one of them is most of the work.

1. Engagement mechanics that never need a score

Play five different titles this week. Keep a seven-day streak. Earn points per session, redeemable against something. These run entirely on events your own page already owns — a click into a game, time with the tab focused, a return visit. No cooperation from the build is required at all. For a portal or a carrier bundle, this is the default that works across a whole catalogue on day one.

2. A per-title high-score board

Needs a real score event from that title. In a licensed catalogue you will get this on a subset, not the whole shelf, because the titles came from different studios with different integration histories. Plan for a board on the handful that support it rather than a board that is mysteriously empty on two-thirds of your games.

3. A cross-title tournament with a prize

The hardest one, and the one most often sold first. Beyond the score event you need comparable scales — one title scores in points, the next in survival time, the next in levels cleared — plus normalisation rules, tie-breaks, an authoritative clock, and an anti-tamper posture. If your catalogue is generic licensed titles and your timeline is six weeks, run this on three to six instrumented titles and say so in the marketing. A tournament on six games that works beats a tournament on 400 that does not.

4. A sponsor leaderboard on a branded game

Structurally the easiest, because you are commissioning or licensing one title for a campaign and the score event can be written into the build scope before anything is made. If a leaderboard is central to the campaign idea, this route is usually cheaper than retrofitting scoring onto catalogue titles — which is the sort of trade-off worth deciding at brief stage rather than at integration stage.

🧮 What You Can Still Measure With No Score Access At All

Operators tend to treat "the games don't emit scores" as the end of the competition idea. It is not, and this is worth internalising before you go and pay for custom instrumentation you may not need.

Outside the iframe, on your own page, you own: which title was opened, when, by whom, from which referrer, on what device, how long the tab stayed focused, whether they came back, and what they opened next. That is enough to run most-played boards, playtime tournaments, quest chains, loyalty point accrual, and prize draws by entry. It is also, for a telecom or portal operator, the data that actually informs the next licence renewal.

One caveat to write on the wall: focus time is not play time, and neither is skill. A heartbeat measures a tab, not a person. Anyone gaming a playtime leaderboard will leave a tab open, so cap the daily accrual and require some interaction signal before the clock counts.

🚫 Five Ways a Tournament on Licensed Games Falls Over

• It was sold before anyone opened the console. The integration check takes an afternoon. Do it during evaluation, not after the contract.
• Every title was assumed to behave the same. A catalogue is many studios' work under one agreement. Instrumentation varies title by title, and so does the payload.
• Nobody normalised the scales. Points, seconds survived and levels cleared cannot share a ranking without a product decision, and that decision quietly determines who wins.
• The device clock decided the winner. Timestamp submissions server-side. A tournament that closes at midnight closes at midnight where your server lives, not where the phone thinks it is.
• The prize rules were written after the leaderboard shipped. Verification, disqualification and tie-breaks have to be published terms, because the first disputed win is the one that gets a screenshot posted publicly.

📋 Nine Questions to Put to a Licensor Before You Sell the Tournament

1. Which titles emit a gameplay event at all, and by what mechanism — postMessage, an SDK callback, or nothing?
2. What are the exact event names and payload fields? Is it a score, a level, a duration, or only start and stop?
3. Does the event fire only at game over, or continuously during play?
4. Is any of it validated server-side, or is every value client-declared?
5. If we host the files on our own origin instead of embedding your URL, does the instrumentation still work unchanged?
6. Can score events be added to named titles — at what cost, and with what lead time from purchase order to delivered build?
7. Who receives the data? Is anything reported back to you or to a third-party portal when a player finishes a round on our site?
8. Does the licence permit us to modify the build for instrumentation, or must every change come from you?
9. Which of these answers will appear in the licence schedule, rather than in an email from a sales engineer?

Question nine is the one that saves the quarter. Verbal answers about instrumentation age badly, because the person who gave them is not the person who ships the batch.

🎯 What You Get When You License HTML5 Games From a Direct Licensor

This is the practical argument for licensing from a company that develops games as well as distributing them: someone can answer per-title questions, and someone can change a build. A licence from a direct licensor covers the formats you actually deploy — HTML5 builds for web, portals and embedded screens, Android APK builds where you need an installable, and source where the deal includes it — along with branding and the choice of hosting the files yourself or embedding a hosted URL.

Catalogue depth matters here in a specific way. A shelf of 1,049 titles is not there so you can publish all of them; it is there so that when your requirement narrows to "titles that emit a score, work offline, and suit an under-13 audience", there is still a usable list at the end of the filter. That is the question to ask when you license HTML5 games for anything with a mechanic layered on top. If an installable catalogue is also in scope, the same conversation should cover APK game licensing rather than running as a separate procurement. Start by narrowing the shelf: browse the catalogue and build the shortlist against your mechanic, not against the thumbnails.

🧸 Licensing Branded Games for Campaigns, Portals and Events

Where the competition is the campaign — a sponsor leaderboard, a retail promotion, a booth high-score board — branded content changes the participation rate more than any feature you can build around it. Forestry Games works with branded IP and has brand partnerships including Disney, Nickelodeon, Cartoon Network and Warner Bros, and businesses can license branded game content through Forestry Games for campaigns, portals, events and apps. Because a branded title is scoped before it is built, it is also the cleanest place to specify the score event, the payload and where the data lands.

If that is your case, the next step is a scoping conversation rather than a catalogue browse: describe the mechanic, the audience and the flight dates, and ask for a licence scope covering the titles and the instrumentation together. For campaign and event use, marketing game licensing and games for events are the right starting points, and a portal demo is worth asking for if the leaderboard has to live inside a white-label site.

✅ Run the Score Test This Week

Do not take this on trust in either direction. Open two titles you are already licensing, or two demo links from a supplier you are evaluating. Put a window.addEventListener('message', console.log) on the parent page, play each one to a real game over, and read what arrives. Ninety seconds per title, and the result decides whether the tournament in next quarter's plan is a configuration job or a development project.

Then send the nine questions above to the licensor before the mechanic gets sold to anyone. The cheapest version of this problem is a paragraph in a scope document. The expensive version is a sponsor asking why the leaderboard is empty in week two.