0. 《联机桌游合集: UNO+斗地主+五子棋》是什么？
这是我独立开发的H5小游戏，它是个桌游合集，每一款都可以联机，跟朋友一起玩。目前包括7款游戏：UNO、斗地主、五子棋、象棋、德国心脏病、一夜狼、飞行棋，以后会持续开发新游戏。
特点
支持联机
跟朋友进入同一个房间，即可联机玩游戏。
- 《UNO》支持2-10人一起玩。
- 《斗地主》支持2-4人打牌。
- 《五子棋》支持1-2人下棋。
- 《象棋》支持1-2人下棋。
- 《德国心脏病》支持2-7人一起玩。
- 《一夜狼》支持3-10人一起玩。
- 《飞行棋》支持2-4人一起玩。
第一个进入房间的人会成为「房主」，可以修改游戏人数，人齐后房主可「开始游戏」。
游戏中断可随时重连
开始游戏后，如果你掉线，或者关闭了网页。不论过多久，只要房主没结束游戏，你重新回到这个房间，就可以继续对局。
哪怕所有人都关闭网页，只要游戏没结束。大家回来后，仍然可以继续对战！
当然，如果游戏还没开始，或游戏已经结束，那么你关闭网页，就退出房间了。
允许观战
当房间人数满时，之后进入的房间的人可以观战。
等到游戏结束，如果房间有空位了，访客点“刷新”，即可变成玩家，玩家位先到先得（晚了就还是访客噢）。
1. 我为什么要做《联机桌游合集》？
之前跟朋友聚会，但没带牌，很多桌游玩不了。
我去搜公众号、小程序，但大都充斥着广告，或只支持线上匹配，或交互复杂。
我们迫切需要——没广告的、支持朋友联机的、简洁的工具。
因为我自己懂一点点前端和后端，就做了些尝试。
上个月，我开了个公众号“线下聚会游戏”，用来发布这些“工具”，目前做了五子棋、斗地主、UNO。
但因为它是联机游戏，所以线上的朋友也可以玩。
2. 技术选型？为什么？
通信
毫无疑问，这是需要Client和Server频繁交互的场景。用HTTP轮询、长轮询都不合适，会浪费资源。
所以我选择了WebSocket作为通信协议。它跟HTTP一样也是基于TCP的，但差异在于，它Client和Server都可以主动发送数据，也随时可接收数据。
这样节约了带宽资源。
数据序列化协议
你可能会疑惑，这也需要决策？无脑JSON不就行了吗。
但我还真没用JSON。因为JSON是基于字符串去序列化，它的体积肯定会比基于二进制的序列化协议大一些。
因为涉及到频繁的数据交互，且我服务器网络带宽不高，我不想一个免费的游戏给我带来太多成本。所以最初的技术选型尤其重要（如果以后再改，是很难的）。
我期望有这样的协议：我定义好数据格式，比如五子棋游戏有2个字段，分别是“谁是黑棋”、“棋盘上棋子列表”。而我用第1位，0表示房主是黑，1表示房主是白。接下来8位，表示棋盘上有多少个棋子，假设为K，那么接下来K*8位，每8位就表示这K个棋子每个棋子的坐标。这样的数据序列化协议是最简短的。
但是我为什么要自己创造协议呢？这种东西，一定有现有的协议实现了！肯定不止我一个人想得到。
查了一下，还真有——Protocol Buffer。思路跟我心中的协议差不多，虽然空间比我心中的协议大了几位（可以忽略），但是扩展性比我心中的协议好很多。
所以，数据序列化协议，我选了Protocol Buffer。
这次技术选型，我又节约了带宽资源。
数据更新方案
这种桌游，一定是数据驱动的。服务端存一份游戏数据，前端根据数据得到当前各个数据状态，根据数据状态渲染出游戏界面。
有2种数据更新方案：
| 优点 | 缺点 | |
|---|---|---|
| 方案一：每次游戏数据更新，服务端同步全量数据给前端 | 可以有统一的版本控制 | 若游戏数据大，每次传输成本高 |
| 方案二：每次游戏数据更新，服务端增量更新数据给前端 | 每次传输成本低 | 可并发的增量更新，需要保证每个操作是原子操作；不可并发的增量更新，需要做好版本控制 |
如果是你，你会选方案几？你猜我选了方案几？
你可能以为我会故技重施，为了节约带宽而选择方案二。
但是我选了方案一。为什么？
- 我的游戏是小游戏，只要保证总的游戏数据量足够小（甚至能够1个TCP包发完），那么你把100b压缩成20b其实是无意义的，他们可能只是21ms和20ms的差别。用户能感觉到21ms和20ms的差别吗？不能。
- 方案二增量更新确实诱人，尤其是针对《王者荣耀》这种实时性强、数据量大的游戏。但我是个小游戏，实时性没那么强。而增量更新带来的前后端开发成本，是更高的，远高于收益。
后台选型
这个其实只要支持websocket都可以。我用了自己擅长的python，用了ASGI协议，用了Daphne实现。
但是，python解析protobuf是有成本的，好在python可以用C++实现。
最好的技术选型，其实是直接用C++改Nginx源码，以Nginx模块的形式实现小游戏后端。
但是开发成本比较高，我为了快速实现、落地、验证想法，就用了自己熟悉的python。后期有时间的话，我会用Nginx模块开发的形式重构后端。
前端选型
既然已经是数据驱动了，那么React再适合不过。把游戏数据当作State，收到后台更新时，就setState，那么UI就会自动更新。
当然Vue也可以，只是我对React更熟悉。
用户认证方案
用户初次访问，我会在后台Nginx埋下随机数cookie，有效时间很长。之后都通过这个cookie来校验用户。
没cookie的，websocket会拒绝建立连接。
之后用户能断网重连，也是因为他的cookie没变。如果用户删了cookie，服务器就不认识他了。
监控方案
要做一个平台，你至少要知道实时在线人数吧？这样才能知道服务器负载如何，能提前去扩容。
我用了某云平台的日志工具做监控。通过后台写日志，通过统计日志，展示服务监控。看个pv uv还是没问题的。
3. 技术实现亮点
UNO是迄今为止，我做的复杂度最高的桌游，熟悉我的朋友知道，UNO是我花了7天时间做出来的。
为什么这么快？
大一统后端框架
首先，得益于大一统后端框架。所有游戏，他的后端其实是同一套，只是配置文件不同（例如可设置的最大人数、最小人数、游戏名称等等）。
相当于我把游戏开发复杂度全部转移到了前端，后端只负责数据中转。也就是说，其实每个人收到的数据，是同样的（如果你玩斗地主，你能解析数据，你会发现你知道了其他人的牌。只是这个解析成本挺高的，你需要知道二进制协议才行）
我这么做，也是为了提升开发效率。
当然，可能有人会做外挂，但是我不会做在线匹配功能，只希望提供给一群关系好的朋友去玩，朋友之间，你还开挂吗？（分分钟不跟你玩了hhh）
前端脚手架和组件库
你访问一下3款游戏，会发现，他们外表长得很像，只是换了个皮肤（色号）。
因为我做了一套游戏脚手架和组件库，把公共能力全部都抽成了组件，以后开发新游戏时，只需要写那个游戏独特的业务逻辑，其它东西，都被脚手架生成好了，组件库也拿来即用，所以开发效率特别高。这也是我能7天开发出UNO的真正原因。
其它特色
- 服务端实现简洁，无数据库依赖，数据暂时都存于内存。
- 服务端如果需要更新重启，游戏数据保留！
- 有一套简单的DevOps体系，可帮助我快速开发、部署、上线。
4.写在最后
我是HullQin，公众号线下聚会游戏的作者（欢迎关注公众号，联系我，交个朋友），转发本文前需获得作者HullQin授权。我独立开发了《联机桌游合集》，是个网页，可以很方便的跟朋友联机玩斗地主、五子棋、象棋等游戏，不收费无广告。还独立开发了《合成大西瓜重制版》。还开发了《Dice Crush》参加Game Jam 2022。喜欢可以关注我噢～我有空了会分享做游戏的相关技术，会在这2个专栏里分享：《教你做小游戏》、《极致用户体验》。
我在开发《联机桌游合集》时，每个细节都在追求极致用户体验，并总结了一些经验，今后将总结更多，欢迎大家关注专栏《极致用户体验》。欢迎大家阅读、点赞相关文章：
- [极致用户体验] 网页里的「返回」应该用 hisroty.back 还是 push ？
- [极致用户体验] 你的 Link Button 能让用户选择新页面打开吗？
- [极致用户体验] 一行简单的样式，让网页有「高级感」
- [极致用户体验] 2行代码，让你的UI适配移动端、PC端，快来收藏
我还新建了专栏《教你做小游戏》，分享做小游戏的相关经验，欢迎大家阅读、点赞相关文章：
