A Multiplayer Title Isn't a File, It's a Running Server. Settle That Before You License HTML5 Games.

Before you license HTML5 games that include multiplayer titles, find out whose server the game calls at runtime. On most catalogue builds, the answer is not you.

Single-player titles behave like every other web asset you have ever bought. A folder of files, a hosting bill measured in cents, a thing that keeps working whether or not anyone is watching it. You can put a thousand of them on a CDN and forget about them for a year.

A multiplayer title is a different object wearing the same file extension. Somewhere in that build is a connection to a machine that has to be awake, reachable and paid for at the moment a player presses Play. If nobody has agreed who owns that machine, the title appears in your catalogue, appears in your CMS, appears in your title count — and shows an infinite "Connecting…" spinner to the first person who clicks it.

This gets missed because catalogue conversations have columns for scope, territory, term and format, and none for "requires live infrastructure". So the .io titles ride in alongside the match-3, priced the same and failing differently.

🔌 Ask What Happens Between Click and First Frame

There are only three answers, and they cost wildly different amounts.

Peer-to-peer. Players connect directly to each other over WebRTC. There is no game server at all — but there is still infrastructure. Peers cannot find each other unaided, so a signalling service handles discovery and lobbies, a STUN server tells each client its own public address, and a TURN server relays traffic when a direct connection cannot be established (restrictive NATs, corporate networks, some mobile carriers). Poki's own developer documentation for its Netlib networking library describes exactly this shape: "Direct client-to-client connections without a central game server", with Poki providing "hosted STUN/TURN and signaling services for free" while noting that developers "can also self-host these components". The library's stated benefits are worth reading as a summary of why studios choose P2P at all — "No server costs", "No double implementation", and lower latency when players are geographically close.

The catch is in the last two words of that free offer. Free on Poki. A title built against a platform's signalling backend does not automatically talk to yours, and Poki's documentation notes the library is still beta and that its API can change. If you license a P2P title for your own domain, the question is whether the licensor ships a build pointed at infrastructure you control, or one that quietly assumes the platform it was born on.

Authoritative server. Game state lives on a server you or the licensor runs, usually room-based: a process holds a match, a few dozen players connect, the room closes. This is what anything with scoring integrity needs, because P2P means the client is the authority and the client can be modified. Room-based servers are the honest answer for competitive play and the expensive one for everything else.

Platform-locked. The build only works inside the environment it was commissioned for, because the matchmaking, identity and persistence all come from that platform's SDK. These titles look licensable and are not, at least not without a port. They are the reason "do you have multiplayer games?" is the wrong question and "which of your multiplayer titles ship with a self-hostable backend?" is the right one.

⏱️ Latency Decides Where the Server Can Physically Sit

The reason multiplayer infrastructure costs more than static hosting is not compute. It is geography.

A CDN edge node solves distance for files because files can be copied. Game state cannot be copied — every player in a match has to reach the same authoritative process, so somebody is always the furthest away. The tolerance for that distance is narrow and well documented. Mark Claypool and Kajal Claypool, writing in Communications of the ACM in November 2006, measured player performance against injected latency and found accuracy in a high-precision shooting task dropped by roughly 35% at 100 milliseconds. The study is twenty years old and has not aged, because the limiting factor is human perception and the speed of light.

What that means operationally:

• A single-country portal is easy. One region, one deployment, players within a few tens of milliseconds of each other. This is the case for most carrier and operator portals, and it is why multiplayer is more tractable there than people assume.
• A global portal is not one deployment. It is regional deployments plus matchmaking that keeps players in their own region — which in turn means a thin player pool per region until you have real traffic. A worldwide portal with 400 concurrent users has roughly nobody to match a player in São Paulo against at 3am.
• P2P inverts the problem in your favour. Two players in the same city routed directly to each other beat two players in the same city routed through a server in Virginia. This is the genuine argument for peer-to-peer on a casual portal, and it is stronger than the cost argument.

