Created with Cocos | 新华社&抖音推出爆款小游戏，专访技术负责人聊聊背后的逻辑

过去一年，有哪些事件在你的记忆里熠熠生辉？在这个年末，新华社携手抖音串联全年记忆碎片，共同推出小游戏「抖音热点记忆2021」，重温过去一年的震撼与激情、快乐与感动，让热点不再转瞬即逝，今天 C 姐特意邀请了背后的团队，一起聊聊打造这支爆款小游戏的故事。

「抖音热点记忆2021」塑造了一个梦幻的记忆世界，我们将在这里开启「记忆修复之旅」。依据游戏指引完成对一个个场景的探索，即可获得该场景的专属徽章。一个场景探索结束后将解锁两个新场景，任选其一进入便可继续探索。玩家每次可到访5个场景，集齐5枚徽章后将打开2022之门。

游戏共设计有20个热点场景，对应20段闪耀记忆，隐藏在一枚枚徽章后等待玩家前去解锁。跟随男孩/女孩的脚步，我们将重新发现今年的感动、悲喜、勇气、骄傲，和2021好好告别，开启2022的全新篇章。

这样一个饱含巧思的游戏化交互作品，由字节跳动抖音热点团队和创意游戏团队联手制作，我们邀请到了「抖音热点记忆2021」前端技术负责人游子威，和大家聊一聊这个作品的技术实现亮点。

开发这个游戏的过程中，遇到最大的挑战是什么？

答：这个项目整体开发周期很短，大概只有两个半月。如何在有限的时间中，兼顾开发效率、艺术表现、运行性能之类的技术指标等，对我们来说是个不小的挑战。从现在的成品来看，整体达到了我们的预期，还是比较满意的。

团队是怎样打造高效的开发工作流、确保开发效率的呢？

答：这是我们团队第一次做这类型的 3D 项目，而且项目场景数量比较多，工作流里涉及到的环节也较多，时间紧、任务重，因此我们在开发初期拉了一张很长的甘特图，详细记录了每个环节的制作时⻓和交付时间点，⼤家必须严格遵守这个时间点，否则项⽬真的可能完不成。

整体的研发节奏是滚动式流水线开发，综合考虑人力、时间等因素，我们将项目中的所有场景都分批次来制作。落实到单个场景的制作流程，大概是策划粗案→细案→美术草稿→2D 原画→3D 建模→研发制作，再由策划介入进行一些剧情编辑和美术调优，同时热点团队对呈现效果也会从热点事件的还原和用户感受出发，参与共创，整个流程下来要花上一个月左右。

为什么会选择用 Cocos Creator 进行研发？

答：技术预研阶段我们对目前市场上比较成熟的游戏引擎和 H5 开发工具做了一些调研。Cocos Creator ⾃带了可视化编辑器，⼯作流相对⽐较完善，这对我们而言是一个非常重要的决策点——之后用起来也确实如此，引擎整体上比较符合我们的使用习惯，而且对美术同学、策划同学来说都是一个比较容易上手的工具。

我们也做了一些 benchmark，横向对比了几款引擎。看了官⽅出的「塞尔达 Demo」，认为引擎在艺术表现、性能指标上都⽐较符合我们的预期。此外 Cocos 的开发者社区比较活跃，官方也有布道师、研发人员能提供一定的技术支持，这对我们来说帮助很大。比如我们团队里一半以上的成员之前没接触过 Shader 这方面内容，要想快速学习上手、最终去实现一些表现效果，还是有一定难度的。所以我们邀请麒麟子给团队做了一次技术分享，解答了大家的一些困惑，真的非常感谢！

那么引擎在使用时又有哪些不吐不快的槽点呢？

答：吐槽的话我也是有一些话想说的。我们⽤的是 Cocos Creator 3.3.1，感觉这个版本 IDE 的稳定性还不太够，比如我们遇到过 Prefab 数据丢失、场景引⽤⼀些已经被剔除的资源、动画跳帧等问题，当时是自己开发了⼀些⼯具来检测此类现象。但前段时间 v3.4 修复了这些问题，我们也在 v3.4 测试版中实验了一下，问题的确已经得到了解决。

开发过程中有遇到什么难点吗？或者有没有一些提高研发效率的小技巧可以同我们分享？

答：我们自研了多款插件、或是通过修改引擎源码，去达到一些我们想要的功能和效果。

首先，v3.3.1 没有动画状态机，但这个游戏⾥人物、动物的动作状态切换还是⽐较多的，所以我们简单实现了⼀套动画状态机——当然现在 v3.4 里官方已经新增了动画系统。另外我们美术同学觉得线性混合不太能满足他们的一些艺术想法，因此我们对引擎做了些修改，支持了非线性动作混合。

