Design within the game sandbox
Know which browser capabilities belong to the host.
Supported boundary
The frame is sandboxed with scripts allowed and without normal same-origin privileges. The SDK uses the established bridge to ask the host for platform actions. Your game does not need to implement the bridge handshake.
| Avoid in game code | Use instead |
|---|---|
| Direct network calls, sockets, beacons or remote scripts | SDK features and packaged project assets |
| Browser storage and cookies | llvls.save |
| Parent navigation, popups and fullscreen requests | Host controls |
| Custom login, purchase or leaderboard interfaces | Corresponding host SDK flow |
| Dynamic code evaluation or string-built imports | Static modules and supported libraries |
| Remote fonts, SVG or arbitrary uploaded file types | Accepted media and system fonts |
Develop against the restriction
- Remove incompatible APIs while porting a game.
- Use static imports for local code and JSON.
- Load image/sound paths through the SDK helpers.
- Keep personal information and secrets out of game code, logs and analytics.
- Choose Run and resolve its findings. Publishing performs additional checks before the release can go live.
- Test the isolated frame, not only a permissive standalone web page.
The build scan and browser isolation are complementary. A build succeeding does not grant general networking or storage permissions. Do not obfuscate a blocked call to make the scanner miss it.
SDK asset helpers can read the build’s own permitted files. That narrow access is not a general HTTP client. The host performs authenticated service work outside the game.