发布时间：2024-05-13 来源：网络
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消耗
适可而止
避免过度优化
