为学cocos，和机友做了个重力小游戏

年初，花叔给自己定今年学会游戏开发的个人发展目标。

于是，趁着小游戏发布之际，一边学createjs一边发布了个人第一款小游戏：最强坦克，现在每逢周末都会或多或少地迭代一下。

渐渐发现，createjs做游戏有点弱，那是偏程序编码的开发方式，虽然在做数据调用和程序逻辑方面比较灵活，但是做游戏UI效果，createjs会显得无力，因为要一行行代码写，效率不高。而实际游戏开发中，UI效果的制作工作量又不少，所以createjs在游戏开发上面还是略逊一筹，可以说它只是个代码库，要真正做游戏还是需要一整套开发套件才行。

于是花叔慢慢转战cocos creator(以下简称cc)，在说它跟createjs有什么区别前，先介绍一下学习cc的阶段性成果。

这是基于cc做的、用重力感应控制方向的飞行游戏，这个游戏的灵感很奇妙，来自于一个游戏群。

话说，花叔喜欢玩ps4怪物猎人，刚好最近有同事拉了个微信猎人群，里面有设计师，有开发者。我们经常联机一起玩，闲聊之余，有位设计师同学知道我会做小游戏，他就说有个构思，灵感来自于小时候的一个纸飞机游戏：

他说当年一玩就可以玩一个下午，他想在小游戏也实现个类似的游戏，我后来查了一下其实这是GBA上面的经典游戏，是瓦里奥制作系列中的一个小游戏。

当年的GBA游戏机没有重力感应功能，而现在微信小游戏是支持的，我当时也刚好在研究这块，在设想找一种游戏模式去落地这项技术，正好这个想法迎合了我对技术的尝新需求，于是，一拍而合，我们就真干起来了。

一般周末或者下班时间，我们就开发和设计。没过多久，设计稿就差不多搞定了。

初版是这样的（大家都说sige同学的设计稿好惊艳）：

后来觉得交互得优化，就改了一版，UI变了。

而程序层面，花叔第一次接触cc，说真的，作为代码佬一开始挺不习惯cc的开发流程。

cc的开发理念是以工作流为核心，让不同职能的开发者能够快速找到最大化自己作用的工作切入点，并能够默契流畅的和团队其他成员配合。

简单来说，他就是把游戏中可能用到的各类功能或者元素封装成一个个组件，这些组件带有自己的回调方法，组件在可视化开发工具里就能通过拖拽和拼装形成游戏。

cc还有有一个比较好的点是：它约定了程序员可以定义一些属性，这些属性能暴露给其他同学去修改。

做前端的同学想象一下，在你把设计稿还原成页面后，如果设计师让你修改某些位置或者宽高参数时，你得帮他在代码里翻，看需要改哪个地方，是不是很烦？

而且这过程一般是串行的，你得停下手中的工作，去帮他弄。在cc里，你完全可以让设计师去打开那个可视化工具，跟他说让他在面板里自己调，微调可以预览查看真实效果，最后调完后，双方项目再简单合并一下就行。这样既能保证专人做专事，又可以让事情并行。

这是件挺爽的事情。

然而，要实现这样完美组合，cc需要一个既定的程序设计模式，程序员并不能像用createjs那样，自己定义设计模式，cc限定了您只能用它的全局设计模式。

置于是怎样的设计模式，这里不细说，反正总结来说就是程序员要写一个个的组件类，程序逻辑发生在类的一个个回调方法里。

所以，代码佬们一开始可能会有点抗拒，但是用习惯后会发现很爽。

利用它，很随意就能做出比较复杂的UI效果，甚至粒子动画效果，例如游戏中的这个火焰效果：

在cc中实现这个效果，就是几分钟的事，逻辑是：给火箭这个node挂个ParticleSystem组件（粒子组件），然后更改一下单个粒子配图，然后调整一下参数即可。

cc结合可视化的编辑工具能提供了很多可扩展的组件，只要稍稍改改，就能做出各种不一样效果的游戏元素。

要是程序员自己去实现这些组件的交互逻辑，效果好不好先不说，但所花的时间估计也不少，文章篇幅已经有点长，这种点点配置或者看看文档就能用的功能点就不说了。

