java aoi 服务器地图_游戏服务器AOI的实现

在一个场景里，怪物A攻击了玩家B，玩家B掉了5血量。玩家B反击，怪物A掉了10血量。玩家C在旁边观看了这一过程，而在远处的玩家D对这一过程毫无所知。这是MMO游戏中很常见的一情景，从程序逻辑的角度来看，把它拆分成以下几部分

怪物A感知玩家B在攻击距离内，释放了技能，并把整个过程广播给附近的玩家B、玩家C

玩家B感知怪物A在攻击距离内，释放了技能进行反击，并把整个过程广播给自己(玩家B)、附近的玩家C

玩家D因为离得太远，无法感知这个过程

可以看到，整个逻辑都是以位置为基础来进行的，玩家需要知道周边发生了什么。通常把玩家周边的这块区域叫做玩家感兴趣的区域，即AOI(Area Of Interest)，其大小即玩家的视野大小，上图画出了C、D这两个玩家的AOI。玩家AOI区域里的视觉变化(如攻击、掉血、移动、变身、换装等等)，都需要通知玩家。而不在区域内的变化，比如上面的玩家D的AOI不包含A、B，就不需要通知他。怪物是不需要知道这些视觉变化的，因此一般来说怪物是没有AOI的。

AOI的核心是位置管理，其作用一是根据AOI优化数据发送(离得太远的玩家不需要发送数据，减少通信量)，二是为位置相关的操作提供支持(例如玩家一个技能打出去，需要知道自己周围有哪些怪物、玩家，这些都是通过AOI来查询)。

PS: 场景中的玩家、怪物、NPC等统称为实体，下面有用到。

Interest列表

AOI的作用之一是优化数据发送，哪到底这个要怎么实现呢。以上面的情景为例，怪物A攻击时，是如何知道要把数据发送给B、C，而不发给D呢？最简单的办法是把场景里的玩家遍历一次，计算一下位置。但在实际中，一次攻击可能会下发4到5个数据包(攻击、掉血同步、怪物死亡、击退等等)，现在有些游戏喜欢做成一刀打一片怪，那数据包可能要到10个以上了，每次都计算一下显然是不太现实的。因此一般每个实体上都有一个列表，所有对该实体感兴趣的玩家(即AOI包含该实体的玩家)，都在列表上，一般把这个列表叫做Interest列表，或者观察者列表、目击者列表。例如，C在A、B的Interest列表里，D不在，所以A、B攻击时，把数据发给了玩家C，没发给D。

每当位置变化时，需要维护这个列表，这个处理起来还挺麻烦，后面再细说。

AOI区域的形状与大小

理想情况下，AOI区域是圆形的，因为现实生活中人在各个方向的视野大小都是一样的。不过用来玩游戏的手机、显示器可不是圆形的，因此为了方便，很多时候AOI是做成了方形的。一来AOI区域的大小并不需要很严格，大点小点一般没问题，二是判断点是否在圆内，需要计算平方，而判断是否在正方形内，只需要判断大小，效率高一些。还有另一个原因就是有些AOI算法，不太好实现圆形区域(如下面的格子算法)。

虽然实体看得比较远，例如玩家可以看到很远的那座山。但很多游戏不会给你拉那么远的镜头的机会(看到的远处的山实际是装饰用的，走不到那个位置，和AOI无关)，所以不少游戏的AOI都很小，只有几个格子，等同手机屏幕大小即可。折算到现实现生活中大概只有10多米，即只能看到旁边的那块石头。

AOI算法

AOI并没有什么特别优秀又通用的算法，甚至做一些同场景人数不多的游戏时(比如经典的传奇类游戏)，简单的遍历或者全场景广播都比其他算法优秀。其他算法是各有各的特点，下面简单说下一些通用的AOI算法

九宫格

如图所示，九宫格AOI算法核心是把整个地图划分成大小相等的正方形格子，每个格子用一个数组存储在格子里的玩家，玩家的视野即上图中标了数字的九个格子(如果视野大小为2个格子，再往外扩一圈即可，依此类推)。九宫格的优点是效率高，拿到坐标后即可跳转到对应的格子，视野范围内需要遍历的格子也不多，配合经典的格子地图(tile map)再合适不过，都不需要把像素坐标转格子坐标。其缺点是占用内存有点大，因为必须为所有格子预留一个数组，即使是一个数组指针，长宽为1024的一个地图也要1024