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

这是我独立开发的H5小游戏，它是个桌游合集，每一款都可以联机，跟朋友一起玩。

目前包括3款游戏：UNO、斗地主、五子棋，以后会持续开发新游戏。

地址：game.hullqin.cn

特点

支持联机

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

• 《UNO》支持2-10人一起玩。
• 《斗地主》支持2-4人打牌。
• 《五子棋》支持1-2人下棋。

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

游戏中断可随时重连

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

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

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

允许观战

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

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

2. 我为什么要做《联机桌游合集》？

之前跟朋友聚会，但没带牌，很多桌游玩不了。

我去搜公众号、小程序，但大都充斥着广告，或只支持线上匹配，或交互复杂。

我们迫切需要——没广告的、支持朋友联机的、简洁的工具。

因为我自己懂一点点前端和后端，就做了些尝试。

上个月，我开了个公众号“线下聚会游戏”，用来发布这些“工具”，目前做了五子棋、斗地主、UNO。

但因为它是联机游戏，所以线上的朋友也可以玩。

3. 技术选型？为什么？

通信

毫无疑问，这是需要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还是没问题的。

4. 技术实现亮点

UNO是迄今为止，我做的复杂度最高的桌游，熟悉我的朋友知道，UNO是我花了7天时间做出来的。

为什么这么快？

大一统后端框架

首先，得益于大一统后端框架。所有游戏，他的后端其实是同一套，只是配置文件不同（例如可设置的最大人数、最小人数、游戏名称等等）。

相当于我把游戏开发复杂度全部转移到了前端，后端只负责数据中转。也就是说，其实每个人收到的数据，是同样的（如果你玩斗地主，你能解析数据，你会发现你知道了其他人的牌。只是这个解析成本挺高的，你需要知道二进制协议才行）

我这么做，也是为了提升开发效率。

当然，可能有人会做外挂，但是我不会做在线匹配功能，只希望提供给一群关系好的朋友去玩，朋友之间，你还开挂吗？（分分钟不跟你玩了hhh）

前端脚手架和组件库

你访问一下3款游戏，会发现，他们外表长得很像，只是换了个皮肤（色号）。

因为我做了一套游戏脚手架和组件库，把公共能力全部都抽成了组件，以后开发新游戏时，只需要写那个游戏独特的业务逻辑，其它东西，都被脚手架生成好了，组件库也拿来即用，所以开发效率特别高。这也是我能7天开发出UNO的真正原因。

其它特色

• 服务端实现简洁，无数据库依赖，数据暂时都存于内存。
• 服务端如果需要更新重启，游戏数据保留！
• 有一套简单的DevOps体系，可帮助我快速开发、部署、上线。

5.写在最后

我是HullQin，公众号【线下聚会游戏】作者，除了本文说的《联机桌游合集》，我还开发了《Dice Crush》，参加了国际赛事Game Jam 2022。喜欢可以关注我噢～我会为大家制作更多好玩的小游戏，并分享做游戏的相关技术。