其次，游戏里用到了大量的路径动画，一个个打点太麻烦，于是我们做了一个 3D ⻉塞尔曲线可视化编辑插件，方便策划同学直接在 3D 空间里制作路径动画。

再有，目前引擎缺少运行时的可视化编辑能力，所以我们做了一个支持可视化编辑节点属性的 chrome 插件 Coconutool，目前已经整理上架到 Cocos Store 了。

最后还有个非常大的难点是镜头动画。原先我们是在游戏运⾏时做⼀个相机姿态关键帧录制能⼒，⽐如按⼀下空格就记录当前相机姿态，然后后续基于相机姿态关键帧⽣成 Catmullrom 平滑曲线，再在曲线上进⾏采样，采样点之间以直线做姿态插值，实际验证这样做出来的镜头动画⾜够平滑，⽽且计算量很⼩。但是后面我们发现这个方法不方便做⾮匀速的相机动画，美术同学想要的一些效果难以达到，最终我们还是妥协了，让美术同学使用 DCC ⼯具来制作。项⽬后期我看到有位⼤神出了可视化智能相机编辑系统 Cinestation 插件（注：插件作者陈炫烨），看过 Demo 效果不错，打算在后续项⽬中尝试⼀下。

小游戏/H5 的加载时间对用户体验有很大影响，这个项目在优化上都做了哪些工作呢？

答：我们整个项目打包构建下来大概有 150M，目前包体 2.1M 左右，优化方面还是花了很多心思的。

1、UI 资源优化。目前整个游戏全部 UI 加起来只⽤了⼀张1024*1024的图集。我们对一些重复资源进行了拆分，能做九宫就做九宫，并对部分大图进行了适当的缩小。

2、Bundle。我们做了两类 Bundle：场景包和 common 包。

• 场景包，zip 包。把场景 Bundle 打成 zip 包，这样用户在进入某个场景的时候，只需要下载这个 zip 包，解压后就可以正常运行游戏了。

• common 包，merge depend。场景会复用到的资源单独成一个 Bundle，叫 common 包。这个包也是非常非常大，如果做成 zip 包网络耗时会很长，所以我们就只简单给它做了个默认的 merge depend 模式的 Bundle。某个场景里要用到某些复用的资源的时候，只需要单独去下载相应的资源即可。

• 在做 Bundle 的过程中我们也遇到了一些问题。因为⽤户⽬录上限 50M，如果总文件大小超过这个上限，zip 包就无法再解压运行。因此我们对引擎进行了修改，进入场景后会先预判接下来可能会是哪两个场景，把资源预下载到临时目录里。等到用户正式选择场景、切换场景的时候，这个场景 bundle 下的所有⽂件缓存会先被清除，然后再去临时目录里看看对应的 zip 包是否还在，如果在，就把它解压到用户空间去，如此就大幅节省了下载时间。

3、unmanaged ⽂件缓存清理。针对用户目录的控制，我们还做了一些其他事情。比如说一些存在用户目录里的大图其实是不受游戏引擎管理的，而是我们直接通过原生小游戏的一些 API 把那些图片下载到本地，所以这一块的文件缓存也需要及时清理。

4、场景资源动态依赖计算。场景有很多复用资源，切换场景时，这些资源其实没必要释放掉再重新去加载，所以我们引入了一个动态的依赖计算。动态计算每个场景依赖的资源，跨场景时比较前后两个场景，相同的依赖自动复用，不需要的依赖自动清理。这样一方面减轻了研发的压力，另一方面也最大程度实现了资源复用。

5、加载策略。我们制定了一个徽章加载策略。当用户的徽章数量少于一半，在打开徽章界面时都是加载散图。但如果用户徽章数量超过一半，如果还是一张张加载散图，加载速度就会更慢。所以我们做了一个调整，若徽章数量超过一半就加载一张整的徽章图集。

6、流程组件。我们自研了一个流程组件，它支持配置的形式，策划可以直接介入去编辑场景里的剧情，既方便了策划创作，也减少了代码大小，解放了研发人力。

7、刨除不需要的库。举个例子，我们在⽴项之初就决定不⽤物理引擎，⼀⽅⾯是因为物理引擎代码较大，另⼀⽅⾯是因为物理引擎在 iOS 上运⾏效率不佳（iOS 不⽀持 JIT）。因此策划在前期提出想法时就会先和研发对一下，看有没有办法用简单的代码逻辑来实现，如果实现不了，可能就需要协调一下是否要换种表现形式。需要⽤到物理的地⽅，我们就⾃⼰去实现⼀套简单的方法。

感谢游子威的分享！希望有更多开发者可以用 Cocos Creator 做出各种动人的作品，向世界传达自己的想法！

往期精彩