我要设计一款基于Rust的轻量级联机对战服务

(可直接跳到最后一行)

笔者非游戏业内人士,前段时间再次(自从2015年开始到现在不知多少次)对游戏开发感兴趣,于是开始了解有哪些游戏引擎适合新手学习。

去年学了rust,有了锤子找钉子,因此首先学了bevy。然而在学了几个月后,发现没有可视化编辑器确实很麻烦,建一个UI视图都是靠脑内定位,于是放弃。

然后开始学习godot。学了几周后,发现制作2D游戏很方便。而且它还支持rust开发,通过rust实现了steamworks集成。同时我也发现上架steam需要把游戏打磨得比较完善才行,否则700大洋打水漂,美术问题确实不好解决,因此退而求其次,打算做个2D休闲小游戏试试水。

再然后发现小游戏不适合用godot或者bevy来做,现在更流行的是cocos creator3、laya。

于是开始学cocos creator3,学起来挺容易上手的,顿时信心十足,决定发布一款能多人联机的2D小游戏到微信平台。

微信是有官方支持的游戏服务的,包含房间匹配、帧同步等开箱即用的功能。这大大节省了开发成本,不用搭建专业的游戏后端服务。

游戏还没做完,听说微信小游戏被批量首发吃广告费的玩法搞得流量低迷,微信小游戏的入口我都不知道在哪,我开始担心流量了,于是打算发到抖音小游戏平台。

然而抖音小游戏没有类似微信小游戏的游戏服务,没有官方的房间匹配与帧同步服务。

华为倒是有个联机对战服务,官方声称“目前服务处于免费阶段,期间华为承担服务器资源开销。后续如有政策调整,将会提前两个月通知,您可放心使用”。感觉不太放心,华为东西还是比较贵的,到时候改api不还得再掉一次头发。

(跳这里↓)
因此,我决定用rust写一款极其简单的联机对战服务,在客户端的使用方法就参考微信的api,主要功能只有创建房间、对局匹配、帧同步。


2025-12-12
补充一下:这个联机对战服务没有数据库,没有redis,没有使用任何缓存中间件,一切数据都在程序的堆栈中。这几天压测一下,看看到底什么德行。
另外,不打算开放源代码,可以开放无限制版的docker镜像和二进制程序(支持linux、windows),有cpu内存的地方就能部署使用,比如serverless。所谓无限制版,就是没有认证功能、随便部署使用、没有任何链接数、房间数的限制。

支持支持,rust入门到忘记反反复复好几次,开源不

个人还是觉得h5 的最好联机方还是走 headless 模式 :joy:

框架用rust,到时候游戏逻辑估计还要换到其他语言去。
rust写逻辑会凭空造出很多其他语言不会碰到的麻烦,比如说borrow checker的引用检查。
(学了rust,然后写了一些小东西,然后就是rust一生黑 :upside_down_face:

1赞

既然都学习了bevy,为何不走一波 fyrox

这是加入了rust邪教啊,一切东西都要用rust重构 :grimacing:

既然都入手了cocoscreator3了,为什么服务器不用node来写,同一种ts语言不爽吗

Rust写复杂业务那真是有得忙了,学了这个语言才发现,为什么这么好的性能而使用的人这么少。

用 rust 感觉不如用 golang。看下后端招聘就知道了。综合性能和就业前景,golang 靠谱些。
个人 solo 用 nodejs 就好了

没有服务端逻辑,只有定时消息广播功能,用户端发什么就广播什么

从golang转过来的,我写go容易忽略err,写个5万行的程序,上线后经常崩溃,实在修不动了。
我写rust就非常稳,重构了之前go项目,也是5万多行的程序,运行几个月直到服务器不续费都没崩溃。
当时写的小说网站

没仔细写过nodejs,感觉js前端后端和构建脚本各种各样的环境把我脑袋绕晕了,不过我本业是前端哈哈

是的,要是不用rust,吃那么多苦学rust,苦就白吃了 :joy:

挺好的,加油。

一直用fastify,ai加持。 。。效率杠杠滴!!

我收回我的话,已经在用 rust 了。后端性能和安全为王,从长远发展角度,用就要用最好的

你这是咋了

之前看麒麟子说他新项目要用 go?想着后面去看看他 go 写得怎么样,就先学了 go 。然后既然学了 go 的基础特性,索性就再学一下 rust 。
学完 go,没有啥特别的感觉。但是学完 rust,它的理念完全符合我对语言的设想,所有的痛点都 get 到,真心牛逼。所以新项目尝试用一下 rust 写后端

我的开发前几天遇到瓶颈了,我的设计中,一个帧同步房间就是一个异步,500个房间就是500个异步。
一开始使用ticker实现定时任务,发现ticker也会积压,不管是丢弃、爆发还是延迟,都不太对劲。
然后用sleep实现定时任务,sleep34毫秒,实际上并不是,可能四五十毫秒,也可能更多。
好在昨天rust开发群的热心群友帮我各种分析,最后发现是异步调度的粒度较粗(平衡妥协的结果),打不满cpu,异步太多时,会发生积压和爆发,表现就是帧同步的帧间隔忽大忽小,小到0毫秒,达到几秒。
后来另开一个节拍线程,产生30fps的定时信号,然后在一个异步中,集中执行500个房间的帧广播动作,也就是集中管理房间的方式,帧广播的时间一下子就稳定了,加到10000个房间,瓶颈也只在websocket本身的io操作上。
总结一下,就是异步别搞太多,不能乱用。

这个服务现在是单体服务,我的想法是把它部署在云托管平台上,比如腾讯的 腾讯云开发或者抖音的 抖音云中,都可以自动伸缩实例。
有一个问题就是,如果负载增加,增加了实例,这两个实例其实就是独立的,数据不互通的,玩家连接后端服务时,会随机进入其中一个实例中,只能和当前这个实例中的玩家匹配游戏。
不知道这个问题应该怎么低成本解决,或者不算问题?
大家怎么看呢?