在一些时间以前，比如2012年之前，做web游戏的人还不是很多（就是用javascript写游戏的人）。

当时也没想那么多，就是为了制作一个「不需要下载，点开就能玩的游戏」，所以就投入到web游戏制作的大海中。

但那时很多人都说，「你这些东西看着蛮好玩的，但感觉没什么用啊」。

其实我不是很理解「没什么用」是什么概念，「好玩」难道不够吗？

然后时间来到2018年，微信推出了小游戏。于是web游戏制作技术忽然从一个「没什么用的技术」一跃变成了时下最潮流的技术。

——————————————分割线————————————————

其实我只喜欢一个title，游戏制作人。但因为一直没有一款具有代表性的游戏，所以我一直不知道怎么做自我介绍。

真希望哪天可以自豪的介绍：我是 xx 游戏的制作人。

我所在团队是腾讯互娱的TGideas，会议上稍微吹了会，感兴趣的同学自行搜索。

——————————————分割线————————————————

接下来是正题：

主题分为4个部分（忽略旁边那个表情包）：

基础概念
架构设计
部分算法
微信API

游戏的驱动由开发编写游戏逻辑，然后在渲染器中实时渲染到画布上。

微信小游戏和传统web游戏（canvas类）最大的区别在于API。

小游戏的表现既可以像跳一跳那样休闲，也可以像街机的格斗游戏一样热血，不要被想象力所限制，认为「小游戏就应该有小游戏的样子」。

当然，一般会有「小游戏就该是什么样」的想法的人，多少是对游戏有所了解的人才会发出的感慨，因为我们需要戴上名为「现实」的技术枷锁。

这种想法并没有错，反而比那些没有套上枷锁，而要求他人根据手机壳的颜色改变手机背景颜色的人要好很多。

但是，在戴上了技术枷锁以后还能保持天马行空的想象力，那才是最难能可贵的。

微信小游戏的文件结构

game.js以及game.json分别是小游戏的入口文件及配置文件。

res是游戏资源，也是游戏占用体积最大的地方。

adapter是利用微信API模拟浏览器API的库。

而src部分就是本次分享的重点内容。

我个人制作的小游戏目前画风都比较奔放，所以分享时借用团队制作的小游戏来介绍了。

游戏结构分为3个大的模块：

Base 模块管理脚本，用来组织起整个游戏的部分。负责游戏的开始，暂停，决定游戏该调用哪个场景。

Scene 场景模块，类似于不同的关卡，每个关卡里需要载入什么样的角色，什么样的敌人，播放什么样的音乐都由场景模块决定。

Role 角色模块，游戏逻辑中最重要的一个部分。不论是主角还是敌人，甚至场景里的一个宝箱，一颗子弹，都属于角色。

剩下的模块都是对不同游戏进行补完，因为一个格斗游戏和一个休闲游戏所需要的模块差别是非常大的。

角色模块可以大致分为4个部分：属性、动画、指令、行为。

属性：我们可以把一个object叫做实体，这个实体里的属性就是角色的属性，比如坐标，hp，speed等等。

动画：角色的动画一般有属性动画，序列帧动画，骨骼动画这几种，这些动画中部分还有2d和3d的区别。

动画这一部分属于「跨领域」作业，因为要把一些「感性」的图像转化成「理性」的代码。这部分的介绍以后会陆续放出。

指令：指令是玩家输入手段的一种封装。

例如，「水果忍者」的滑动切水果的指令就是通过「触控」的API进行实现，而一些「连续技」，「虚拟摇杆」也需要对应的API组合来实现。

行为：角色的行为就是通过调整角色的属性而产生的一种结果。

如移动就是坐标

x+=speed;
sprite.play(move);

角色行为是游戏逻辑中最重要的一环，而角色之间的行为交互又伴随着大量的算法。

每种游戏所需要的算法都不相同，但是游戏里运行算法的计算方式是一致的。

如加速度方程，在代码中的实现实际上如就是

v+=a；
s+=v；

了解游戏算法的基本机制后，可以稍微扩展下，比如碰撞算法：

基本上每个算法的推导过程都可以单独作为一篇文章来讲了，感兴趣的同学可以自行搜索算法名称。

另外一些比较常用的游戏算法也可以了解下，比如：状态机，字典树，寻路，排序……

当然，游戏基于专业的游戏引擎去制作，可以达到事半功倍的效果。了解游戏运行机制可以帮你更快速的上手游戏引擎。

微信小游戏与传统web游戏最大的区别在于API。

微信小游戏有一部分与微信小程序不一样的API。

其中最特别的就是「开放数据」。

主域可以传数据到微信后台，但是却无法从微信后台获取数据。而开放数据域可以从微信后台获取数据，但是却无法现实以及将数据传入主域。

所以主域想要显示微信后台数据，必须在开放数据域绘制好数据，然后将开放数据域的sharedCanvas当作image通过drawImage函数绘制到主域的canvas中。

开放数据的一些注意事项

sharedCanvas 只能被绘制到上屏 canvas 上。
上屏 canvas 不能调用 toDataURL，其 context 不能调用 getImageData。
sharedCanvas 不能调用 toDataURL 和 getContext。
不能将上屏 canvas 和 sharedCanvas 以任意形式绘制到其他 canvas 上，包括 drawImage、createPattern、texImage2D、texSubImage2D。
sharedCanvas 的宽高只能在主域设置

其中第5条常常容易被忽略，然后出现各种适配问题。

最后总结一下小游戏的运行机制。

游戏从入口文件进入以后，开始执行渲染器。
然后游戏的主逻辑会调用游戏下一步需要的场景模块。
场景模块中调用当前场景所需要的角色模块。
角色模块在接收到不同的指令后会产生不同的行为。
角色行为之间通过大量算法进行交互，最终产生完整的游戏效果。

「现场演讲的时候，你好像不是这么说的」