3D 游戏的万人同屏技术详解(2)

[gantleman]

全文地址
https://zhuanlan.zhihu.com/p/195059458

在<使用 redis 实现 5 万人同服的'相位技术'>中我介绍了基于九宫格和相位技术的空间管理技术。这里我们也要借鉴游戏服务器中“服务”的概念。可能有些同学没有接触过游戏服务器，对服务的概念不是很熟悉。服务可以看做是一个独立的线程环境。这个线程监听着一个消息队列。其它的服务可以发送消息给他。这种方式在服务器开发中的 go 语言，erlang 语言，skynet 框架中被广泛应用。消息队列保证了服务所创建的数据是私有并且多线程安全的，只能通过消息通讯的方式进行修改。服务的概念为多线程下使用数据的安全问题提供了保护。通过消息通讯建立了在多线程下的秩序。但这种方式在客户端使用的并不多。各种服务的框架也都是在服务器端使用的多。

客户端使用多线程开发管理 1 万多个线程将会是一场噩梦。而管理 1 万多个服务对技术水平要求也还是比较高的。针对客户端没有多线程的服务框架问题，我开发了 pelagia 框架。借用“服务”的概念来管理客户端多线程。通过内嵌 kv 数据库和预判以及服务私有数据的概念彻底消灭多线程死锁和依赖的问题。因为只有解决多线程的安全问题。才能进一步思考如何优化通信和计算以及存储的平衡问题。安全问题不解决所有的优化问题就会是空中楼阁。

全文地址
https://zhuanlan.zhihu.com/p/195059458

[devwolf]

@ConradG 个人观点，#71 更全面的 block 原因讲解远比#66 的"这个题主就真的很值得……block"更有意义。
即使 #71 交代了原因，若没有#70 楼无意中代表我发表了意见，我将无法从#71 得到新的观点。
我是个忙前端开发的应届生，完全不懂游戏这块，依旧保持着小白憧憬，很津津乐道的在看楼上大佬们之间的辩论，虽然不可能完全理解但想要尽量的留下印象。
我无法辨别你们两方观点的是非曲直，上面的记录使我觉得帖主应该会乐意参与的异议讨论（结果而言大概是没有回答#71 ）。
我觉得#71 远比#66 要妥当，若真如你所言帖主存在#71 的问题，看到这么吝啬赐教的大佬我只能怪罪于运气不好。
“尽量让自己的回复有意义”这是我对 v 站留下的印象（虽然我自己也很难做到），我依旧觉得#71 不是#66 的理由。

[devwolf]

@ConradG 首先，假设你说的“题主单纯的认知有问题”成立，那么“揣着明白装糊涂”明显是不合常理的，自然是“有其他目的”。
有哪些其他目的呢，不就是把话题的展开的更有意义。
“无预设的提问”并不受“预设”影响、“预设有偏差的提问能否有不受错误预设干预的完美回答”，
退一步问，上面所有展开辩论的预设都是完全错误的吗？

[psyche]

@devwolf #82
楼主提供的不是有意义的回答。
你没有发现吗，没有质疑楼主的回帖基本都是没有实际游戏服务端编程经验的人。
你可以看一下楼主前几天发的帖子，他在 Github 上所谓的开源项目一千多个 star 都是花钱刷的，这个他自己也承认，他声称这样是为了推广有用的技术，Github issue 里面都是他自问自答，对于楼主的项目和文章的质疑，他从来没有正面回答，只是胡搅蛮缠或者强调自己有十几年的经验也“写出了实际的开源代码”，“比你们空质疑强”。
根据楼主的发言，有经验的开发者觉得：“楼主的东西没有人用”，“楼主没有实际的高实时性游戏服务端编程经验”，这些是很自然的推理。这些是经验判断，经验不一定总是对的，但通常很有用。
楼主的东西做一些实时性不高的页游服务器或许没有问题，因为实时性不高的页游用什么做都问题不大。
质疑楼主的人跟楼主都没有仇，但是大家工作生活都很忙，没空陪楼主浪费时间。
前几年出现了大量做手游的初创公司，确实有一些公司做技术选型的服务端主程是新手，这几年由于版号限制这种情况几乎没有了，现在有能力做技术选型的人基本不需要楼主的东西，你大可放心，楼主忽悠不到人的。

以上都是经验判断，不一定是对的，你不信的话可以拿楼主的项目做个 moba，arpg 或者 fps 的 demo，测一下数据，然后回来打我们的脸。

