Cocos Creator 发展趋势与感悟

张晓衡，软件研发经验值十年，后三年专注于手游开发。Cocos 的铁杆老粉、社区活跃份子、简书心得达人。平常喜欢将自己的工作用文字和视频的方式记录，最近更是创建了「奎特尔星球」公众号，通过另类的讲解方式为大众开启了 Cocos 开发的另一扇大门。愿他的经验值能对大家的开发生涯有所帮助。

🔥🔥🔥

转眼间就要到年底了。回首这一年，我使用 Cocos Creator 引擎开发游戏项目已经快一年。依仗着之前 Cocos2d-x JS 经验老本，目前在 Creator 平台上过渡的还算顺利。

10 月 21 日的「深圳站」 Cocos 开发者沙龙期间，我认识了不少 Cocos 高手（引擎组的大咖），了解到更多的 Creator 发展趋试，探讨了游戏开发中的问题，结合当下自己的工作情况，又有了不少的思考和感悟。

1

Creator v1.7 重磅来袭

Creator v1.7 最大的亮点是 JSB2.0。JSB2.0 的本质是底层 Javascript 引擎的更新换代。回想过去，我最早在 2013 年 9 月开始接触 Cocos2d-x JS，直到现在的 Creator v1.6 版本，SpiderMonkey 为 Cocos 服役已经超过了4年，现在终于要谢幕了。

JSB2.0

JSB2.0 迎来的是，两大超级明星级：V8 与 JavascriptCore

• Mac 与 iOS 使用 JavascriptCore

• Windows 与 Android 使用 V8

 JS 引擎变化对 Cocos 项目的影响

1. 在 native 上 JS 层的运算性能有翻倍提升；

2. 在 native 上有更丰富的调试方法，更精准定位问题的手段。我觉得这一点对程序员很重要，因为找问题比改正问题花费更多的时间，有了先进的调试手段，有利于加速 bug 的定位；

3. native 与 H5 环境的 JS 引擎环境更加一致，在开发体验上更加接近；

4. 旧的 Cocos 项目，如果之前编写了 JSB 绑定相关的代码，要升级到 JSB2.0 需要重新编写绑定代码。

在此献上官方 JSB2.0 绑定教程：

github.com/cocos-creator/cocos2d-x-lite/blob/develop/cocos/scripting/js-bindings/docs/JSB2.0-learning-zh.md

2

AssetBundle 隐形的翅膀

Cocos 沙龙上，AssetsBundle 虽然只有较短的文字介绍，但了解到这一未来特性的第一瞬间就被它吸引了，它让我想起一两年前国内各大引擎的 runtime。

当年国内三大游戏引擎，纷纷将 runtime 置入腾讯 QQ 浏览器，号称超级 App 的到来，原生游戏也能点开即玩。那时感觉完全是进入了 H5 的春天。我当时项目做的并不好，有人转 u3d 或 lua，我转了一圈还是决心留在 Cocos2d-x JS 的阵营！后来不知道为什么 runtime 没火起来，反而是 H5 势头越来越猛。

话题扯远了，还是回到 AssetsBundle 上来，我觉得 AssetsBundle 会不会更加模糊原生游戏与 H5 游戏呢？两者都是将代码和资源放到远程服务器，动态加载运行。而且其中还有一句关键“跨项目联动”，不同项目共享 AssetsBundle 资源，那是不是可以将游戏内容转变成一种云服务呢，大家共享？

如果 AssetsBundle 真的能将资源粒度控制的非常精确，原生游戏也具备 H5 的特性，同时还有 H5 不具备的流畅体验，那问题又来了？

Cocos 原生游戏是否不再用为热更新烦恼了呢？
目前流行的棋牌合集游戏，是否不用为游戏大厅和子游戏而发愁？
安装包体积问题是不是也可以由此迎刃而解？

想到这些，小心脏有点受不了，赶快写两行代码压压惊！

所有的 Cocos 游戏都成了超级 App，假想一下会不会出现一种“游戏 SDK ”，就是制作一个 SDK，里面集成了 Cocos2d-x + Creator JS + AssetsBundle。当 App 接入这个 SDK 后，这个 SDK 会从远程获取游戏代码和资源…...

AssetBundle 会不会像一双隐形的翅膀，带着我们飞翔，带来更多的希望？

3

2D 与 3D

沙龙上 Cocos 引擎核心开发者 Jare 在 PPT 中还分享了一个 Cocos 的高亮特性：

引入材质系统？我做游戏的时间不长，在 Cocos 中只听说过纹理，从来没有过材质的概念，纹理与材质是什么关系？

为此，我在知乎上搜索了一翻：

1. 纹理：即“纹路”，每个物体表面上不同的样子，譬如说木头的木纹状。

2. 贴图：是图，最简单的形式是 PS 之类的软件做出来的一张图，这些图在 3D 中用来贴到物体的表面，用来表现物体的“纹理”。

