导言

PA 开发与打包实践 · 01 入门篇
写给第一次接触试玩广告的你：从一个简单玩法开始，看懂开发、打包、测试与交付。

最近做了几批 PA 项目，工作内容从替换素材、调整界面，到生成不同渠道的文件，再到测试和交付。做下来才发现，一个看起来只有几十秒体验的小广告，背后也有一套完整的开发流程。

如果你第一次接触 PA，可以先把它理解成：用户不用先安装游戏，就能直接操作的一小段试玩体验。

PA 是 Playable Ads 的缩写，也就是试玩广告。普通视频广告让用户看，试玩广告让用户亲手点一下、拖一下，或者完成一个简单的挑战，再决定要不要下载。

这篇文章不从复杂的代码讲起，而是顺着一个项目，看看它怎么从想法变成可以交付的文件。

阅读导航

• 01 · 先想清楚用户要做什么
• 02 · 准备素材和产品信息
• 03 · 让画面真正动起来
• 04 · 打包到底在做什么
• 05 · 为什么会有很多份文件
• 06 · 生成文件以后真正玩一遍
• 07 · 把正确的文件交出去

01–先想清楚用户要做什么

假设我们要做一个整理物品的试玩广告。

用户打开画面后，看到几个物品和对应的收纳位置。一个手指提示告诉他可以拖动。物品放对了，会出现动画和声音；完成几次操作以后，画面展示结果，并出现下载按钮。

体验很短，但开发前仍然需要回答几个问题：

• 用户第一眼应该看哪里？
• 他怎么知道可以操作？
• 操作成功或者失败，会得到什么反馈？
• 体验什么时候结束？
• 点击下载按钮后，应该前往哪个产品？

这些问题决定了后面的画面、代码和测试内容。

刚开始做项目时，很容易先关心“按钮好不好看”“动画够不够炫”。但如果用户看不懂第一步要做什么，再精致的画面也很难发挥作用。

所以，我更愿意先把完整体验写成一句话：

用户跟随提示拖动物品，获得反馈，完成挑战，最后看到下载入口。

有了这条主线，再去补充细节就容易多了。

02–准备素材和产品信息

做 PA 会用到背景、角色、按钮、图标、音效等素材。有些项目还会提供设计稿，告诉开发者每个元素放在哪里、应该是什么样子。

素材准备看起来很基础，却很容易影响进度。

比如背景已经换成新主题，结束页面还留着旧产品的名字；图标换好了，下载按钮却仍然指向旧商店地址。画面可能正常运行，但内容已经不一致。

因此，开工前需要核对的不只是“有没有图片”，还包括：图片是不是这次批准使用的版本，文件能不能正常打开，产品名称和图标是否对应，商店地址是否正确，以及这次究竟需要哪些语言和渠道。

在我们的流程里，还会区分两种任务：

前一种通常需要更多画面适配。后一种改动较少，但产品信息仍然必须认真核对。

03–让画面真正动起来

以我们使用的 Cocos Creator 工程为例，可以把它理解为一个制作互动内容的工作台。

开发者把背景、物品、按钮放进场景，再通过代码规定它们的行为：物品什么时候可以拖动，放到正确位置后发生什么，什么时候播放声音，什么时候显示结束页面。

这里有一个很容易忽略的区别：设计稿是一张静止的画面，试玩广告是一段持续变化的体验。

静止时位置正确，不代表拖动时不会遮挡。竖屏看起来舒服，不代表横屏还能看清。中文按钮放得下，也不代表换成更长的外语文案后不会挤出边框。

所以开发过程中，需要反复运行和操作，检查真实体验，而不只是对着一张截图调整位置。

一个很实用的办法，是从用户打开广告开始，一直操作到最后：

打开画面 → 看懂提示 → 完成操作 → 获得反馈 → 进入结束页 → 点击下载

看得懂提示吗？第一次操作顺畅吗？动画结束后还能继续吗？结束页面有没有正常出现？下载按钮是否有效？

先让这条流程完整跑通，再去打磨视觉和手感，通常更容易发现真正影响体验的问题。

04–打包到底在做什么

开发工程里有很多文件：代码、图片、声音、配置，以及编辑器需要的资料。广告平台不会直接使用这一整个工作目录。

打包，就是按照目标渠道的要求，把需要的内容整理成可以交付的成品。

在我们的项目里，常见成品是 HTML 文件，有些渠道使用 ZIP 压缩包。具体格式由对应渠道的要求决定。

可以把开发工程想象成厨房：食材、工具和制作过程都在里面。打包后的文件则是准备交出去的成品，接收方需要能直接使用它。

这也是为什么“在编辑器里能玩”，还不能说明“已经可以交付”。

打包后可能出现资源没有带全、声音没有正常播放、按钮没有接上平台接口等问题。真正要检查的，是最终生成的那个文件。

05–为什么会有很多份文件

因为同一套玩法，可能要服务不同产品、不同渠道和不同语言。

例如，同一个整理玩法，可以分别生成产品 A 的英文版本、产品 A 的日文版本，以及产品 B 的英文版本。它们的玩法相同，但部分内容和配置不同。

如果每一种组合都复制一个工程，后面修复同一个问题就需要到处修改，很容易漏掉。

我们逐渐采用的方式是：保留一套主要工程，把不同产品、渠道和语言的差异放进配置，再按需要生成对应文件。

记住这一点
看到很多交付文件，不一定意味着开发了很多套游戏。它们可能来自同一个工程。

另外，我们也会生成专门用于录屏的 HTML 版本，方便录制操作过程。录屏版本和正式投放版本的用途不同，需要分清。

06–生成文件以后真正玩一遍

我现在会把检查分成几个层次。

1. 检查文件本身。 能不能打开，体积是否符合本次要求，图片和声音是否完整。
2. 检查体验。 引导是否清楚，玩法能不能走到结束，横竖屏是否正常，不同语言是否显示正确。
3. 检查平台上的表现。 广告能否在目标环境中正常工作，下载按钮是否调用了正确的跳转方式。

这几层检查互相补充。本地浏览器里打开成功，只能证明一部分事情，不能自动代表真实广告平台也通过了。

对于需要人工试玩的环节，我们会把具体待测文件交出去，并记录测试对应的是哪一版。如果后来又修改了文件，就要判断之前的测试结果是否还适用。

07–把正确的文件交出去

任务多了以后，目录里很容易出现“最终版”“最终修改版”“最终确认版”。

名字越来越肯定，人反而越来越不确定。

因此，我们会维护一份交付清单，记录正式文件的位置、对应产品和渠道，以及哪些旧文件已经被替换。上传后也要核对文件有没有漏传、传错。

这样，后续同事不需要猜哪个文件能用，隔一段时间回来也能查清楚当时交付了什么。

做完这些项目以后，我对 PA 的理解逐渐变得具体：它有玩法开发，也有素材整理、渠道适配、测试和版本管理。

如果你准备开始第一个 PA 项目，可以先完成一段很小的体验：一个明确的操作，一次清楚的反馈，一个正常的结束页面，再把它打包并从头玩到尾。

当这条流程走通以后，多产品、多语言和自动化打包，就有了可以继续扩展的基础。