The hard part of a playable isn't making it fun. It's making it fun inside the network's size cap, loading fast enough on a mid-range Android, and passing review without three rounds of rejections.
We build in Luna and hand-rolled HTML5, from your existing Unity project. Every playable below is live — click and play them.
These are the shipped builds, unmodified — same single HTML file the network receives. Click one to load it; it runs exactly as it would in an ad slot. Every one is under 2.8 MB.
Sizes below are the real file sizes, not estimates — open dev tools and check.
This is the whole job. Everything else is polish.
Studios usually discover these after the network bounces the build. We design around them from the start.
Every network sets a hard ceiling, and they differ. A playable that passes on one network gets rejected on another purely on file size — so textures, audio and atlases get budgeted before a line of gameplay is written.
Luna doesn't support everything Unity does. Reflection, certain generics and some third-party SDKs simply won't convert — knowing which, before you build, is most of the skill.
Most networks want one self-contained HTML file with everything inlined. Assets that load at runtime break the moment they're served from an ad slot.
Each network exposes its own CTA API. Get it wrong and the playable runs perfectly but never sends anyone to the store — which is the entire point.
Most impressions aren't on a flagship. A playable that's smooth on your test device and drops frames on a three-year-old Android is a playable that loses installs.
UA teams don't need one playable. They need a steady stream of variants to test — so we're set up for throughput, not one-offs.
We pick the one mechanic worth showing. Most weak playables fail here — they try to show the whole game in twenty seconds.
Once the base is built, alternate hooks, endings, difficulty curves and CTAs are cheap. That's what gives your UA team something to test.
Size, packaging, CTA and device testing checked against each target network's spec before it reaches you — so review isn't where problems surface.
For a Luna build, yes — under NDA. If the project can't be shared, we can build the playable from scratch in HTML5 to match your art and mechanic instead.
It depends on the mechanic and how the project is built. Variants off an existing base are much faster than the first one — that's usually where the throughput comes from.
Yes, and it's the first constraint we design to rather than the last thing we fix. Tell us the network and the cap up front.
Yes — each gets its own build with the right CTA API and packaging. One creative, several compliant outputs.
That's the usual arrangement — a monthly retainer producing a set number of playables and variants. See engagement models.
We'll build the first playable at our cost. Run it against whatever you're using now and judge it on the numbers.