MMO 万人同屏实验成功发布!

2022-03-31 16:07:53 +08:00
 gantleman
3DMMO 的万人同屏是一个让我激动不已的技术挑战!我是在 08 年关注到了 3DMMO 游戏服务器并行化的问题。并于同年就开始了一系列的技术尝试。软件工程和其他的工程一样。对于新的想法就是反复尝试,反复失败的过程。其实每个游戏服务器工程师都会开发一个自己的软件框架。一来容易维护二来使用方便。我只是比较幸运和执拗,喜欢用自己框架尝试新的想法。“念念不忘,必有回响”,进过一系列的技术改进,终于实现了 3DMMO 的万人同屏。

luacluster 项目由两部分组成,服务器端的 luacluter 以及客户端的 uacluster_unity3d_demo 。虽然整合了 luajit, uvlib 等大量的第三方的开源库,但开发工作仍然非常的繁重。为了支持跨平台和兼容 unity 的坐标体系等,又做了很多非常复杂的实验。这个项目最大的难点在于,不能简单的把他归为分布式中的计算,存储或传输的任何一类问题。它是要在分布式的计算,存储和传输中寻找到一个恐怖的平衡点。

在 2020 年我个人曾连续写过 3 篇文章《使用 redis 实现 5 万人同服的“相位技术”》 《 3D 游戏的万人同屏技术详解(1)》 《 3D 游戏的万人同屏技术详解(2)》。这 3 篇文章围绕着一个核心问题。就是如何评估游戏服务器的性能?因为对游戏服务器性能评估的标准模糊,导致了现在游戏服务器技术开发方向的迷失。只有重新确立服务器性能评估标准,才能找回游戏服务器的技术方向。要评估服务器的性能,我们就要给出相应的标准。web 服务器有唯一的通用标准就是在线人数。也就是服务器的承载能力。在完成同样功能下,使用最少的硬件,承载能力越高越稳定的服务器,他的软件性能就越好。

但对于游戏服务器有着完全和 web 服务器不同的特点。无法使用简单的在线人数来衡量服务器性能。比如在 MMO 下虽然在同一个服务器内,但在不同地图的玩家之间,就几乎不会产生任何性能消耗。如果在极端情况下将每个玩家分别放入一个单独的地图。玩家之间不产生任何的互动。那么服务器的消耗将会非常的低。对应的服务器承载人数就会非常的高。但这种极端类型的服务器无法做出任何 MMO 游戏。所以在 MMO 下对服务器的评价标准,由最初的同服在线人数变为同地图在线人数。

可是随着无缝大地图技术的出现,这种同地图在线人数的评价标准又无法满足需求了。因为无缝大地图可以将任意整张地图分割为无数小地图。并将每个小地图分别放入不同的服务器。以提高整张大地图的承载能力。但这样的分割算法导致了新的问题。如果这些玩家集中到地图的某个点,服务器就不能正常工作!这就是说虽然整张地图可以承载的人数很高。但这种高承载能力只是一个障眼法。因为地图上某个区块的服务器会因为玩家的聚集而随机的崩溃掉。

虽然我们有无缝大地图的技术。但因为 AOI (游戏服务器内对象的可见范围)的承载能力很低。在整张大地图内导入过多的玩家会让服务器有崩溃的可能。最终使得服务器的承载能力受限于 AOI 的承载能力。从玩法上说可以在整张地图上导入很多玩家,但这些玩家之不能聚集在一起进行互动。使得整张地图承载能力的意义就非常小了。

所以对于 MMO 服务器的承载能力判定标准,也就由地图在线人数进一步变成了 AOI 内在线人数,也就是同屏的承载能力。这不是因为产品需求产生的技术路线。并不是因为某个产品需要万人同屏所以我们去研究万人同屏。而是因为我们解决了同服问题,解决了同地图问题,然后遇到了同屏问题。而同屏的问题又变的非常复杂。因为客户端在同屏上遇到了和服务器一样的技术瓶颈,导致在客户端上实现万人同屏也非常困难。客户端和服务器的问题互相纠缠,最终导致我们大多数人都迷失了。而我厌倦了这种对技术方向无休无止的争论。选择了以万人同屏为目标,重新梳理了全部技术栈,形成软件框架并最终使用云服务器完成了测试工作。

制约万人同屏的技术细节有那些呢?在服务器方面有如下几个问题:无法充分使用线程,异步场景和同步场景混乱,帧同步和状态同步混乱,对象的多个实体数据同步混乱等等。在客户端方面的问题:多线程通信技术不成熟,ECS 技术不成熟,渲染优化技术不成熟等等问题。我认为 MMO 万人同屏的实验成功是游戏软件领域重要的里程碑。将会解锁更多全新的游戏模式。

当前已经完成了所有基本测试工作,正在整合了 Mongodb 的数据库用于硬盘存储部分功能。接下来会开发增量存储以及传输加密等等功能。这将是一个长期的开发计划,期望最终实现一个通用的分布式 MMO 游戏开发框架。

行业内历年的数据摘要

1. 2013 年 bigworld 做过一次压力测试。在同一个地图上,使用 96 台(共 128 核心)服务器,可以承载 10 万个机器人。但每个机器人的 AOI 范围内有 62 个客户端。

2. 在 2019 年 kbengine 使用两台 8 核服务器,在同一个地图上可以承载 1 万人。AOI 范围内承载能力是 600 个客户端。

3. 在 2021 年通过进一步改造 kbengine, 实现了并行空间的技术,同样两台 8 核服务器,可以将 AOI 范围内承载能力提升到 1000 个客户端。

4. luacluter 使用 2 台 128 核服务器,将 AOI 范围内的承载能力提升到了 1 万个客户端。