Matchmaking pool size is the number that kills more multiplayer sections than latency does. A title needs a critical mass of simultaneous players to produce a match in under ten seconds, and below that mass you are shipping a lobby screen, not a game. Model it before you licence it: concurrent users × share who pick that title × share online in the same region. If the answer is a single digit, the title needs bots, and bots need to be in the build you are buying.

🧾 The Hosting Layer Under You Moved Twice in 2026

If a licensor tells you they will run the servers, ask what they are running them on. Two of the better-known answers stopped existing this year.

Unity's own service status notice records that "As of April 1st 2026 Multiplay Game Server Hosting by Unity has been deprecated" and that "Customers can no longer scale new game servers or make new allocations to the Multiplay service" — see the Unity status notice. Unity announced the wind-down in December 2025 and licensed the underlying software to Rocket Science Group, a company formed by people from the original Multiplay team, so existing titles had a migration path rather than a cliff. Separately, game server host Gameye's 2026 roundup of the sector records that Hathora announced on 4 March 2026 that it would close its game server hosting platform, which shut down on 5 May 2026, with the team moving to an AI company.

Neither is a scandal — managed game-server orchestration is a hard, low-margin business and consolidation is normal. The point for a licensee is narrower: the multiplayer titles in your catalogue sit on top of a vendor stack you did not choose and cannot see, and that stack changed twice in five months. If your licence says the licensor operates the backend, it should also say what happens when the licensor's own vendor exits — notice period, migration obligation, and who pays.

The counterweight to that risk is open source. Colyseus, one of the common Node.js frameworks for room-based web multiplayer, publishes both options on its pricing page: a free open-source tier to "Self-host on your own servers" with "No restrictions", and Colyseus Cloud "Starting at $15/mo" with "No CCU/DAU/MAU limits" and unlimited bandwidth. A framework you can self-host cannot be discontinued out from under you. That is worth more than the price difference, and it is a fair question to put to a licensor: is the multiplayer stack behind these titles something we could take over if we had to?

⚖️ Add Chat and You Have Changed What Your Site Legally Is

This is the part that catches portal operators who think of multiplayer as a product decision.

The moment players can send each other text, voice or even a nickname that renders on another person's screen, the service has user-to-user functionality. Under the UK's Online Safety Act, that is a regulatory category, not a feature description. Ofcom has published guidance aimed specifically at the games industry — "Gaming: know the online safety risks, the rules, and how to comply" — and its framing is that in-game chat, voice comms and player-to-player interaction are what bring a games service into scope. Illegal content duties came into force in March 2025; the children's protection codes followed in July 2025, with a children's access assessment required first if the service is likely to be accessed by children.

A casual games portal is, almost by definition, likely to be accessed by children. So the sequence is: licence some .io titles, enable chat because the build has it, and acquire a risk assessment obligation, a moderation requirement, and a reporting mechanism you had not budgeted for. Other jurisdictions have their own analogues, and the app stores impose their own user-generated-content rules on top if you ship the portal as an app.

The cheap mitigation is usually to ship multiplayer with chat disabled and nicknames drawn from a generated word list rather than free text. Most casual multiplayer loses very little. Whether you can disable it is a property of the build — which is a licensing question, asked before signature, not a settings toggle you find later.

🚩 Nine Questions Before a Multiplayer Title Enters Your Catalogue

1. Is it peer-to-peer or server-authoritative, and if server-authoritative, who operates the server?
2. If the licensor operates it, what is the uptime commitment and what is the remedy when it is missed?
3. Can we self-host the backend — signalling, TURN, or the room server — if we need to?
4. What third-party services does the build call at runtime, and are any of them free tiers belonging to another platform?
5. Does it support region-pinned matchmaking, or does it pool players globally?
6. Does it have bots or a single-player fallback for when the lobby is empty?
7. Can chat and free-text nicknames be disabled in the build we receive?
8. What is the concurrency ceiling before we need to add capacity, and who monitors it?
9. When the licence ends, what happens to accounts, nicknames and player-held state?

