为了研究一笔画完，结果做出了个游戏

某天，我看到流行的、一笔画完类型的小游戏，于是就在那想，这种游戏的关卡构建是不是都是人工构建的，还是说程序可以随机生成。

结果想着想着就想动手试试，恰好最近在研究一款叫playcanvas的3d引擎，于是弄了个3d Demo。

为了快速演示，demo里的格子没用特别复杂的模型，而是用了简单的正方体模型，演示的效果是随机生成一个有解的布局，通过触碰或滑动屏幕来构造一次走完的路线。

demo没花我太多时间，大概两个小时就搞定了。

要不不开始，一开始便不可收拾，我不想它就是个简单的演示demo。

所以接下来的周末，我都沉迷在这个demo的优化过程中了。界面怎样在短时间内美化？到底随机地图的关卡怎么构建？是不是该用小程序云？能不能做点只有小游戏可以实现的功能？

一系列问题突然在我脑海中盘旋。

显然最后都实现了，现在回想起来有种类比于“为什么当年高考都能扛过去”的感觉，所以这里记录一下开发历程中的思考。

代码逻辑，太枯燥这里就不细说了，有兴趣的同学可以线下交流，这里通过几个问题抛点大家能理解的业务思路。

界面怎样在短时间内美化的？

有朋友说目前的视觉不太好看，我只想说，两周的开发时间，而且只是下班后或者周末的业余时间搞的项目，从策划到交互到视觉到开发，都一个人包办，你想要专业级的视觉呈现，是不是太苛刻了。

所以，视觉上走的是一种折中的开发方式，比如说，不做2d的，做3d的，在视觉表达上，3d引擎为我提供了透视、光照、阴影等现有的效果处理方式，我可以轻松的画出一些低精度模型，加点光加点影，画面就显得不会太违和。

所以，我第一次用3dmax画了个小鸡模型。。。

其他UI层面的元素，就用photoshop稍微画画就好。

到底随机地图的关卡怎么构建？

对于有解关卡的随机构建其实很简单，大体逻辑是：随机定点，然后从三个可选方向中选一个行走，一直走到无路可走时，此路线就是一个关卡，目前游戏中有个“发起挑战”的模式，其实就是这个思路的缩影。

但怎么判断这些关卡的难度呢？这成了我最头疼的问题，依据总个数？不行，只能算是其中一个维度。按照起点和终点的距离？好像也没有固定的算法。到最后我也没得出判断难度的程序判断标准，只能人为定义了一些比较难的关卡。

是不是该用小程序云？

一笔一连小游戏目前远端的逻辑基本都放在小程序云上面，但也有部分逻辑需要自己搭建第三方服务器来支援。

小程序云为游戏提供了玩家游戏记录存储、排行榜逻辑处理等基础处理功能，但诸如“生成小程序码”、“调起微信商户功能”等需要服务端二次校验权限的接口，小程序云目前是不支持的。

以结果来看过程的话，中大型游戏用小程序云会有挺大程度的限制，但小型的小游戏用小程序云应该绰绰有余了。

能不能做点只有小游戏可以实现的功能？

答案肯定的，我做demo有个习惯，总想利用它做点新功能的预研或者做点老接口的综合应用。一笔一连小游戏中就有两个点是为了好玩或者研究而做的。

第一个是“动态消息”的功能

实际落地点是游戏中的“集结赢薯条”功能（更多细节可参考这里）：

第二个是发红包功能

这可能是个有争议的功能，花叔只是好奇玩一下，有成型的体验demo，但目前没上线，技术上能跑通的。

主要的业务逻辑是：

首次需要构建小游戏和另一个可以发起企业付款小程序间的openid映射关系，当存储后，以后的每次领红包操作，即可根据关系去间接调起商户接口发起（有规则风险）。

而技术逻辑大概是这样：

只要玩家首次完成这个交互，把这个关系构建好后，未来的就再也不会有跳转付款小程序的前端交互了。

当然，如果小游戏和付款小程序是同主体，他们间的openid理论上能动态互转，就可以免去“通过前端跳转来构建两个openid关系”的繁琐步骤。

好了，说了听多了。

结束...