AOI（兴趣范围Area Of Interest） 游戏中的广播的类型 全服广播、地图广播、社交关系、交互目标、玩家自身 全服广播的特点：频率不高 地图广播的特点 ：移动同步广播频率高，流畅度，做插值，服务器有压力 社交关系：低频率 交互目标：P2P，点对点，服务器中转，广播频度低 玩家自身：客户端和服务器的广播，别人不知道，只和自身相关，频度也不会高

【问题一】 同一个地图超过50人就很卡，服务器端怎么分析怎么解决？ 承载结构，最大允许多少人 假设一个地图有100人，100个人移动，其他人都要知道 。 至少要发100*100次同步消息。同步消息间隔又需要很短。 假设1秒要同步10次，1秒需要有10万次消息处理。还有包括消息的收发，会有更多消息处理，客户端会非常卡。 假设一个消息包需要~3MB/S =24Mb/S ，100人就需要2400Mb/S，带宽压力大，转发率压力大（每秒转发多少个包，剩下的放路由器缓存里，无法一次性转发） 如何将1台服务器只能承载100人数，提升到承载1000人数，提升10倍甚至更高呢？

MMO可以插值校正，频度降低，【FPS不行，服务端不做强验证】 区分服务器线路，限制人数 技术层面：在地图消息同步的基础上 使用AOI 只关心玩家身边的人

建立AOI兴趣范围清单 只对兴趣范围内的目标广播 极大的降低消息处理压力与网络负载

所有的设计原则 兴趣范围的规范方案（划分范围，如何区别在身边） 对象与数据结构 高性能算法

区域划分 每个对象都有一个AOI管理器，有一个兴趣范围，放置一个数组，遍历周围的人，可维护的清单，半径N米的范围 消息的同步数量会减少，但不会大幅度减少性能，要比较 消耗量确实减少，但是CPU性能是否增加了吗？？？？

级别设定 AOI范围级别设定 Level3：是不是能看到，产生兴趣预先加载 Level2：产生兴趣，同步基本数据，同步的数据少，能看到 Level1：产生兴趣，同步基本数据，精准同步各种状态

伪代码 优点 不需要特殊的数据结构 易于实现 缺点： 计算成本较高（1+N）*N / 2 ，第1个人，需要对其它999人计算，计算量还是相当大的 1000人 =》 500500次消息量 ， 只减少一半，优化还不够

多线程：并行计算，提升计算效率 延迟计算：减少计算间隔（不需要每一帧进行计算） 分批计算：100 / frame （一帧计算100人）

【问题】距离计算：三维向量计算比较复杂 【设想】地图格子：格子内广播 【伪代码】格子的坐标，维护每张格子上的管理器，玩家离开旧格子，进入新格子 leave和enter要做一个全局的数据结构，一位数组，连续的内存地址，数组的查询最快，计算消耗低

优点 计算速度非常快 缺点 需要额外数据结构存储格子信息 需要额外的格子管理逻辑 实现复杂度高 【最重要的问题】格子边界问题

相邻格子，玩家不同步，可以进一步优化

9宫格，广播给其它9个格子，合理划分格子大小，最终影响性能消耗 格子太大，玩家数量少，发送的消息太多 格子太小，同步消息不多，性能消耗大

进一步优化 9宫格内在做半径计算

算法优化 优化数据结构，树结构，四叉树八叉树 降低运算消耗

（服务器）ECS架构（要求很高，容易做批量运算） 采用面向数据概念优化架构，提升运算性能

并行运算与GPU加速 利用并行计算提升性能 采用GPU加速减少CPU消耗

适可而止 避免过度优化