从 Unity 原工程迁移到微信小游戏试玩广告：一次三国 5V5/BOSS 试玩的实战记录
最近尝试把一个原本 Unity 开发的三国题材联网小游戏，拆出一版适合广告投放的微信小游戏试玩版本。目标不是完整复刻原游戏，而是在较小包体、较短体验链路里保留核心卖点：武将、Spine 动画、战斗反馈、BOSS 压迫感和结算转化。
目标
这次试玩主要做了几个版本，最终重点落在 BOSS 招募玩法：
玩家进入后看到 BOSS 居中压场，底部有 5 个武将卡片。点击一个武将，武将立即上阵战斗；继续点击就继续补人，最多 5 人。战斗过程中 BOSS 掉血，武将有攻击表现、血条、音效和受击反馈。结束后弹出成功/失败结算，并支持重新体验。
相比传统“点按钮释放技能”的试玩，这个版本更强调一个很短的操作闭环：
点击武将 → 立即上阵 → 战斗变强 → BOSS 掉血 → 继续补人 → 结算反馈。
资源复用
资源主要来自原 Unity 工程，包括：
场景背景图
武将 Spine 资源
BOSS Spine 资源
战斗特效 Spine 资源
战斗音效
中文字体
为了方便后续多方案打包，每个试玩版本都尽量独立放在自己的场景和资源目录里，避免互相污染。这样后面要做 A/B 测试、换玩法、换入口，都比较好维护。
适配重点
微信小游戏试玩广告最容易出问题的不是战斗逻辑，而是适配和包体。
这次遇到几个典型问题：
编辑器正常，小程序预览位置错乱。
iPhone 刘海屏安全区导致 UI 偏移。
中文字体在小程序里显示异常。
试玩包超过微信预览限制。
微信转换插件里“试玩转换”和“小游戏转换”的配置逻辑不一致。
最后适配逻辑统一放回 Unity 里处理，而不是在微信开发者工具里临时修。这样编辑器、构建、预览的表现更一致。
中文字体处理
小程序里不能完全依赖默认字体，尤其是战斗 UI 中有大量中文，比如“魔化吕布”“已上阵”“点击武将”等。直接引入完整中文字体会明显增加包体，所以最终使用了字体子集。
做法是只保留试玩中实际出现的汉字，把字体压到几十 KB。这样既解决中文显示问题，又不会明显影响包体。
微信小游戏配置
最终按当前测试方案，首包资源走“小游戏包内”，不走 CDN：
首包资源加载方式：小游戏包内
压缩首包资源：不勾选
WebGL2：开启
IL2CPP Optimize Size：开启
横竖屏：Portrait
Heap：256MB
同时新增了一个 Unity 菜单导出入口，避免每次手动配置出错：
Playable Ads/Export Boss Recruit WeChat MiniGame Package
这个菜单会自动设置 Boss 试玩场景、微信小游戏配置，并执行导出。
经验总结
这类试玩广告开发，不能只把它当成“小游戏裁剪版”。它更像一个独立的小产品，需要从体验路径重新设计：
操作要足够短，最好 1 秒内看到反馈。
角色、BOSS、血条位置要服务于第一眼理解。
文案要少，但关键状态必须清楚。
资源复用要克制，保留最能体现原游戏品质的部分。
包体和适配要从一开始就考虑，不要最后才补。
这次最大的收获是：原工程资源和表现可以复用，但广告试玩的工程组织、适配方式、导出配置最好独立沉淀下来。这样后面继续做新玩法，不会每次都重新踩一遍微信小游戏转换、字体、包体和安全区的问题。