开源项目地址

服务器开源地址: https://github.com/surparallel/luacluster

客户端开源地址: https://github.com/surparallel/luacluster_unity3d_demo

名词
1. AOI ( Area Of Interest ) 游戏服务器内对象的可见范围,即服务器内每个对象需要维护的可见和被见列表内对象的范围。当游戏对象发生移动时对应的列表需要增加或删除。维护列表的算法决定了游戏服务器的性能上限。
2. 无缝大地图( seamless maps )将一张超大的游戏地图按算法分割成多个小份,并分别由不同硬件服务器维护的算法。可以实现在一个超大地图上承载更多玩家。
3. 并行空间 将一个地图块同时创建到多个硬件服务器中,以提高单个地图块承载人数的上限的算法。
4. 万人同屏( Unity includes a 10,000 NPC scene ) 在同客户端屏幕内展现 1 万个游戏对象。对于游戏服务器是将 1 万个游戏对象放入 AOI 范围内。

原文链接: https://zhuanlan.zhihu.com/p/487028752
12102 次点击
所在节点    游戏开发
71 条回复
seakingii
2022-03-31 17:43:46 +08:00
晕死,别人好心开源个东西,没必要一堆嘲讽吧.
有用就用,感觉没技术含量就轻轻放过吧.
就我自己来说,感觉这个"万人同屏"确实是非常复杂的,很有技术难点
guabimian
2022-03-31 18:15:00 +08:00
游戏是互联网产品里最有技术含量的 无论服务端 客户端 图形图像 音视频 算法等等各方面
做 crud 的就不要随意鄙视啦
FrankHB
2022-03-31 18:23:15 +08:00
@paopjian 使劲儿时间膨胀完事……
qq296015668
2022-03-31 18:27:35 +08:00
大佬。先膜下
luckyrayyy
2022-03-31 18:48:03 +08:00
我玩过同屏,人数最多的游戏是永恒之塔,最多号称 3000 vs 3000 打架, 不光特效、人物模型需要魔改客户端文件屏蔽,角色名称都得屏蔽显示,然后卡成 ppt....
chairuosen
2022-03-31 18:52:29 +08:00
消息风暴怎么解决
yaott2020
2022-03-31 19:12:58 +08:00
B 站那个修狗夜店就是这个做的吗?
GGMM
2022-03-31 19:19:01 +08:00
@yaott2020 修狗夜店我记得也是一个游戏,通过 danmu1 发送指令到游戏里来实现操控。但是蹦迪只需要一个人蹦,不需要与其它的用户交流,实体之间的数据不需要同步,所以我觉得单线程高并发应该就可以了。
c0xt30a
2022-03-31 21:58:32 +08:00
好奇问下:
1 。 每个玩家在算法里是抽象为一个平面上的圆 /正六边形还是一个三维的圆柱体?或者更复杂的不规则三维模型?
2 。玩家之间的碰撞是怎么检测并模拟的?
3 。寻路算法是怎么设计的?

纯粹是好奇,如果问题很幼稚 /愚蠢还请 OP 原谅。
snw
2022-03-31 22:12:05 +08:00
老罗前些天做广告的那个网游?
VirgilMing
2022-03-31 22:21:56 +08:00
反正我知道的是
魔兽世界怀旧服运行到安其拉的时候,经历了测试服之后,暴雪一顿优化,开门事件该卡还是卡。
wanacry
2022-03-31 22:46:44 +08:00
就算是现实世界也没做到万人同屏啊?你有见过一万人同时在你的视野中吗?
Nazgull
2022-03-31 23:20:03 +08:00
感谢分享,没事看一下。
x86
2022-03-31 23:22:33 +08:00
文字太长不想看,想看视频效果,添加的假人不算
whileFalse
2022-04-01 01:24:39 +08:00
@wanacry @VirgilMing @c0xt30a @luckyrayyy @mzlzero @learningman @Jooooooooo
楼主应该只关注服务端技术。
客户端(玩家)很可能是只会移动和发送通用消息(可以理解为说话)。玩家在移动时,会进入离得近的其它玩家的视野,并从离得远的玩家的视野中消失。视野内其他玩家说的话自己能听到。
服务端只负责做这么几件事:
* 计算玩家之间的视野范围,将其他玩家进入 /离开视野范围的消息通知当前玩家
* 当某个玩家移动时,将移动事件广播给视野内的其他玩家
* 当某个玩家说话时,将其广播给视野内的其他玩家

楼主研究的是怎么尽可能高效地计算视野,并依据视野广播相关消息。
Yadomin
2022-04-01 03:20:56 +08:00
看到这个头像我又想起来 /t/693150 ,这么牛的项目怎么删库了呢
documentzhangx66
2022-04-01 04:25:11 +08:00
楼主说的这些,无非就是想通过优化,来支持所谓的万人同屏。

但所谓的优化,就是通过牺牲一些东西,来换取另外一些东西。不过某些场景,是无法牺牲特性的。

另外 EVE 曾经请了世界级的顶级算法与服务器大佬做优化,但也就那样了,千人就开始卡屏。

制约 N 人同屏的性能问题,主要在于单核的算力不足,以及各种网络设备随机 IO 的性能差。
taowen
2022-04-01 08:20:43 +08:00
为啥分享个技术,这么多冷嘲热讽的?好好聊技术不行吗?
yogogo
2022-04-01 08:50:54 +08:00
摸下大腿
winglight2016
2022-04-01 09:00:05 +08:00
@wanacry 我的印象中有过三次,千禧年大家在广场上一起倒计时,亚运会火炬、奥运会火炬过来的时候大街上挤满了人,就是前胸贴后背的那种,我相信有一万人了

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/844129

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX