研究一下物理引擎，做了个游戏，文末有感
前阵子过春节，在家看小孩没法出去玩，于是就码起来了，心血来潮想做个基于物理引擎的小游戏，于是愉快地打开了cocos creator（后面简称为ccc）。
然后到这个周末，一个算是上线了。
视频效果如下：
负责的工作
一年多前，我开始学习小游戏开发，并尝试按全栈的方式去独立开发小游戏。由于做小游戏都抱着学习的心态，所以什么不擅长就临时学一下。最后整个游戏的策划、交互、视觉设计、音效设计、前端开发、后台开发、性能调优、功能测试等工作都一人包揽了。
所用到的IDE包括（仅供参考，其他同行有更好的工具推荐的话，记得留言哦）：
photoshop，主要用于交互和视觉稿的设计。
cocos creator，主要用于视觉还原、主逻辑开发、跨端调试和编译。个人觉得这是超给力的游戏开发工具，把component的机制直接可视化，集成各种物理引擎、粒子引擎、UI组件等功能，大大节省了游戏UI以及部分特效逻辑的研发成本。但小游戏版本的编译速度还是很慢啊。
Visual Stuido Code，用于代码开发。这好像是最近最流行的代码撰写工具了，免费且稳定啊！
微信开发者工具，用于微信私有功能开发，云开发，小游戏提审。相比早期的版本微信开发者工具的体验优化了很多，但在文件监听侧还是有点问题，跟ccc的联动，经常会出现ccc编译好文件，微信开发者工具会报错的问题。
Cool Edit Pro，音频资源裁切。
TexturePacker，sprite资源集自动构建。
Google Chrome，web版游戏调试。有些时候一些性能调优可以放在chrome上面，它有非常专业的调试工具。
从涉及的IDE看出来，其实开发一个游戏需要兼顾好多内容，尽管游戏提供的功能并不多，但实际研发时间却不短，花了整个春节假期（WTF，明明就几天）。
实际上，游戏开发相比页面开发，我认为前者更难，它更像一门综合技术，世界观构建、内容建设、美术构建、音效设计、程序算法等等，很多方面都需要涉猎，这里面的每项内容都够我钻研很长一段时间了。
题外话，请善待独立做游戏的人，他们都在以高负荷的工作压力在研发和学习。
（文章篇幅略长，想看鸡汤，不想看技术细节，可直接跳到最后）
门外汉的游戏策划
虽然自身策划能力很业余，但在动手开发前，再简陋的策划步骤还是省不了的，预先策划有助于快速开发。
1.游戏的主线
早前预想的故事场景是开卡车在林中运输木材，核心玩法很简单：把木箱子运到指定的区域。
整个游戏基于仿真物理场景，唯一一点超现实的功能是用蓝墨水画的线条会被实体化，会成为物理碰撞体，玩家可借此搭建桥梁、容器、障碍物等方式来协助搬运。
2.内容建设的手段
而为了解决内容构建的问题，我为游戏提供了一个开放的模式，那就是：玩家可自主创建关卡。
这需要我在游戏开发中应用到原本网页设计的组件化思维，要把游戏里可能会出现的元素抽象为通用组件，然后构建一个编辑模式，让玩家拖动放置，进而设计出不同的关卡。
3.虚拟货币的换算机制
游戏引进了金币的概念，它是整个游戏世界里的通用货币，目前构思中给金币赋予的作用有两个：a.以20比1的方式兑换提示机会；b.以2000比1的方式购买卡车皮肤（暂未实现）。
而金币的获取方式比较简单粗暴：签到、分享和看视频（还没到1000累计注册用户，所以没放开功能）
ccc开发经验
鉴于内容太多，总的开发逻辑就不细说了，这里给一下开发过程中一些有用的经验。
关于布局
ccc为本游戏中提供了两种实用布局组件：
1.Widget，这能让某个元素自适应到任意位置。这是相当实用的控件了。使用方法非常简单，各种机型的自适应布局一下子就被兼顾了。
2.Layout，这能让游戏中的Node具备如网页dom一般的流行布局特性。它提供了常用的三种流体布局方式：横向、纵向以及网格。该组件对于本游戏的控件容器特别合适。
关于动画
ccc提供的动画开发套件非常强悍。
这有两个点可以提一下：
1.动画定义，ccc里为某个Node追加动画时，只要给它加cc.Animation组件，然后建立一个animation-clip，针对它去可视化编辑动画的属性和帧状态，就能快速做出一个动画。
2.动画事件监听，ccc的动画控件里有一个我觉得非常实用的功能，那就是可以为动画的某一帧定义自定义监听事件（该事件代码体可定义在Node对应的用户脚本组件中），例如里过关时会有个弹框动画，在动画播放到差不多的时候，会播放一个音效，利用的就是动画的自定义事件。
关于物理引擎
ccc的物理引擎相当强悍，只要在程序开端执行：
cc.director.getPhysicsManager().enabled = true;
整个游戏世界就会进入物理监听状态，所有被定义成刚体(追加了cc.RigidBody组件)的Node将直接具备物理性质，通过追加PhysicsCollider控件可让Node具备指定热区的物理碰撞特性。
碰撞体有一个挺有用的方法，getAABB，这是获取碰撞体包围盒的方法，可以用其结合rect的containsRect方法来实现对某个矩形区域里是否包含某碰撞体的功能，在中箱子与目标区域的监听功能就是依靠它来实现的：
具体代码：
//获取自身包围盒
var selfAABB = this.node.getComponent (cc.PhysicsPolygonCollider).
getAABB()
if (otherAABB.containsRect(selfAABB)) {
}
此外，物理引擎里还提供了一种比较实用的组件：关节组件。
它可以定义一些常用的物理场景，比如本游戏里，汽车轮子上用的就是物理引擎的WheelJoint控件：
该控件可以模拟机车轮子的物理效果，让轮子跟某个刚体保持一定距离，并能自转。
其实除了这类型的关节组件外，官方还提供了很多别的关节组件，具体的用法可以参考ccc的官方开发文档：
https://docs.cocos.com/creator/manual/zh/physics/physics/joint-component.html
对了，还要提一下：
cc.director.getPhysicsManager()
这段代码能返回全局的物理管理对象，本游戏用了该对象下面的2个方法：
1.testPoint方法，该方法可以检测某个坐标点下是否存在物理碰撞体，中在某个刚体上禁止画线的功能就是依靠它来实现的：
2.rayCast方法，该方法可以获取指定出发点到终点间射线所经过的刚体集合，中画线遇到刚体后禁止继续的功能就是依靠它来实现的：
这个方法的原生实现逻辑相当复杂，各种几何算法什么的，反正几何数学没学好的花叔如果要以原生方式实现，也只能勉强实现很挫的效果，但ccc直接就封装好供大家调用了，非常方便。
关于预制对象
预制对象是ccc中很重要的节点处理机制，
https://docs.cocos.com/creator/manual/zh/asset-workflow/prefab.html
它可以把某个节点像场景那样单独存为一个文件，然后在不同场景中引用，并通过：
cc.instantiate()
方法进行预制对象节点的复制，这样可以实现节点逻辑的复用，用来做节点组件最合适不过了。
中"创作模式"下的所有地图元素其实就是基于同一个预制对象。
不管是"创作模式"还是“闯关模式”里的地图元素的基础数据模型均来自该预制对象，如果需要新增地图元素，只要修改这个预制对象即可全局生效，可以说非常方便了。
但大家要注意，预制对象对性能有一定的反向作用，具体可以翻翻cocos的论坛，可以说它是双刃剑。
关于camera
听说2.0版本的ccc对camera的逻辑进行了优化，我试用了一下真好用，目前camera是跟group绑定的，在游戏中可以定义多个camera来处理node的Color/Depth/Stencel，中用camera实现了各种元素的层级处理（给camera定义Depth，然后指定不同group到cullingMask中）
此外依靠camera，可以快速实现截图或放大镜的效果：
touchmove回调方法中的相关代码：
var camera = this. assistCamera. getComponent ( cc.Camera );
// 新建一个 RenderTexture，并且设置 camera 的 targetTexture 为新建的 RenderTexture，这样 camera 的内容将会渲染到新建的 RenderTexture 中。
let texture = new cc.RenderTexture();
let gl = cc.game._renderContext;
// 如果截图内容中不包含 Mask 组件，可以不用传递第三个参数
texture.initWithSize(100, 100, gl.STENCIL_INDEX8);
camera.targetTexture = texture;
// 渲染一次摄像机，即更新一次内容到 RenderTexture 中
this.assistCamera.x = touchLoc.x
this.assistCamera.y = touchLoc.y
camera.render();
var sf = new cc.SpriteFrame(texture)
this.node.targetAssist. getComponent(cc.Sprite). spriteFrame = sf
想要了解camera的用法，还能研究一下官网提供的demo，这里就不展开细说了:
https://github.com/cocos-creator/demo-camera
关于性能调优
讲真，毕竟我也不是太深入地去了解过ccc的底层原理，所以性能优化这块就只能从自己这个项目来给点小技巧，以下稍微讲讲：
刚有初版的时候，性能特别糟糕，后来做了三项优化工作。
1.自动合图
降低 DrawCall 是提升游戏渲染效率一个非常直接有效的办法，而两个DrawCall 是否可以合并为一个 DrawCall 的一个非常重要的因素就是这两个 DrawCall 是否使用了同一张贴图，所以官方是建议合图的。
但我项目中用了那么多碎图，这时候让我去合图，岂不搞死我！苦恼之际以外发现ccc提供了一个强大的功能“自动合图（Auto Atlas）”
不用不知道，一用吓一跳，这功能可以把当前目录以及子目录下所有的图片文件以指定的算法去合并成sprite图，并且自动更新原有spriteFrame的引用，一下子就把全部碎图合成大图来按需调用了。
网络请求直接从几十个变成一两个。
然而....我发现drawcall也没降低多少。没花太多时间去想为什么，这个方式我就先不关注了。
2.减少节点
节点如果没来得及释放，那么一定会导致drawcall上升，往这个方向想，我就想到cc.instantiate()，在里只有这个方法会主动去新增节点，那么只要产生的临时节点及时销毁就行，但发现其实在复制完都调用了removeFromParent()方法，逻辑好像是对的。
但后来查了一下资料，原来removeFromParent方法执行后，节点并不会自动销毁，真正能让它销毁的是node的destroy方法。囧大了。应该换成destroy。于是就全局搜索removeFromParent，逐一替换，drawcall就顺利降下来了。
3.优化代码逻辑
除上述常规手段外，针对自己的代码也需要做一下优化，本游戏的代码逻辑中最有可能优化的地方是“画线”部分：
画线的主要逻辑是：
1.当前场景instantiate一个用于画线的全屏尺寸的预制对象
2.监听节点上touchmove，每次移动的时候对它上面的cc.Graphics组件进行lineTo的画线处理，同时存储每个移动点
3.用所有收集的移动点根据一个算法去构建node的物理碰撞区域
所以移动点越少越好，这样的话，优化的手段就有两个：
1.当前移动点与上一个移动点的直线距离少于一个限定值，就认为当前移动点无效。（相当于强制移动点的距离）
相应的判断代码很简单，利用ccc提供的向量求距的方法即可：
return lastPoint.sub(nowPoint).mag() >= 5;
2.“当前移动点跟上一个移动点的移动方向”如果跟“上一个移动点跟上上个移动点的移动方向”一样的话，那么上一个移动点即可销毁不做记录。（相当于把直线部分的移动点压减为两端点）
touchmove回调中相应代码如下：
//获得增长向量
var addVe = thisPos.sub( thisPos.prevPos )
//如果有前一个增长变量
if(thisPos.prevPos.prevPos){
//获取上一个点的增加向量
var lastAddVe = thisPos.prevPos.sub(thisPos.prevPos.prevPos)
//如果两个增长向量相等,则这次的点替换前一个点
if(Math.abs( addVe.signAngle( cc.v2(1,0) ) - lastAddVe.signAngle( cc.v2(1,0)) )<0.1){
this.points[this.points.length-1]=thisPos
this.physicsLinePoints[this.physicsLinePoints.length-1]=thisPos
}else{
this.points.push(thisPos);
this.physicsLinePoints.push(thisPos);
}
}else{
this.points.push(thisPos);
this.physicsLinePoints.push(thisPos);
}
依靠上述3种方式，我大概能把drawcall控制在50左右，但其实效果还是能优化。
ccc就性能优化来说，还提供了“节点池”和"动态合图"的优化方式，本游戏目前还没有应用上，未来也许可以试试。
最后
终于把要讲的讲完了，最后感慨一下。
花叔怎么说也从事互联网快10年了，现在对于平时的工作也不需要单纯的执行，也许从旁指导一下就算完事了。所以有人会问：你怎么还孜孜不倦地画图、写代码、做demo呀？还需要吗？
我就给他说了一件事，从前有一天，我指导另一个同事的项目，振振有词有理有据，但同事反问我一句：你多久没写代码了？这里面是xxxxx这样的。
我瞬间懵了一下。
虽然还是答上去了，但后来我就在想，幸好他这个项目我以前研究过，不然就凭那句“你多久没写代码了”，我就直接把主导权送出去了。
企业获利大多是基于信息不对称，谁是信息上游，谁就更有可能控制局面；管理者、策划者给的是方向，固然重要，但信息不对称的事情大多在于技术层。
我见过cp怎样用技术忽悠需求方，特别是高新技术层面的事情，忽悠起来简直轻而易举。
有时候，我们转型、通道转通道、技术转管理，以为是找了个更好更适合的方向。
其实我看到更多可能的：1.专业到了瓶颈，对瓶颈逃避而选择转型罢了；2.专业能力突出被授予管理权力，然后就以为要转型了；3.真的不适合本专业
第三点且不说，前两点，何曾想过你想转向的领域，缺你吗？你苦心经营的技术不时而锻炼就会淡忘，就愿意因为一点点小瓶颈而舍弃吗？
技术和管理本不冲突，但为何要因管理而丢弃技术，失去对技术创造力的追求。
还能不能好好定义自己是什么人哦？
最后，引用一前辈的话：“我这人习惯自己先搞清楚怎么实现再指导。”
谁不想当信息的上游啊。
你以为我平时指导多内部小游戏的研发，靠的是吹水咩....