3. 材质：主要是用来表现物体对光的交互（反射、折射等）性质的。譬如金属对光的反射和毛毯对光的反射性质完全不一样，那么对 3D 程序来说，这样的差别就通过材质这个属性来计算出不同的颜色。

通过上面的解释一下子就明白了，感情是要在 2D 引擎中引入光照功能，实质是将 3D 游戏的特性引入 2D 中，再回过头看看标题“重写渲染层”，这是在为 Cocos3D 铺路的节奏吗？

4

Javascript 与 Typescript

使用 Creator 做项目之初，我一直坚持使用 Javascript ES6 语法，不仅代码更加简洁，而且这是未来发展的方向。JSB2.0 带来了新的 JS 引擎，对 Javascript 新语法的支持更是不言而喻。

新旧 Javascript 语法混合

但在短期内，新旧 JS 语法将会在项目中混合使用，代码风格的统一上会出现分歧：有些守旧的人看不懂新语法不愿意使用，而有些人喜欢冒险的人则鄙视旧语法。不过目前通过 Creator 的内置 bable 编译器抹平了语法上的问题，输出的代码最终影响不大。

总的说来接受和学习新一代的 JS 语法是大势所趋，单从提高开发效率和代码质量来说是值得的。不过习惯不是那么容易被改变，如果有心想在项目中使用新语法，统一代码风格，ESLint 是一个极佳的工具，可以尝试用用！

TypeScript 让人心动

这一年使用 JS 做 Creator 项目也有不少感悟，特别是观察到刚入行的新手，不管是 JS 语言本身，还是 IDE 对 JS 支持，都成为新手成长速度较大的障碍。

Creator 从 v1.5.2 开始支持 TypeScript 语言，我之前也学习过一阵，还未在项目中实战过。自从在 Cocos 社区看到有网友晒出用 TS 写代码的视频，心里痒痒的！如果有兴趣可通过链接了解，说不定会让你爱上写代码的感觉。

我认为 TS 至少可以解决 JS 两个问题：

1. 解决在 IDE 工具中的代码提示问题：JS 代码在 IDE中 的提示较弱，这是新手入门时很大一个槛，组件属性、方法需要强行记忆，还容易写错。TS 动、静结合在编码时的智能提示相当精确，同时对老手也能提高代码生产速度。

2. 解决数据类型问题：JS 在数据定义、参数传递时没有类型限制，TS 则像 Java 这类静态语言上有强制的数据类型匹配，可以减少在运行时属性不存在，对象字段写错字的问题。

TS 是 JS 的超越，而且在 Creator 中 JS 与 TS 可以混用。我们可以尝试在新的底层代码中用 TS，上层代码不管是用 JS 还是 TS 都可以在 IDE 中提供精确的智能提示，从而提高开发效率，再由星星之火蔓延到整个项目，最好是能让项目、让团队能火起来…...

5

团队与项目

我遇到的大多数团队，美术与策划几乎都不愿意用游戏引擎，会熟练使用引擎去编辑 UI 的并不多，对于美术人员来说，编辑动画比编辑 UI 更容易。

UI 界面的生产问题

我所体验到的项目工作流，还没有达到上图所示中的那样美好境界：

美术拼接 UI，程序员完成组件代码的挂接

我理想的情况是将用户界面中的 UI 和布局部分交由策划做第一轮，将界面的美化、赋图、精确位置等交由美术做第二道加工，最后由程序做节点的层节调整、命名等需要与代码交互相关的操作。

要做到这些，需要整个团队具有极强的协同能力，如果协作的不好还不如交由程序员直接完成(可怜的程序猿们)！

还是有些不甘心，团队中如果能培养一名会游戏 UI 编辑的美术或策划，能将 UI 与程序建立链接，在程序开始一个功能前将场景和预制件提前准备好，这将极大地为程序员们节省时间，也为是项目节省出时间。

很多时候我们是为了完成任务而工作，大多并没有思考过各种资源组合的可能性，有时候慢一点、反思一下说不定会找到更优的解法。

资源管理问题

我一直认为，游戏项目中的资源管理是重中之重，整合策划、美术、程序输出的资源，是游戏团队人员每天要做的事情。如何能高效地整合游戏开发中的这三驾马车，是值得深入研究的课题！

• 策划：文档、配置

• 美术：图片、动画

• 程序：代码、工具

在我的游戏开发体验中，我觉得程序应该主动利用代码和工具为项目流程增加自动化处理，将人工重复劳动从中解放出来。策划产品经理应该站在更高的层次发现流程中的痛点，想办法优化流程、减少部门之间的沟通成本。

6

结语

无论是 Cocos 的升级与发展，还是 JS、TS 语言的进化，再到项目和团队，都让我感受到当下世界发展之快，所有的事物都用尽全力去奔跑。

正如电影《爱丽丝梦游仙境》故事中红桃皇后所说的：

“在我们这个世界，你要想待在原地，就得使出全身力量拼命奔跑”