```
因为 luacluster 已经成为了事实上的技术标杆。
只要你想研究无缝大地图和万人同屏甚至游戏服务器就绕不开 luacluster
```
楼主实在狂得可以，不去拉投资实在可惜。做技术讲究的是脚踏实地，你犯了这个大忌，难免在论坛里被人锤。
“成为事实上的标杆”要有事实，是哪个游戏用 luacluster 实现，并且成为标杆了？？我倒是没听过
“无缝大地图”之前就有人在做了的，网易、腾讯的一些网游都有，当然除非你觉得他们的地图不够大
“万人同屏”这个需求最大的限制是客户端而不是服务器，服务器其实只有 aoi 这一模块有压力而已
摘取自
https://tanronggui.xyz/t/847585?msclkid=c2b79945bef311eca9160fa12532cb75 的一些信息：
```
这样我们就实现了一个非常惊人和高效的异步通信系统。任意进程和线程中的对象通信只要最多 2 步就可以完成。找到 upd 端口发过去，找到线程队列发过去。在任意环境下只要拿到 entity id 就可以快速知道封包的目的地。实现在分布式网络内的任何对象之间像普通函数调用一样的调用。什么网络编程，什么多线编程可以统统见鬼去了。
```
事实上我们公司的 rpc 调用早就可以实现根据玩家 id 唯一直接异步调用，也可以根据服务器 id 异步调用，还能根据 lua 函数函数指针直接调用，比你这个方便多了，这个可以提高开发效率，但对运行效率有个毛用。游戏行业各家都有自己封装的 rpc ，没什么大惊小怪的
```
万人同屏顾名思义要做服务器上处理 1 万个玩家的位置同步问题。1 万个玩家的位置同步每次要产生 1 亿个消息。1 万乘 1 万产生 1 亿个消息。请记住 1 亿这个数字后面我们要反复提及到。
首先我们先分析 1 亿个消息的产生流程。服务器会收到 1 万个客户端发起移动的请求。1 万个请求是没有问题的，现在服务器处理 10 万个链接问题都不大。所以这 1 万个请求一般的服务器压力都不大。问题是这 1 万个请求，每个请求要产生 1 万个新的请求发送给其他的玩家。这样服务器就扛不住了。一下产生了 1 个亿的 io 需求，哪种消息队列都扛不住，直接 mutex 就锁死了。
所以我使用了 CreateMsgList 接口创建了一个消息 list 。哪么 io 请求就转变为插入 1 万个 list 的操作。然后将这个 list 和消息队列合并在一起。这样就 1 亿个 io 请求变为 1 万个 io 请求，io 请求一下就压缩了 1 万倍。同样的道理我们也可以把发送给给客户端的封包进行压缩。处理 1 亿个封包请求很难但处理 1 万个封包难度就低很多了。下面是封包压缩的部分代码
```
我寻思楼主是不是没做过游戏，甚至之前没做过底层。我见过的游戏服务器，哪个没有个 buffer ，所有发送的 io 都是缓冲成二进制流发出去，怎么就产生了 1 个亿的 io 。另外在游戏中请慎用压缩，游戏和 web 不一样的地方是通信频繁，但数据量小，一个攻击包、移动数据包才几个字节，启用压缩会导致客户端解包压力比较大。现在流量不值钱，还不如直接发送
```
我们要把玩家的移动描述成一段时间的状态。有位置，方向，速度，开始时间，停止时间的完整状态。这样在每个客户端就可以根据这些信息，推断出玩家移动的正确状态
```
这个，我都不知道要怎么说了。需要做在场景里移动的游戏，哪个不是这么做的？难道楼主之前做游戏是定时持续发送玩家的状态？ 而不是有变化才发？
要实现万人同屏的核心：比如如何减少 aoi 事件，用哪种 aoi 更优。客户端如何支持这么大的量还能不发热，如何渲染这么多实体，视角切换如何才能避免渲染看不见的实体，这些东西完全没提到