three.js更适合用来做3D模型效果。如：跳一跳就是three.js制作的。cocoscreator更适合用来做2D动画效果。如：斗地主，卡牌游戏一般就是cocoscreator制作的。
CocosCreator是一款优秀的开源移动游戏引擎，在全球范围内拥有数量庞大的用户。
有是有，但并不是很多，而且都是贪吃蛇之类的，非常小的游戏，即便是页游也一样。能运行在浏览器端的语言，确实只有JS，但在开发阶段，却并不一定要使用JS写。而是用其他语言写，直接使用JS写游戏，实在太自虐了。
JS本身的缺点非常严重，如果只是写DOM的话，其实并没什么感觉，因为代码量太少。
但如果写类似游戏这种复杂逻辑，代码量一变大，瞬间就令人崩溃了。弱类型，回调地狱问题，即便将来版本更新到ES10，也不可能完全解决。
如果你看过一个游戏项目的JS源码，你会发现一个非常恐怖的现象。在代码的最底部，有几百个，甚至几千个大括号。。。。所有大型程序的JS源码，拉到最底部，大概都是长这个样子的：
} } } } } } } } } } } } } } } } } } } } } } } } } } } }} } } } } } }} } } } } } } } } } } } } } } } } } } }.Listen(127.0.0.1) } } } } } } } } } } } } } } } } } } } } }} } } } } } } } } } } } } } } }}
大括号的数量还必须绝对精准，少一个，或者多一个，都无法正常运行。。。这就是平时所说的回调地狱。由于JS项目总是函数里面套函数，层层相套，这叫做回调函数。层数一多，就算你是N年的老手，也照样懵比。。。。
所有的游戏项目，都比网页特效的代码量要多的多。。。比如写一个斗地主，就需要4，5万行的JS代码。。。。。最底部的大括号数量，轻松上千。。。。
弱类型的缺陷更严重，但由于解释起来篇幅会很长，所以这里就不提了。
所以为了避开JS本身太多的语法缺陷，一般游戏项目，都是使用其他语言编写，最后再通过一些手段，编译成JS。。。就如同你用一般编程语言编写，最终运行的时候，只有1和0的道理一样。。。在制作页游的时候，一般都是用强类型语言编写，最后开发完成之后，把那些强类型语言编写的代码，通过一些手段“转换”成JS代码。
“转换”成JS代码的方法有很多，其中在游戏行业比较主流的，一共有三种：
1，ActionScript语言，简称AS语言。也就是当年FLASH使用的那个语言。。。当年也曾辉煌过，后来随着FLASH的没落而逐渐没落。。。但有很多H5游戏引擎，也同样使用AS语言。比如LayaAir引擎等。
2,TypeScript语言，简称TS语言。由微软出品，微软和谷歌共同维护的一门完全符合ECMA标准的语言，可以视作JS的超集。超集这个概念怎么理解呢？就是“所有的JS语言，同时也是TS语言，而TS比今天的JS，更像未来的JS”。就比如目前的JS版本只出到了ES6或ES7。那么ES10是啥样？现在并没人见过，连ECMA组织也不知道。。。但有一点可以确定的是，它和TypeScript长的很像。而TS是包含JS的。换言之，JS本身也可以视作是TS的一部分。只是TS里的内容要远比JS多的多。这语言主要有两种用法，一是像AS语言一样结合游戏引擎，比如cocos creator，白鹭等引擎都支持。还有一种用法就是。。。结合Three.JS之类的库，完全按照JS本身的用法去使用。
3，C#语言。虽然JS得名字里面带个Java。但和它长的最像的语言，却并不是JAVA，而是C#。简单说就是：“JS的名字和JAVA有多像，语法就和C#有多像”。所以C#也比较容易转换成JS。但这并不是重点，重点是有一个超级牛的游戏引擎，是使用C#作为开发语言的。就是大名鼎鼎的Unity3D。Unity3D可以直接把C#编写的游戏项目，虚拟现实项目等，编译发布到WebGL。
机缘巧合，最近接到关于游戏的需求，前后调研了一下Unity3D和CocosCreator，但是考虑到是作为项目的一部分而使用，并且局限于Unity3D的使用条款，为了避免法律问题，最后选择的是使用CocosCreator来实现。第一次接触Unity3D和CocosCreator这类的游戏引擎，大约用了一个月的时间，从学习到项目大部分完成，之后要打包成静态库供其他客户端的同事们使用。学习途径主要是CocosCreator官网文档和官方Demo（看中文的文档就是爽！！！）。本片文章的目的主要是记录一下过程中遇到的问题及解决方案，并不是完整的教程。
本次要做的是一个最简单的跑酷类游戏，无需使用Tiled（地图编辑器），spine（骨骼动画编辑器）。也是做了这个小游戏才发现游戏其实已经发展的很成熟了。
我们可以看到，元素很简单，背景主要有远景、中景，通过设置不同的速度来实现现实中跑动的效果。主要的逻辑实现部分是在前景的任务和障碍物。由于没有使用物理引擎，所以是直接使用CocosCreator的碰撞检测实现的。主人公可以跳跃越过障碍物，撞开障碍物，收集金币。按住屏幕，hero跳起，按的时间长一些，主人公的跳跃也会高一些，自然一些的话还是需要简单的物理公式的。正常情况下hero是在x轴上是没有速度的，一种情况是当障碍物挡住hero时会有一个和障碍物同样的速度模拟阻挡的效果，还有一种情况是阻挡产生之后hero产生了位置上的移动，需要一个速度回到原位置。由于CocosCreator提供了碰撞检测之后的回调函数，所以我们可以很轻松的在回调中做一些相关操作，比如让碰到的金币消失之类的。
有位同事做过cocos2d-x的开发，使用的c++，向他请教了一些基础了知识，但是细节上跟cocosCreator相差恨远，因为cocosCreator是用cocos2d-js框架并配合可视化的编辑器来实现的。由于是先调研的Unity3D，对这种脚本的方式还是比较能够接受的。其核心思想是在组件，在编辑器中制作精灵和动画，然后通过脚本组件来控制其逻辑实现，各种功能都组件化，当我们需要给精灵添加一个功能的时候，就是向其添加一个组件。在这个小游戏的制作过程中用的组件的数量也是有限的，主要是使用了：
编辑器给我们提供了方便的拖拽界面，直接将我们需要使用的图片导入，就会自动生成精灵文件（但是用过Unity3D之后，还是感觉Unity3D的功能集成度更高一些，而且还可以做3D）。
在编写脚本的时候也是不能脱离编辑器的，在编写脚本的时候着实是让我这个ios程序员有点摸不到头脑了，JS的使用方式有点让我不太适应，没有了xcode的提示功能，写起来还是有些费劲的。JS也是边学边写，不过得益于官方的Demo几乎把所有组件都写了一遍，所以就照着葫芦画瓢。写的时候就发现，其实引擎并没有帮我们做很多的工作（Unity3D可以直接在编辑器里设置物理属性，不过听说下个版本的CocosCreator也会有）。在编写脚本的过程中，最复杂的就是hero脚本的编写，需要检测碰撞和处理hero跳跃过程中的不同状态。碰撞检测的话需要自己计算碰撞发生的位置，当做矩形碰撞器来处理的，只计算x轴和y轴的碰撞。x轴发生碰撞的话，hero有一个和障碍物一样的速度，y轴碰撞一直持续的话就是调整hero的y轴的位置，让其在障碍物的顶部。跳跃的过程中完成动画的切换。
与CocosCreator编辑器不同的是，这个编辑器是我写的一个生成障碍物的一个app，可以方便让产品配置障碍物的位置。主要的实现思路是使用UICollectionView，界面非常的简单,主要是配合CocosCreator脚本的实现，需要将颗粒状的障碍物连成一个长的条状，所以需要将界上的障碍物颗粒结构化一下，取到障碍物的最底部的颗粒的位置，然后连接在一起的高度，这样的话就是对每一列的统一种类的障碍物进行深度优先搜索，记录最低点和搜索过的深度，这样的生成的JSON文件在CoCosCreator脚本里就可以直接使用了。