接下来说说cc开发微信小游戏的一个痛点吧，那定必是：结合开放数据域的功能开发和调试。

说说背景，为了让游戏开发者能使用微信关系链数据，微信小游戏的官方开发团队提供了一套开放域调用并展示关系链数据方案，可以让开发者在一个黑盒里实现关系链数据的拉取，但是这些数据仅能做前端侧的呈现，开发者没法在程序中主动存储。

先来看看太空引力小游戏哪些地方用了开放域：

• 排行榜（包括好友和群排行）
• 超越提示
• 结算页分数和相近排名

凡是跟用户关系链数据相关的地方全来源于一个cc的开放域项目，“太空引力”项目是分两个cc项目合并而成的，注.cc项目定义为微信开放域（也叫子域）项目。

yinli_rank是专门负责所有开放关系链数据展示的子项目，yinli项目才是游戏主逻辑主项目。

两个项目间通过微信小游戏开放域的API进行单向通信，

意思是，主项目中发个消息给子项目，跟他说要一个“超越哪位好友”的图文展示时，子项目就开始准备，准备完后就画到一个主项目和子项目共享的画布上面，主项目就能拿来展示了。

这个逻辑也不难理解，但是调试起来就很麻烦。

会牵扯到两个cc项目、微信开发工具、另外一个代码编辑工具的同时运行，甚至还需要单独打开个浏览器。

花叔因为这个还多买了一条内存条。。。

来说说为啥会这样，首先要打开两个cc项目原因上面说了，因为开放域要独自开一个，主项目也要开一个。那么为什么还要有个代码编辑器的工具要打开？

因为，cc不支持代码编辑，在它的可视化编辑工具里，代码只做展现，要编辑的话，需要指定别的代码编辑工具。。。并且，每次编辑完还得回到这个可视化编辑工具里，预览页才会刷新。。（花叔只想说，wtf）

至于为什么要打开微信开发工具就很好理解了，因为cc本身没法模拟微信小游戏的api，它的预览功能里并没有集成微信小游戏的api，要是直接用wx.xxxx的api，用浏览器或者cc的模拟器预览的时候铁定报错。

所以项目到后期要调试开放域项目逻辑或者别的一些小游戏私有api（例如重力检测）时，过程就是：代码编辑器编写代码，回cc可视化编辑工具保存更新，然后ctrl+shift+b调出发布页面，然后去微信调试工具里预览效果。。。

就上面的描述，看起来都觉得已经反人类了吧，实际操作还更反人类，因为cc的代码发布偶尔会相当的慢。。。有时候得喝杯水慢慢等。

那是不是没有优化手段呢？也不是，花叔这里给几点经验：

1. 利用好cc的build-templates 这个能让你的开放域项目具备正确的入口文件，1.9.1版本的cc，发布的开放域项目默认入口文件是sub.js，以前确实开放域的入口文件就是这个名字，但是后来微信官方改了，cc却没跟上，但没关系，用build-templates能让每次发布的时候给发布目录中加固定的文件。
2. cc发布代码的时候选择调试模式 这首先可能会免去代码压缩的过程，发布会变快，其次发布后的代码在微信开发者工具中是一行行显示，便于代码检索

发布后的代码会打包到src目录下的project.js(或者project.dev.js)中。

1. 尽量把游戏逻辑和微信API逻辑分离，游戏主逻辑在cc中直接调试。

今天说得有点多，不说了，别的问题就交给留言区了。

总的来说，重点有三：

1. 花叔跟一个设计师做了一个重力感应类小游戏，这是目前小游戏里含有的重力类游戏，它叫“太空引力”，appid是：wx6b14f87a706b8245，欢迎绑定，小程序码在这里：

1. 微信游戏群有时候不是讨论怎么玩游戏的，有时候也会讨论怎么开发游戏，例如我们那个猎人群。
2. cocos creator做小游戏不错，就是调试比较麻烦。

思维导图高级版小程序寻求公众号绑定，APPID为： wx368bd706303f88b6，公众号可在mp后台直接进行绑定，花叔会第一时间确认。

本文来自花叔的MinProgram公众号

不用问，可随意转载