From a Unity Game to a Playable Ad: What Transfers and What You Rebuild

The question arrives in some form on most game teams: the game is already built in Unity, Unity exports to WebGL, a playable is HTML5, so why not just ship the build? It sounds reasonable and it fails at the first step. Knowing exactly where it fails saves a week, because the answer is not a workaround but a different production path with a different owner.

Why a WebGL build cannot be a playable ad

Three separate constraints each rule it out on their own.

Size. Networks cap a playable at around 5 MB, and Meta additionally requires the index.html itself to stay under 2 MB. An empty Unity WebGL project (no gameplay, no art, no audio) lands somewhere between roughly 1.8 MB and 12 MB depending on render pipeline, code stripping and whether Brotli compression is used. The reported floor of about 1.8 to 2.2 MB is reachable only with the built-in render pipeline, aggressive stripping and unused packages removed. That is the empty project. A real game with art and audio in it is past every cap before you add a single sprite.

Packaging. A playable must be one self-contained file that makes no network requests. A Unity WebGL build is a loader script plus a separate WebAssembly module, a data file and a framework file, which the loader fetches at runtime. Inlining all of those as data URIs would add roughly a third again in size to something already far too large, and several networks reject the pattern outright regardless.

Load behaviour. Even where a container tolerated the size, the format is judged on time to first interaction. A WebAssembly module has to download, compile and initialise before anything appears, and a creative that shows a loading bar for several seconds loses in the auction before anyone judges the creative at all.

What does transfer

Quite a lot, and it is the expensive part. What you rebuild is a few seconds of interaction logic. What you reuse is everything that took the art and design team months.

• Sprite atlases and UI art, at the resolution the ad canvas actually needs rather than the resolution the game ships at.
• Character and effect animation, baked to frame sequences or re-authored as a short loop rather than carried as a runtime rig.
• The colour palette, typography and UI language, so the ad and the first screen after install look like the same product.
• Tuning constants (movement speed, gravity, timing windows, the curve of a merge), which are what make the ad feel like the game rather than merely look like it.
• Audio stings for the success moment, which cost nothing to reuse and are usually already short.

Pulling assets out of the project

Take the source art, not the build output. Unity's build pipeline compresses textures into GPU formats intended for a runtime, which are wrong for a webview and lossy in ways that stack badly with a second compression pass. The originals in the project's asset folders are what you want.

Then resize before you convert. A sprite authored at 1024 pixels for a tablet-resolution game may occupy 120 points on the ad canvas, and shipping it at source resolution is the most common single reason a playable is unnecessarily large. Resize to roughly twice the on-canvas size, then convert: WebP for photographic and painted art, PNG only where you need crisp edges on flat colour with transparency.

For animation, decide between a frame sequence and re-authoring. A short sequence at a modest frame count is simple and predictable; anything longer is usually cheaper to rebuild as a tween on a static sprite, which also gives a result that scales cleanly with the canvas rather than being locked to the resolution it was rendered at.

Rebuilding the loop

The rebuild is smaller than it sounds, because you are not reimplementing the game. You are implementing one mechanic, for one board, for about eight seconds, with a guaranteed resolution. There is no save system, no economy, no progression, no settings, no analytics and no failure recovery. Those are most of what a game is, and none of them appear in an ad.

In practice this is a scene with a handful of objects, a rule about what a valid move is, and a win condition. A no-code editor covers it without a developer: Playable Ads Maker's Game Templates ship the common mechanics as re-skinnable plugins, and the Break System covers tap, hold and traced-path interactions where a full mechanic is more than the ad needs. The export produces the single inlined HTML file, with the correct store-exit call per network already wired.

Keeping the ad honest against the live game

Because the ad is a rebuild rather than a slice of the real build, it can drift from the product, and drift is exactly what platform policy on misleading creative is aimed at. The rule is that the mechanic in the ad has to be one the player meets in the app, behaving the way it behaves there. Simplification is allowed and expected; invention is not.

Two habits keep this from becoming a problem. Re-derive tuning constants from the current build rather than from a designer's memory of it, and re-check the ad against the game whenever the game changes the mechanic being advertised. A creative that was accurate at launch and is no longer accurate after a rebalance is still a policy problem.

When the game is not in Unity

Nothing above is Unity-specific. Unreal, Godot, Cocos and native engines hit the same three walls (size, packaging, load behaviour) for the same reasons. Godot's web export is smaller than Unity's and still far past a 5 MB single-file budget once there is content in it. The pipeline is identical in every case: extract the art and the tuning, rebuild the interaction for the format, and treat the ad as a creative asset rather than a build target.

A realistic first pass

1. Pick the one mechanic that best states your claim, and write the win condition down in a sentence.
2. Export the source art for that mechanic only: board pieces, one character, the success effect, the UI frame.
3. Resize each asset to about twice its on-canvas size and convert to WebP, keeping PNG only where transparency over flat colour demands it.
4. Rebuild the loop in an HTML5 editor with a guaranteed resolution inside about eight seconds.
5. Copy the tuning constants from the live build so the timing and motion match the product.
6. Export per network, confirm the file lands well under the cap, and test on a real low-end Android device rather than a desktop browser.