AOI（Area Of Interest），译为感兴趣区域，是MMO游戏中不可或缺的一个模块。

它所解决的问题是，计算场景中的每一个对象在其周围一定范围内的可见对象集，并在频繁交互的场景中，实时更新可见对象集。

随着游戏技术的发展，策划对AOI的需求越来越复杂，“玩家的任务怪物不能被其他玩家所见”、“队伍玩法相关的怪物和NPC只能被队伍成员所见”、“只有完成了剧情任务的玩家才能看到这个NPC”，这样的需求屡见不鲜。

但传统的AOI只能单一的以对象之间的距离来判断相互是否可见，已经无法实现上述需求。于是，分层AOI的设计应运而生。

1.需求概括

上述策划需求，可以概括为“场景的同一区域，不同的对象具有不同的可见性”。虽然这有悖于现实世界，但的确有不少游戏做了类似设计，毕竟这是策划建造的虚拟世界。

2.层的概念

继续思考，每一个对象的可见集合如何构成？

以玩家为例，他应该看见公共怪物、自己的任务怪物、所在队伍的任务怪物、剧情进度相关的怪物……显然，这是由若干个子集组合而成，我们把这些子集称之为层，图示如下：

图中不同的椭圆代表不同的层，他们把场景中所有对象分成了若干个集合。我们规定：

①同一层中的对象在AOI视野范围内，相互可见。

②若两个对象在任意一层中满足可见，则两个对象可见。

3.数据结构

①层编号

每一层是单个场景中的唯一资源，对应一个唯一资源编号，用一个非负整数表示。特别的，保留整数0作为公共层，几乎所有场景对象都设置了该层。

②层存储

对于对象，使用bitset来存储它所在的层列表，处于哪些层，就把哪些层的bit设置为1。值得一提的是，为了使bitset占用的空间较少，我们用尽量小的整数表示层编号，分配上从小到大依次分配，回收后可重复利用层编号。

③层相交

使用bitset的intersects接口，可以方便的判断任意两个对象是否有共同层。

4.接口设计

以下列出关键接口的设计

1.为什么不在客户端做可见性屏蔽？

①服务端也有取AOI可见集合的需求，例如AI选敌。

②减少服务端向客户端同步的对象数量，以节省流量，提高性能。

③可见性是一个很底层的功能，直接实现在服务端AOI模块是合理的设计。

2.为什么不用副本场景做隔离？

①从策划层面来看，他们更倾向于把玩法放在大世界中，认为这样更MMO。另外，切副本场景会带来不太好的感受，也是他们抵触的原因。

②从程序角度来看，管理和切换副本场景是有开销的，过于频繁会带来性能问题。

3.分层AOI的层数有限制吗？

没有。但为了防止开发者滥用，最好加个限制，例如1000层。另外，在设计上要按需使用。除了公共层，其他没有对象的层都应该及时回收，有需要时再重新申请。

4.挥砍空气的问题如何解决？

可见性的差异，确实带来了这一弊端，就是看见别的玩家在挥砍空气。这一点，我们的策划在权衡之下觉得可以接受。

除了已经实现的需求，分层AOI还能支持哪些玩法呢？得益于设计抽象、使用灵活，我们可以大开脑洞。比方说，你可以让一个对象离开公共层来实现隐身的功能，你可以给VIP玩家设置VIP层投放更多的怪物让他爽，你可以在公共场景中进一步实现一个MaskAoi的功能，等等。