最后提醒一下各位新人，要快速进步的话，最重要的技能是学会不要在什么地方浪费时间。

[gantleman]

@psyche <使用 redis 实现 5 万人同服的'相位技术'>这篇文章在知乎有 4 百多个赞，我不想质疑这些点赞的人都是没有实际服务器编程经验的人。为什么要回复你是因为你在教育年轻人什么是靠普。我没有说过我做的技术都是靠普的。靠普的技术我想也轮不到我去教。在关于 redis 的文章里 redis 主从集群是非常普通的技术了。独立位置服务也是被公司常常使用的技术。让我惊讶的是都 2020 年还拒绝使用 redis 。还在强调单线程是性能最好的服务器。还有拒绝使用分布式的服务器开发。难道你们的服务器都是基于汇编语言开发的单线程服务器？我刚入行的时候也有些老师傅教育我，汇编语言是世界上最快的语言。C 语言都是异端，java 语言只能开发网页。而如今我会使用 C 和 java 但再也没有使用过汇编。最靠普的东西不需要老师傅去教育。如今教育我的老师傅也不知道在哪了。linus 发明 linux 的时候只是一个在校的研究生，按背景口水人的话 linux 操作系统就不存在了。世界潮流浩浩荡荡，唯一靠普的就是保持开放的心态不断尝试新东西。最重要的技能就是学会浪费时间。

[leimao]

知乎吧，懂得人还是少，大多都是不懂跟风的。我基本很少在知乎上看技术的东西，娱乐的东西倒是可以看看。别对知乎太较真，也别把知乎当成知识和学术的殿堂。

[psyche]

@gantleman #84
认真回你，并发框架是很核心的关键代码，你想推广的话把你的核心代码精简一下，写个介绍吧，最好配上用数学语言对算法正确性的证明过程（说明为什么用你的算法能避免死锁，以及其他问题），讲并发的技术书都有这种内容，你写出来以后有高中数学基础的基本都能懂，有多少点赞根本无关紧要。

[gantleman]

@leimao
@psyche

谢谢回复，你们说我什么都没关系。但请不要再说年轻人就该如何了之类的话，年轻的压力已经很大了，请多体谅他们。

[psyche]

大家都听说过“民间科学家”吧，民科声称自己解决了悬而未决几百年的科学难题，专家说你这是错的，民科表示自己热爱科学，几十年努力还要反抗学阀的压迫多么艰辛，学阀尸位素餐只会骗科研经费，看不懂我的高深解法于是说我是错的。民科声泪俱下感动了一些观众，于是有人说，不管民科是不是对的，至少讨论是有意义的，你看他多可怜，还有人点赞呢！

[icestraw]

@ConradG 我觉得你说的对，楼主根本没有想讨论技术问题，连软广都算不上。我能理解评论里心怀善意的人多，但是，姑且不论楼主讨论 /文章 /态度的问题，你们稍微翻一下这个人的实际作品（而非文章），就知道这就是个江湖骗子，只是手段稍微高明点。
我把他文章里的项目地址 po 出来给大家评判吧，截止 2020-09-10 知乎链接里的项目地址： https://github.com/surparallel/pelagia

[yueyoum]

本来在知乎 看到这篇文章， 当时想评论，但是 知乎没登陆， 懒得评论了

在 v2 又看到，


先说结论吧： 从 LZ 的言论来看，LZ 没做过高强度交互的 游戏服务器， 做的应该都是 CURD 。


我 N 年前 刚入行的时候 也搞了一个 万人同屏的 AOI 算法，

1w 个单位，都在随机移动，这些单位每帧把 以自己为中心，半径 10~30 米范围内的 其他单位选出来，（用来支持视野，或者 AOE 技能）

记得当时 这些单位先随机移动一次， 然后再获取自己的 AOI， 大概消耗 20ms 的样子 （ c++代码）

LZ 用 redis 试试 要多久。


高强度交互的游戏服务器， 状态和计算是无法分离的，

CS SOURCE 比赛服务器 是 100HZ， 每帧计算不能超过 10ms
COD 网游服务器 20HZ， 几百人在一个场景里，还有各种载具，物理计算，弹道计算，服务器 50ms 能做完这么大规模的计算已经很厉害了

你玩玩 LOL 吧， 那么复杂的技能判定， 你放到一个通过网络的外部缓存， 试试， 卡的玩家怎么玩？

