Wrap every portal SDK and ad network behind one internal interface (adapter pattern): your game code calls generic functions like showInterstitial() or saveScore(), and a per-platform adapter translates that into the right SDK call, loaded conditionally at runtime.
At a glance
| Fact | Value | Source |
|---|---|---|
| Pattern used to isolate portal SDKs | adapter/facade layer | |
| Revenue formula for ad integrations | requests x fill rate x eCPM/1000 | playgama.com |
| Higher-earning ad formats | full-screen formats | playgama.com |
Don’t scatter portal-specific and ad-network-specific calls through your gameplay code. Put a single internal interface between your game logic and every external SDK – one function per action (show interstitial, show rewarded, save score, unlock achievement) – and write a thin adapter for each platform that translates the generic call into that platform’s real SDK call. Your game only ever talks to your own interface, so adding or removing a portal means writing one new adapter, not touching gameplay code.
A cross-platform SDK layer built for this job, such as Playgama Bridge, handles this setup and lifecycle messaging for you across supported portals, so your game code calls one consistent API instead of maintaining separate branches per platform.
How do I keep ad calls separate from portal calls?
- Detect the platform once at startup (query param, hostname, or a build flag) and load only that adapter – don’t ship every SDK’s script tag on every build if you can avoid it.
- Keep ad-break calls (interstitial, rewarded) behind your own wrapper too, since placement rules differ: Google’s H5 Games Ads calls adBreak() at natural pauses, with its own frequency cap, while other networks expose their own call signatures.
- Log ad requests, fill rate and eCPM per platform separately – revenue is requests x fill rate x eCPM / 1000, and formats and geos both swing that number, so mixing platforms in one report hides which one underperforms.
- For engines: Unity WebGL reaches browser JavaScript through a .jslib plugin; Godot 4 uses the JavaScriptBridge singleton. Wrap those calls once, not per feature.
Test each adapter in isolation before merging – a broken portal SDK should never be able to crash gameplay code.
Sources
- Playgama Ad
- Playgama Bridge: getting started
- Google Ad Placement API: adBreak
- Unity manual: interacting with browser scripting
- Godot docs: exporting for the Web
Related questions
Should I load all portal SDKs on every build?
No – detect the platform at startup and load only the matching adapter and its SDK script, to avoid unused code and conflicting global variables.
How do I test multiple ad networks without breaking gameplay?
Wrap ad calls behind your own interface, mock that interface in gameplay tests, and test each network adapter separately before combining them in a build.
Last updated: 24 September 2026