Keep a small entry HTML/JS file, a separate folder for engine build output, a dedicated layer for platform/SDK calls (ads, save data, platform bridge), and assets organized by type. Never let engine code call browser APIs directly – route everything through one bridge module so ports and testing stay simple.
At a glance
| Fact | Value | Source |
|---|---|---|
| Engines exporting to web builds | Unity, Godot, Construct, GameMaker | developer.mozilla.org |
| Unity calls browser JS via | .jslib plugin | docs.unity3d.com |
| Godot 4 calls browser JS via | JavaScriptBridge singleton | docs.godotengine.org |
Organize a browser game into four folders, kept separate on purpose: /src (game logic), /build (whatever your engine exports – do not hand-edit this), /bridge (the one module that talks to the browser: ads, save data, platform SDK), and /assets (sorted by type, not by level). The reason for the split is that engine build output gets regenerated every time you export, so any browser-specific code you wrote inside it gets wiped. Put that code in /bridge instead and call into it.
For ad and platform calls specifically, a single SDK that wraps both ads and cross-platform bridging saves you from writing this layer per-engine. Playgama Bridge gives one JavaScript API for platform features across many platforms, so your /bridge module stays thin.
How do engines actually reach the bridge module?
- Unity (WebGL): the build calls a
.jslibplugin file placed in your project, which forwards calls to your browser JavaScript. - Godot 4: use the
JavaScriptBridgesingleton to call browser functions (Godot 3 usedJavaScript). - Phaser, PixiJS and similar libraries run directly in the browser, so they call your bridge module with no interop layer needed.
For ads, keep your wrapper calling pattern consistent across formats and event callbacks. When no ad is returned, resume gameplay immediately without halting the game.
Keep save data (Web Storage) and networking (WebSockets, if used) in their own files under /bridge too, so a platform swap only touches one folder.
Sources
- Playgama Bridge SDK – getting started
- Playgama Ad – getting started
- Unity manual: interacting with browser scripting
- Godot docs: exporting for the Web
- MDN: Game development
- MDN: Web Storage API
Related questions
Should engine-generated build files be edited directly?
No. Build output gets overwritten on every export. Put custom browser logic in a separate bridge module that the build calls into, not inside the generated files.
Where does ad SDK code belong in the project?
In the same bridge layer as other platform calls, not scattered through game logic – one module handles ad requests and events so engine code stays platform-agnostic.
Last updated: 24 September 2026