我是 HullQin，公众号线下聚会游戏的作者（欢迎关注公众号，发送加微信，交个朋友），转发本文前需获得作者 HullQin 授权。我独立开发了《联机桌游合集》，是个网页，可以很方便的跟朋友联机玩斗地主、五子棋等游戏，不收费没广告。还独立开发了《合成大西瓜重制版》。还开发了《Dice Crush》参加 Game Jam 2022。喜欢可以关注我 HullQin 噢～我有空了会分享做游戏的相关技术。

0. 《联机桌游合集: UNO+斗地主+五子棋》是什么？

这是我独立开发的 H5 小游戏，它是个桌游合集，每一款都可以联机，跟朋友一起玩。目前包括 3 款游戏：UNO、斗地主、五子棋，以后会持续开发新游戏。

地址：game.hullqin.cn

特点

支持联机

跟朋友进入同一个房间，即可联机玩游戏。

• 《UNO》支持 2-10 人一起玩。

• 《斗地主》支持 2-4 人打牌。

• 《五子棋》支持 1-2 人下棋。

第一个进入房间的人会成为「房主」，可以修改游戏人数，人齐后房主可「开始游戏」。

游戏中断可随时重连

开始游戏后，如果你掉线，或者关闭了网页。不论过多久，只要房主没结束游戏，你重新回到这个房间，就可以继续对局。

哪怕所有人都关闭网页，只要游戏没结束。大家回来后，仍然可以继续对战！

当然，如果游戏还没开始，或游戏已经结束，那么你关闭网页，就退出房间了。

允许观战

当房间人数满时，之后进入的房间的人可以观战。

等到游戏结束，如果房间有空位了，访客点“刷新”，即可变成玩家，玩家位先到先得（晚了就还是访客噢）。

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. 我的游戏是小游戏，只要保证总的游戏数据量足够小（甚至能够 1 个 TCP 包发完），那么你把 100b 压缩成 20b 其实是无意义的，他们可能只是 21ms 和 20ms 的差别。用户能感觉到 21ms 和 20ms 的差别吗？不能。

2. 方案二增量更新确实诱人，尤其是针对《王者荣耀》这种实时性强、数据量大的游戏。但我是个小游戏，实时性没那么强。而增量更新带来的前后端开发成本，是更高的，远高于收益。

后台选型

这个其实只要支持 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.写在最后

我在开发《联机桌游合集》时，每个细节都在追求极致用户体验，并总结了一些经验，今后将总结更多，欢迎大家关注专栏《极致用户体验》。欢迎大家阅读、点赞相关文章：

• 《网页里的「返回」应该用 history.back 还是 push ？》

• 《你的 Link Button 能让用户选择新页面打开吗？》

• 《一行简单的样式，让网页有「高级感」》

• 《2 行代码，让你的 UI 适配移动端、PC 端，快来收藏》

• 《《 合 成 大 西 瓜 》 重 制 版 ！（ 联 机 版 在 做 了 ）》

• 《用 86 行代码写一个联机五子棋 WebSocket 后端》

• 《H5 小游戏技术选型分析，低代码?小游戏框架?canvas 或 SVG?还能用 React？》

我是 HullQin，公众号线下聚会游戏的作者（欢迎关注公众号，发送加微信，交个朋友），转发本文前需获得作者 HullQin 授权。我独立开发了《联机桌游合集》，是个网页，可以很方便的跟朋友联机玩斗地主、五子棋等游戏，不收费没广告。还独立开发了《合成大西瓜重制版》。还开发了《Dice Crush》参加 Game Jam 2022。喜欢可以关注我 HullQin 噢～我有空了会分享做游戏的相关技术。