这是一个创建于 141 天前的主题，其中的信息可能已经有所发展或是发生改变。
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
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
 |
1
theqiang 141 天前 via Android
不懂，不知道是不是之前的网上蹦迪实现原理
|
 |
2
murmur 141 天前
剑三 25 人副本就乱的必须屏蔽特效了，万人同屏呢，怕不是连名字都不配显示
|
 |
3
shunia 141 天前  3
好像说了什么，又好像什么都没说
|
|
4
shunia 141 天前 2
介绍技术产品不能光说废话，至少稍微聊一下做到这件事情的一些方法和细节吧，做了什么样的优化导致能实现这样的效果？
而且两台 128 核的机器？和上面的那些测试在比啥啊？ |
 |
5
xiangyuecn 141 天前
看起来就像一个伪需求😂
|
 |
6
Jooooooooo 141 天前
这...来个视频展示效果呗.
|
 |
7
paradoxs 141 天前
什么游戏需要万人同屏啊。。 传奇打沙巴克吗
|
 |
8
kop1989smurf 141 天前 1
这个“万人同屏”其实光一个 AOI 并不能说明问题。
1 、每个游戏的同步频率不同。 2 、每个游戏根据需求（游戏类型，玩法，反作弊等综合因素）不同，导致每次同步的数据量不同。 3 、楼主举的 4 个例子，其硬件环境并不统一。 |
 |
9
Maboroshii 141 天前 via Android
一个 aoi 范围内有一万人吗？
|
 |
10
israinbow 141 天前 6
好, 可以去拉元宇宙大饼投资了.
|
 |
11
Huelse 141 天前
只是数据同屏？最后还是要分块的吧？
|
 |
12
learningman 141 天前
1080p 有 200 万像素点，万人同屏就是一人两百，大概 20*10
|
 |
13
mzlzero 141 天前
@learningman 不是一万人平分你的屏幕空间，比如一万人可以叠在一起
|
 |
14
Vindroid 141 天前 1
嗯，利好元宇宙
|
 |
15
leiuu 141 天前
最近正好在看《架构之美》，看到 MMO 立马点进来了。
|
 |
16
lysS 141 天前
@learningman 产品就是这样的，起尼玛一些什么玩意名字。其实就是 1w 长并发
|
 |
17
Kinnice 141 天前
使用 2 台 128 核服务器，从上面挨个阅读下来我以为是两台 8 核呢。
每个数据摘要都没有可对比性。每个数据摘要中的 cpu 性能都没有体现，i3 和 i9 可不一样 |
 |
18
cheng6563 141 天前
做的不错，有版号了吗
|
 |
19
paopjian 141 天前
玩过 EVE 吗?
|
 |
20
danhahaha 141 天前
我 5 年前就实现了一个万人同屏抢红包
|
 |
21
seakingii 141 天前 5
晕死,别人好心开源个东西,没必要一堆嘲讽吧.
有用就用,感觉没技术含量就轻轻放过吧. 就我自己来说,感觉这个"万人同屏"确实是非常复杂的,很有技术难点 |
 |
22
guabimian 141 天前
游戏是互联网产品里最有技术含量的 无论服务端 客户端 图形图像 音视频 算法等等各方面
做 crud 的就不要随意鄙视啦 |
 |
24
qq296015668 141 天前
大佬。先膜下
|
 |
25
luckyrayyy 141 天前
我玩过同屏，人数最多的游戏是永恒之塔，最多号称 3000 vs 3000 打架， 不光特效、人物模型需要魔改客户端文件屏蔽，角色名称都得屏蔽显示，然后卡成 ppt....
|
 |
26
chairuosen 141 天前
消息风暴怎么解决
|
 |
27
yaott2020 141 天前 via Android
B 站那个修狗夜店就是这个做的吗？
|
 |
28
GGMM 141 天前
@yaott2020 修狗夜店我记得也是一个游戏，通过 danmu1 发送指令到游戏里来实现操控。但是蹦迪只需要一个人蹦，不需要与其它的用户交流，实体之间的数据不需要同步，所以我觉得单线程高并发应该就可以了。
|
 |
29
c0xt30a 141 天前
好奇问下：
1 。 每个玩家在算法里是抽象为一个平面上的圆 /正六边形还是一个三维的圆柱体？或者更复杂的不规则三维模型？ 2 。玩家之间的碰撞是怎么检测并模拟的？ 3 。寻路算法是怎么设计的？ 纯粹是好奇，如果问题很幼稚 /愚蠢还请 OP 原谅。 |
 |
