使用 cocos2d-js 3.0 开发游戏项目两三个月，积累了几个有意思的工具库，在此做一点小记。

开发手机游戏时常常需要对不同的设备进行分辨率适配。在 PC 游戏开发中，一种比较直截了当的作法——全屏显示游戏，将屏幕锁定在一个预设好的分辨率中即可。但这在当下的移动设备中无法做到。由于生产标准不一，市场上有各种让人零乱的 Android 设备尺寸，即便是规格较统一的 iOS 设备，如今也正走向多分辨率分裂的格局：

• iPhone4S 960×640
• iPhone5/5S 1136×768
• iPad 1024×768
• iPad retina 2048×1536
• and so forth…

为了应对不同的屏幕，Cocos2d-x 游戏引擎提供了一组分辨率适配策略：

• Show All
• No Border
• Exact Fit
• Fixed Width
• Fixed Height

详细的使用方法可参见此官方文档。这些策略通过一些妥协使得游戏在不同的设备上得以较完整的显示。文档中提到一个重要概念叫“设计分辨率”（Design Resolution），表示设计组在这个尺寸下进行游戏素材的设计。在这里对于这些显示策略的优势与不足作一些简单的介绍：

在现阶段游戏开发中有一个简单但烦琐的问题：每当美术资源需要替换时，需要一序列的搬运工作：

1. 从版本控制工具更新美术资源（文件名[0.jpg, 1.jpg, 2.jpg…]，美术组自已的命名方案）
2. 在 working space 中找到相应的资源（文件名[a.jpg, b.jpg, c.jpg…]，程序组的命名方案）
3. 逐个替换：复制美术组的文件到 working space（command+c/command+v），复制程序组文件名（enter, command+c），删除程序组文件（command+backspace），修改新的资源文件为原有文件名（enter, command+v）…

如果数量不多的话，这样简单的操作还是可以容忍的。但是有时候懒惰的天性就会让大多数程序员对这种烦琐的操作忍无可忍。当然，解决方案也有很多：

1. 提出一个合理的方案，使得美术组与程序组使用相同的命名规则。
2. 使用更佳完善的商业游戏引擎提供的资源管理解决方案。
3. 找一个方便替换文件的工具。

对于第一种方案，对开发组的阻碍是，美术组对英文命名不敏感；此外程序组并不知道美术组如何分割资源，随时会增删改资源，会增加沟通成本；

对于第二种方案，对于使用开源游戏引擎的小组，一时半会是没办法做出这样的改动的。

所以如果能使用第三种方案，那也是一个不错的 fallback 。

在游戏中常常需要配置各种产出表，例如怪物的掉落、开启宝箱获得道具等等。简单的做法就是将这些功能分开开发，怪物用简单的概率来判断是否掉落物品，宝箱则根据预先设置好的权重来决定最终获得的道具。

但是需求总是处于变化的，如果策划想要让怪物能像宝箱那样根据权重来决定掉落，或者让宝箱像怪物那样由概率来获得道具（也可能什么也得不到）。

既然如此何不设计一种简单而灵活的，可以兼容这两种方案的配置呢？

如果一个编程语言只有8个指令，你一定会想：天啊，它能干嘛！

实际上，它是图灵完备所需的最少指令数。

在可计算性理论里，如果一系列操作数据的规则（如指令集、编程语言、细胞自动机）可以用来模拟单带图灵机，那么它是图灵完备的。

没错，这就是 Brainfuck 语言，它的八个指令是：> < + - . , [ ]

> 	右移指针
< 	左移指针
+ 	当前位置+1
- 	当前位置-1
. 	输出当前位置的ACSII码
, 	输入一个字符到当前位置
[ 	如果当前位置为0则跳转到匹配的]处
] 	跳转到匹配的[处

美术组希望游戏中对话框的背景不是单调地叠一层半透明黑色，而是能有模糊的虚化效果。像是这个网页中第一个按钮按下去的样子。

显然，如果在要手游中实现这个效果，需要借助 OpenGL ES 2.0 Shader 来完成。

一个理想的方案是对当前场景设置一个 Shader 并在 Shader 中实现模糊效果，使得整个场景虚化。但是对话框也需要置于场景中，这会导致连对话框也虚化掉。

最近闲来无事，将 iPad 里一些玩了很久，感觉无法再精进的游戏拿来开开刀——试着修改游戏存档。于是发现了许多 iOS 游戏脆弱的一面，也发现了一些有意义的防御。

¶Node.js

自 node.js 问世以来，javascript 在服务端的地位得到了许多人的认可。javascript 也不再是以往被认为的“前端的玩具语言”。在开发流程与规范上，node.js 提供了一套完整的方案，其中最基本的就是 CommonJS 规范。它将 javascript 划分为模块，模块之间通过 require 进行调用——这很像其它语言的 include 或 import。

此外，node.js 还提供了 npm 包管理工具（node package manager）。这使得全球的 node 开发者能够非常方便的共享和使用优秀的模块。可以说 node.js 的成长离不开这些优秀的开源社区。

模块化开发的好处非常多，最重要的就是使得测试驱动变得更加友好，不用再去处理复杂的依赖关系。mocha 是 node.js 环境下的一款非常好用的测试/行为驱动框架，能够结合各种第三方测试框架（只要它能抛出异常），我个人比较喜欢 should.js

于是我尝试使用 mocha + should.js 进行了一段时间的 BDD 开发，感觉非常好。很快就能把模块写好，并且得到一份不错的测试文档。

阅读 Cocos2d-x 源码的时候，有几个有趣的关于路径运动的 Test Case 之前一直没有时间去研究：ActionCardinalSpline 和 ActionCatmullRom。由于对 Bezier 比较熟悉，所以 ActionBezier 就略过了。于是特地看了一下前两个陌生的名字。

Cocos2d-x 提供了一组制作帧动画的工具：CCAnimationFrame + CCAnimation + CCAnimate.

CCAnimationFrame 是 CCSpriteFrame 的容器，但是增加了额外的帧信息，比如该帧的停留时间；

CCAnimation 是 CCAnimationFrame 的容器，包含的整个动画所需的帧序列。此外还有动画的循环次数，并且可以设置每帧之间的停留时间；

CCAnimate 是一个动作，它根据 CCAnimation 容器中的 CCAnimationFrame 以一定时间间隔切换 CCSprite 的外观（CCSpriteFrame）。并且从继承树看可以看到 CCAnimate -> CCActionInterval -> FiniteTimeAction -> CCAction 它是一个有限时长的动作。

可以把 CCAnimationFrame 想像成书中的页面，CCAnimation 想像成一本书，而 CCAnimate 就是翻书的动作。