我是HullQin,公众号线下聚会游戏的作者(欢迎关注公众号,发送加微信,交个朋友),转发本文前需获得作者HullQin授权。我独立开发了《联机桌游合集》,是个网页,可以很方便的跟朋友联机玩斗地主、五子棋等游戏,不收费没广告。还开发了《Dice Crush》参加Game Jam 2022。喜欢可以关注我 HullQin 噢~我有空了会分享做游戏的相关技术。
0. 《联机桌游合集: UNO+斗地主+五子棋》是什么?
这是我独立开发的H5小游戏,它是个桌游合集,每一款都可以联机,跟朋友一起玩。目前包括3款游戏:UNO、斗地主、五子棋,以后会持续开发新游戏。
特点
支持联机
跟朋友进入同一个房间,即可联机玩游戏。
- 《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个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。喜欢可以关注我 HullQin 噢~我有空了会分享做游戏的相关技术。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。