Pick your engine

FRVR SDK ships integrations tuned to four common game‑engine stacks. Pick yours and jump to its quickstart; the module pages cover the underlying concepts (ads, IAP, analytics, …) and work the same way across all four.

Engine	Who it’s for	Integration style	Quickstart
Web / JavaScript	PixiJS, Phaser, plain Canvas, WebGL, or any framework that compiles to JS	Two `<script>` tags + `window.FRVR.*` calls	Web quickstart
Unity	Unity games exported to WebGL	`.unitypackage` with a C# wrapper (`FRVRSDK.Ad.`, `FRVRSDK.IAP.`, …)	Unity quickstart
Cocos Creator	Cocos Creator 3.8.0+ built for web	Extension that exposes `FRVRSDK.instance.*` to TypeScript	Cocos quickstart
Construct 3	Construct 3 games built for web	C3 plugin — drop a FRVR SDK object in your project, then use events/actions	Construct 3 quickstart

What they have in common

Same underlying SDK, different API shape. Each wrapper exposes the flavour that’s idiomatic in its engine — JS promises for web, C# callbacks for Unity, a TypeScript singleton for Cocos, events/actions for Construct. The JS SDK’s full surface is the superset; Unity/Cocos/Construct expose the pragmatic subset each engine actually needs.
FRVR picks the channel bundle for you. Your game code is the same across web, Facebook Instant, iOS, Android, Samsung, Xiaomi, … FRVR’s release pipeline injects the right channel bundle per release.
Local dev uses the dev channel. All four wrappers load frvr-channel-dev for you locally, which stubs ads / IAP / storage so you can walk the flows without a live provider.
You can’t pick a production channel yourself. Wrappers don’t expose a way to load frvr-channel-facebook-instant.min.js etc. directly in your source — that’s FRVR’s job.

Decide in one line

Raw HTML5 (PixiJS / Phaser / custom JS)? → Web.
Exporting from Unity to WebGL? → Unity.
Publishing from Cocos Creator? → Cocos.
Building in Construct 3? → Construct 3.

Once you’ve done the quickstart, every module in the sidebar applies to you — Ads, IAP, Analytics, Leaderboards, etc.