A licensor who answers all nine quickly is telling you something true about how they operate. One who treats the questions as unusual is telling you something too.

🎯 When You Should Skip Real-Time Multiplayer Entirely

Here is the honest position, and it is not the one that sells the most titles.

For the large majority of portals, campaigns and operator decks, real-time multiplayer is the wrong purchase. It brings live infrastructure, a moderation obligation, a matchmaking pool you probably do not have, and a support burden — because a multiplayer title fails in ways players report as "the site is broken" rather than "this game is bad".

Most of the social pull is available without any of it:

• Leaderboards and daily challenges run on your own backend, outside the game, and work with the single-player catalogue you already licensed.
• Asynchronous play — beat a stored score, race a recorded ghost, take a turn and get a notification — needs a database, not a live socket.
• Same-device two-player titles deliver genuine head-to-head play with zero networking, and they are unreasonably effective on a tablet at an event or in a waiting area.
• Tournaments are a scheduling and prize layer over single-player scores. Operators run these successfully all the time without a single game server.

And the case where the answer really is real-time: you want a competitive flagship that people come back to daily, you have the concurrency to fill lobbies, and the title is the product rather than one of a thousand. That is a commissioning or in-house build decision, with an operations budget attached, not a line in a catalogue licence. If that is your plan, budget for a team, not a file transfer — a stock catalogue licence is the wrong instrument and any licensor who tells you otherwise is selling you a lobby screen.

📋 What to Put in Scope When You License HTML5 Games With Multiplayer In Them

Licensing directly from a company that owns and develops its catalogue is what makes these questions answerable rather than escalated. Forestry Games has operated since 2017 and licenses a catalogue of 1,049 titles spanning HTML5 and Android APK builds, with in-house HTML5 development for cases where a stock title does not fit the deployment.

For a portal that wants social play without an infrastructure programme, the practical scope is: HTML5 builds you host on your own domain, a written statement of what each build calls at runtime, APK builds where the placement is an Android device rather than a browser, and source access where a title needs its networking or its chat behaviour changed. A catalogue at that scale matters less as raw breadth than as the ability to fill a portal with titles that carry no live dependency, then add social mechanics — leaderboards, daily challenges, tournaments — in the layer you control. Browse the HTML5 games catalogue or the full catalogue and shortlist on that basis before you talk about server architecture at all.

🧸 Licensing Branded Games Alongside the Social Layer

Where the draw is a recognisable character rather than a mechanic, branded content does the work that multiplayer was being asked to do — it gives players a reason to come back that does not depend on another player being online. 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 it for campaigns, portals, events and apps.

Branded licences carry their own approval process covering what a game may contain, where it may run, for how long and in which territories — and that approval process is a reason to keep chat and user-generated nicknames out of a branded title unless the rights holder has explicitly signed off on moderation. Bring your territories, dates and platforms to the first conversation. If the intended use is a campaign rather than a permanent portal, start with the campaign games route and ask for a licence scope written around the campaign window.

✅ What to Do With This Before Your Next Licence Call

Open the shortlist you are already working from and split it in two: titles that are files, and titles that are dependencies. The first group is a hosting decision. The second is an operations decision with a legal tail, and it deserves its own paragraph in the agreement rather than inheritance from the paragraph about everything else.

Then decide honestly whether you need it this year. A portal with a strong single-player catalogue, a leaderboard, a daily challenge and a monthly tournament is a better product than a portal with twelve .io titles nobody can find an opponent in. If you conclude you do need real-time play, buy it with the nine questions above answered in writing, and pick a stack you could take over. When you are ready to price the catalogue itself, buy HTML5 games from a direct licensor and get hosting, branding, territories and runtime dependencies into the scope document on the first call rather than the fourth.