30
snw 141 天前 via Android
老罗前些天做广告的那个网游？
|
 |
31
VirgilMing 141 天前
反正我知道的是
魔兽世界怀旧服运行到安其拉的时候，经历了测试服之后，暴雪一顿优化，开门事件该卡还是卡。 |
 |
32
wanacry 141 天前
就算是现实世界也没做到万人同屏啊？你有见过一万人同时在你的视野中吗？
|
 |
33
Nazgull 141 天前
感谢分享，没事看一下。
|
 |
34
x86 141 天前
文字太长不想看，想看视频效果，添加的假人不算
|
 |
35
whileFalse 141 天前
@wanacry @VirgilMing @c0xt30a @luckyrayyy @mzlzero @learningman @Jooooooooo
楼主应该只关注服务端技术。 客户端（玩家）很可能是只会移动和发送通用消息（可以理解为说话）。玩家在移动时，会进入离得近的其它玩家的视野，并从离得远的玩家的视野中消失。视野内其他玩家说的话自己能听到。 服务端只负责做这么几件事： * 计算玩家之间的视野范围，将其他玩家进入 /离开视野范围的消息通知当前玩家 * 当某个玩家移动时，将移动事件广播给视野内的其他玩家 * 当某个玩家说话时，将其广播给视野内的其他玩家 楼主研究的是怎么尽可能高效地计算视野，并依据视野广播相关消息。 |
 |
37
documentzhangx66 141 天前
楼主说的这些，无非就是想通过优化，来支持所谓的万人同屏。
但所谓的优化，就是通过牺牲一些东西，来换取另外一些东西。不过某些场景，是无法牺牲特性的。 另外 EVE 曾经请了世界级的顶级算法与服务器大佬做优化，但也就那样了，千人就开始卡屏。 制约 N 人同屏的性能问题，主要在于单核的算力不足，以及各种网络设备随机 IO 的性能差。 |
 |
38
taowen 140 天前
为啥分享个技术，这么多冷嘲热讽的？好好聊技术不行吗？
|
 |
39
yogogo 140 天前
摸下大腿
|
 |
40
winglight2016 140 天前
@wanacry 我的印象中有过三次，千禧年大家在广场上一起倒计时，亚运会火炬、奥运会火炬过来的时候大街上挤满了人，就是前胸贴后背的那种，我相信有一万人了
|
 |
43
tomari 140 天前
万人同屏（ Unity includes a 10,000 NPC scene ），这个人，为什么是 NPC ？ NPC 不是指的 non-player character 吗？
|
 |
44
fx777 140 天前
我有个疑问，万人国战，你服务器技术是撑住了。
但是用户的电脑 /手机， 能顶住吗？ |
 |
45
root01 140 天前
只能说牛逼 plus 了
如果真的在游戏这样玩， 我选择退出。 人多到我是谁我在哪都不知道呢。 |
 |
46
cs8425 140 天前 1
这老哥跳又出来了啊....
之前主打游戏状态之类的数据都该丢 redis 直接否定多数游戏场景的计算跟强一致性的刚需， 还是要靠内存内操作达成的事实 整个主题都在"redis 的异步读写每秒可以支持 10 万次"上面反覆横跳 Orz mark 观望一下这次又要卖啥药.... |
 |
47
iqoo 140 天前
随着摩尔定律的升级，MMO 万人同屏最终成功！
|
 |
49
th00000 140 天前
有压力测试结果可以参考一下吗? 压力测试方案是否能公开?
|
 |
50
starix 140 天前
@documentzhangx66 说的挺对；
曾经参与的 MMO 国战游戏，同屏压力在于客户端（网络数据传输以及显示压力），一个玩家周围最大能显示多少，按照九宫格或是半径计算，从服务端传过来每个周围玩家的数据都是非常庞大的（模型、时装、头发、装备外显等等）然后这种相互之间的数据都是在实施变化。 |
|
51
th00000 140 天前
@th00000 #49 看了一下知乎上的文章, 貌似万人只是在 AOI 内放着, 也没进行任何的接近真实的有效同步, 如果是这样的话, 离万人同屏貌似还有一些差距。
|
|
52
starix 140 天前
@th00000 真的是理论数据看看就行，我之前国战项目不是没跑过机器人压测，但是在真实问题前面，这些都是买家秀和卖家秀的区别。显示瓶颈可以通过算法控制单体玩家需要看到的玩家数和数据，但是网络瓶颈是我们当时遇到最无法解决的，需要广播出去的数据就那么些，但是同时并发广播给那么多个客户端，客户端接收的数据量又非常大，瞬时压力导致卡顿非常明显，以此影响战斗，得不偿失。
|
 |
