What Playworks/Luna is actually good at
Playworks/Luna (the plugin most people still call by its old name, Luna) is Unity's own tool for turning a Unity scene into a browser-playable ad, and it does that part natively. You install it through the normal Unity Package Manager flow — Window > Package Manager > + > Add Package From Disk, pointed at the plugin's script/package.json — and once it's imported, it lives inside the editor as its own menu: Tools > Playworks (Ctrl+E on Windows, Cmd+E on Mac).
From there the workflow stays entirely inside Unity. You pick the scenes to include, confirm the startup scene, open the Build & Upload tab, and click Build Develop. When the build finishes, Open In Browser launches a working preview right there — no export to a separate tool, no round-trip through another engine. That's a real, meaningful convenience: you never leave the editor, and what comes out the other end is a genuine playable build, not a rough draft that needs re-assembly somewhere else.
For teams already standardized on Unity, that alone answers a big chunk of "worth it." You're not adopting a second toolchain to get a playable out of a Unity project — you're using the one Unity ships support for.
What it doesn't solve — and this is the part that gets skipped
Where the "worth it" question gets more honest is what happens after Build Develop finishes. Playworks/Luna generates its output as a ZIP inside the project folder — typically at ProjectRoot\LunaTemp\stage4\create-hub — and that ZIP is a single build. It runs. It is not, on its own, a Google Ads-ready package, or an AppLovin-ready package, or a Mintegral-ready package. Each network has its own rules for what a submittable playable has to look like, and none of them are optional:
- Click-through wiring differs by network. Google expects a
clickTagvariable paired with its own ExitApi script. AppLovin and Unity Ads expect an MRAIDmraid.open(url)call. Vungle's primary CTA iswindow.parent.postMessage('download','*'), with MRAID as a fallback. Mintegral expectswindow.install(). TikTok expectswindow.openAppStore()through its own Playable SDK. Meta expectsFbPlayableAd.onCTAClick(). A Playworks/Luna export doesn't arrive pre-wired for all six. - Several networks require a fully self-contained file. AppLovin, Meta, Unity Ads, and Vungle all prohibit external requests and want a single HTML file with every image, font, and audio clip embedded — not referenced by a relative path the way a browser-tested build normally works.
- Size caps are real and unforgiving. Most networks cap creatives around 5 MB, with Meta and Unity Ads specifically recommending closer to 2 MB. Once assets that were loading fine from disk get properly inlined for one of the networks above, file size can jump past the limit without the build itself having changed at all.
- Package shape has to match each network's expectations. Mintegral wants the ZIP name, the top-level folder, and the HTML filename to all match. TikTok wants a first-level
index.htmlalongside aconfig.jsondeclaring orientation. Google wants an orientation meta tag and a ZIP under 512 files.
None of this is a Playworks/Luna flaw. It's the same adaptation work regardless of which engine or export tool produced the original build — Playworks/Luna just isn't the layer that's supposed to do it, and it never claimed to be.
| Step in the pipeline | Handled by Playworks/Luna |
|---|---|
| Build a working playable from a Unity scene | Yes — natively, in the editor |
| Preview the build in a browser before shipping | Yes — Open In Browser |
| Per-network click-API wiring (clickTag, MRAID, SDK calls) | No — same manual work regardless of source engine |
| Asset embedding for single-file networks (AppLovin, Meta, Unity Ads, Vungle) | No |
| Meeting each network's size cap after assets are embedded | No |
| Package shape / config.json per network (Mintegral, TikTok) | No |
The honest verdict
Playworks/Luna is worth it if the premise is "I want to build playables without leaving Unity." It delivers exactly that, and does it reliably as a native Package Manager plugin rather than an external converter you have to trust with your source project. If your team is already in Unity for the core game, adding Playworks/Luna costs you a plugin install and a menu, not a new pipeline.
Where "worth it" gets murkier is if the underlying question is really "will this get my playable running correctly on every network I need." It won't, because that was never the job. The actual bottleneck most teams hit isn't building the playable — it's the second, invisible step of re-adapting that one export for Google, Meta, AppLovin, Mintegral, TikTok, Unity Ads, and Vungle, one at a time, by hand, every time a creative ships or changes. Teams running to one network barely notice this. Teams running to three or more feel it every release cycle.
LunaTemp\stage4\create-hub as usual, and upload that same export to PlayableKit once. From there it applies the click-API wiring, asset encoding, size handling, and package shape each network actually requires, and produces a separate, compliant package per network from that single source build.
What it costs to find out
PlayableKit's plans start at Starter, $400/mo, scale to Studio, $560/mo and Scale, $800/mo for broader network access and build volume, with an Enterprise tier priced individually for larger teams. Before committing to any plan, you can upload a real Playworks/Luna export to the free playable ad validator and see exactly what a compliance check flags per network, with no account required.