Why Playable Ads Need a Specialized Build Pipeline

Playable ads are not ordinary mobile web pages. They are interactive, lightweight, single-file HTML applications that must load in under 2 seconds, occupy less than 5 MB, and run flawlessly inside an MRAID-compatible ad container. Building one from scratch is hard enough. Building a pipeline that generates dozens of variants across multiple ad networks—MRAID, Vungle DAPI, Meta FbPlayableAd, TikTok Pangle—is an entirely different challenge.

That is exactly what PlayableAd Studio solves. It takes a Cocos Creator game project and runs it through a multi-stage build pipeline that outputs production-ready playable ads in all major formats. This post walks through the pipeline architecture end-to-end.

Stage 1: Cocos Creator Project to HTML Bundle

Every playable ad starts as a Cocos Creator 2.4.x project. The pipeline uses the Cocos CLI to build for the web-mobile platform, producing a standard HTML5 bundle with a main.js, style.css, and the project.jsc asset pack.

```bash

cocos build -p web-mobile

```

This generates a `build/web-mobile/` directory containing the compiled game. The key output is `main.js`—a single JavaScript bundle that includes all game logic, scene definitions, and asset references.

Stage 2: Single-File HTML Assembly

The web-mobile build is not a single file. It has separate HTML, CSS, and JS files plus an `assets/` directory with textures, audio, and font files. The pipeline's first transformation is to inline everything into a single playable-friendly HTML file.

```javascript

// Simplified assembly logic

const html = fs.readFileSync('build/web-mobile/index.html', 'utf8');

const css = fs.readFileSync('build/web-mobile/style-mobile.css', 'utf8');

const js = fs.readFileSync('build/web-mobile/main.js', 'utf8');

const assets = fs.readFileSync('build/web-mobile/assets/main/config.json', 'utf8');

const assembled = html

.replace('</head>', `<style>${css}</style></head>`)

.replace('</body>', `<script>${js}</script></body>`);

```

The single-file output is typically 800 KB to 1.5 MB depending on the game's asset count and complexity. The pipeline then runs a series of optimizations: dead code elimination, texture stripping, and audio compression.

Stage 3: MRAID 3.0 Integration

MRAID (Mobile Rich Media Ad Interface Definitions) is the standard API that bridges the creative with the ad container. PlayableAd Studio's pipeline injects the MRAID bridge script automatically.

The MRAID layer handles:

- **Viewability detection**: The ad knows when it is visible (using `mraid.isViewable()`)

- **Play/pause lifecycle**: Pauses the game when the user scrolls away

- **Click-throughs**: Routes `mraid.open()` calls to the ad network's click handler

- **Resize events**: Responds to orientation changes within the ad container

```javascript

// MRAID bridge injected during assembly

if (typeof mraid !== 'undefined') {

mraid.addEventListener('viewableChange', (isViewable) => {

if (isViewable) {

cc.director.resume();

} else {

cc.director.pause();

}

});

}

```

Stage 4: Multi-Network Output Generation

This is where the pipeline really shines. From the same assembled single-file HTML, it generates format-specific builds for each ad network:

|--------|-------------|---------|--------------|

The pipeline uses a template system where each network has a wrapper template with the correct API surface. The assembled game is injected into each template, then the appropriate compression is applied.

Stage 5: Asset Optimization & Size Budgeting

Size is the biggest constraint for playable ads. Networks enforce strict limits—Meta caps at 5 MB, TikTok at 3 MB, and Google at 2 MB. The pipeline runs aggressive optimization:

1. **Texture quantization**: Reduces PNG/JPEG quality to the minimum acceptable level

2. **Audio stripping**: Converts to low-bitrate mono or removes background audio entirely

3. **Font subsetting**: Removes unused glyphs from custom fonts

4. **Dead code removal**: Treeshakes unused Cocos Creator components from the JS bundle

```bash

Optimization stats for a typical build

Before: 4.2 MB (25 assets)

After: 1.8 MB (optimized textures, stripped audio, tree-shaken JS)

Savings: 57%

```

Stage 6: CI/CD Automation

The entire pipeline runs as a GitHub Actions workflow. When a game designer pushes a new Cocos Creator build to the `playables/` directory, the pipeline automatically:

1. Detects the new project via a filesystem watcher

2. Builds with Cocos CLI

3. Assembles the single-file HTML

4. Generates all network variants

5. Runs size validation (fails if any variant exceeds 5 MB)

6. Creates a ZIP package for each network

7. Uploads to a release page for download

8. Posts a summary to the team Slack channel

```yaml

Simplified GitHub Actions trigger

on:

push:

paths:

- 'playables/**/project.json'

```

Real-World Results

Before PlayableAd Studio's pipeline, generating a playable ad for 4 networks took a developer roughly 4 hours of manual work: building, inlining, testing, and packaging each variant separately. Now the same process takes under 3 minutes from push to packaged output.

| Metric | Before | After |

|--------|--------|-------|

| Build time per variant | ~1 hour | ~30 seconds |

| Number of variants per campaign | 1-2 | 8-12 |

| Size violations | 40% of builds | <5% of builds |

| Developer time per playable ad | 4 hours | 10 minutes |

Next Steps

We are working on a variant generation engine that takes a single high-fidelity game build and automatically produces simplified, smaller variants for networks with tighter size limits. The engine will remove decorative assets, simplify particle effects, and reduce frame rates based on each network's profile—all without designer intervention.

The pipeline is also being open-sourced as a reusable GitHub Action. If you build playable ads with Cocos Creator, this will save you hours per campaign.

From Cocos Creator to MRAID: Inside PlayableAd Studio's Build Pipeline