53
scr 140 天前
万人同屏的 mmo 游戏，客户端服务器压力什么的先不说，可以先算算简单的移动同步需要多少的网络带宽。
|
|
54
wanacry 140 天前 via iPhone
@winglight2016 #39 但是是你的视野里同一时间装不下这么多人，你得来回扫视，才能让你感觉出有上万人 如果是站在比较高或者远的地方不需要扫视就看到了上万人，那么细节也想必是丢失严重的
|
|
58
shunia 140 天前 1
上面那些照顾 PO 主的是 PO 主 QQ 群里的群员吗？
这个东西就是懂的都懂，他说的确确实实全是废话，不懂的才会在那里瞎咧咧。 万人同屏从服务器端的纯技术实现上来说也根本就是废话，因为你不考虑任何实际情况的话，万人同屏不就是一万个用户信息的数据结构吗？即便加上消息系统，你不考虑带宽、延迟和前端实现的情况下，随便写不也能实现？ 再说测试用例的问题，一万个 NPC 放在同一个屏幕里，就好比 Unity 的 ECS 例子一样，同屏上十万个同方向移动的对象，fps 也能上 60 ，但是有意义吗？更何况他还拿两台 128 核的机器在这玩非真实场景的负载。 |
|
59
shunia 140 天前 3
更别说 TMD 代码仓库一点进去就是让你加 QQ 群，一句有用的话没有。
再加上我一看代码更来气，整个有用的就一个 bigworld 类啊，干啥了？给地图分块了。其他 50% 的代码是三方库。我一个前端都看得出来这是水代码啊 |
 |
60
devcat 140 天前
后面的这个名词解释笑死了
> 4. 万人同屏（ Unity includes a 10,000 NPC scene ） 在同客户端屏幕内展现 1 万个游戏对象。对于游戏服务器是将 1 万个游戏对象放入 AOI 范围内。 前面说的是万人同屏，但是英文却是 10,000 NPC ，众所周知 NPC 的全称是 non-player character ，也就是非人角色，那万“人”同屏指的是一个人非人同屏呗？ |
 |
61
pkoukk 140 天前
AOI 一万的意思是，中心的 BOSS 放了一个 AOE ，周围 1 万人都会掉血么？
想起我曾经玩的网游，客户端支持的同屏只有 100 左右，再多机器受不了 但是服务端显然不止，起码有 300-500 ，所以打团战的时候经常死于不明 AOE ，甚至有时候你被身边的敌人打死了，因为客户端同屏限制，你看不到这个人 所以恕我直言，更大的 AOI 反而导致玩家聚集时的体验更差。毕竟玩家不可能用 128 核的机器玩游戏 |
|
62
seakingii 140 天前
@shunia 随便扣帽子?什么毛病?
技术上有问题就讲技术上的问题,楼主骗钱就拿出证据. 我就是看不习惯这些没有证据就乱指责的人,还有你这种随便扣帽子的人.我是不是也可以说你是有扣帽子习惯的红卫兵的后代? 你不能要求所有做开源的人都是顶尖高手,不骗人钱,就算是水一点也不犯法. 如果楼主的代码能对别人有点帮助,多少也是好事.如果太水浪费了别人的时间,就是不得了的罪行了? |
 |
63
ysy950803 140 天前
写得挺好的，学习了。不知道楼主这个优化和 WOW 的无缝相位技术有什么优劣区别呢？
|
|
64
ysy950803 140 天前
回忆起早年九城运营 WOW 的时候，去阿拉希盆地（不是战场，是野外地图）打阵营战，估计也就几百上千人，双方交战卡成 PPT ，然后没多久整个服务器就宕机了，甚至还有回档的情况，那些没参与战斗掉线的玩家一脸懵逼哈哈哈。
|
 |
65
crackhopper 140 天前
@cs8425 我跟你观点一样，上次就跟这哥们 battle 过一次，还被对方一顿喷，说我缺乏工程师素养。
|
 |
66
hackfly 140 天前
客户端没必要万人同屏吧，顶多几十人就可以解决了，一般都是基于距离剔除
|
 |
67
aru 135 天前
期待 OP 忽悠成功，拉到投资
|
 |
68
greatx 135 天前
小作文语气和民科一模一样，看着就不太靠谱。
|
 |
69
xingyuc 135 天前
reddit place 那种不限时间就好玩了
|
 |
70
felixcode 135 天前 via Android
楼主开创了"万人同屏"这个词并掌握了解释权和实现权，谷歌搜索排名第一。
|
Select Language