你说 redis 这么快， 怎么可能卡？


就算 redis 真的能 1 秒 10w 操作，1ms 100 次操作
那么 100 人的 团战，
每个人都在移动 （写 redis ）

[gantleman]

@yueyoum 谢谢你提供的失败经验。100 人团站，每个人每秒 60 帧提交移动数据，是每秒提供 6 千个数据。每秒 6 千次的写入压力 redis 还是可以承担的。

[pushback]

我不是做游戏的，我以前玩过剑网三，3d 游戏里好像有个视距的概念，剑网三那边拉大最多也是几百同屏渲染，因为太远了好像玩家这边细节上看不清楚。
顺便问下大佬如何应用服务器转游戏服务器有什么学习路线😂

[yueyoum]

上面没 打完 就发出去了， 继续：

每个人都在 移动 ， （写 redis ）
获取周围视野 （读 redis ）
释放技能 需要判断自己条件是否满足，甚至某些技能只有特定场景才能释放 （读 redis ）
这是一个飞行技能， 技能也搞成一个 actor 了， 它自己又要 (读写 redis )
技能打中玩家了， 要通知这个玩家 状态变更 （写 redis ）
玩家 扣血后， 给自己喝药， 这个药每秒加 10 HP (有是写 redis)

上面这些变化，周围其他玩家都要知道， 得通知周围玩家 获取视野，下发客户端 （读写 redis ）

这只是一个简单的例子， 一个玩家移动，释放技能，使用道具，视野同步 就要消耗 大概 10 次 redis io
但是考虑写放大，周围的玩家都在频繁交互，你一个 AOE 打了周围一圈， 周围一圈的玩家因为反弹伤害又给你打回来也 如果你周围有 10 个人， 就会放大到 100 次操作。

如果周围玩家 反弹的是 AOE 伤害， 那么 这个量级轻轻松松突破 1000 。

那我们就考虑这种情况， 就算玩家 在激烈战斗的时候 1 秒才操作一次， （事实上激烈战斗的时候 一秒操作 5 次轻轻松松）

100 个玩家 1 秒 会对 redis 产生 100 *1000 的 io， 刚好 1ms 100 的 io
仅仅是 100 人， 就把 redis 压垮了。

所以，高强度交互的游戏服务器， 数据只能在进程的内存内处理， 别说 redis 多块， 网络开销都能把人卡死。
一个 20HZ 的服务器， 每帧处理时间就算 40ms， 估计你网络传输就要花掉 10ms， 再加上 编码解码这些额外的工作，
也就是 一半的性能 被你 用 外部缓存给浪费了。


当然 LZ 如果做的是 CURD 项目， 那随意

[yueyoum]

@gantleman

>> 100 人团站，每个人每秒 60 帧提交移动数据，是每秒提供 6 千个数据。每秒 6 千次的写入压力 redis 还是可以承担的。


看来你从来 不考虑 交互啊， 所以扯出了 这么一个方案。

照 LZ 这么想， 无缝大地图 这个业界难题， 在 LZ 这里 轻松解决

可以去 网易 /腾讯 年薪 100W + 了

[livepps]

@yueyoum 赞同，强交互的网路游戏，服务端数据只能做在内存，扛不住的时候，才考虑把一部分耦合低的业务拆解出来放到其他服务器上跑。其实现在很少做什么几千，几万人同屏了，首先玩家体验不好，还有技术上没有好办法解决，最简单就是降低服务器的帧率。
现在更多的游戏类型，都是开房间的，轻松做成分布式，每个服务器开 n 个房间，房间服务器之间不交互。看知乎上说 dota2 的服务器，一台也就承载 100 局比赛，也就是 1000 人，国服在线好像是 50w 的样子，也就是需要 500 台服务器。

[livepps]

redis 是好东西，但不是用来解决这个技术难点上的。

[OneMan]

实时性这么高的东西，这些数据不放内存而放 Redis，疯了吧！
方向错了，越努力越偏远。

[OneMan]

@psyche 我也感觉 LZ 是“民间科学家”，扯名词厉害。互动性要求这么高的东西，还用 redis 还毫秒级，醉了。跟他扯多了都是没意义的。

[DaRenCC]

强烈要求 LZ 去西山居，帮他们改善剑网三的攻防系统，打攻防只能看名字，太离谱了

[lele2019]

技术圈的眼球看来还是很好赚的。。。看来掌握到了 UC 震惊部的精髓。。。