《无尽之剑-命运》PVP后台设计

简介：《无尽之剑-命运》是一款在IOS上经典的单机动作类游戏《无尽之剑》系列的基础上开发的一款网络手游。包含各种关卡副本战斗，装备收集强化，宝石，药剂等多种玩法的。其中PVP的法玩是最能体现出玩家战斗力的玩法。玩家通过PVP战斗可以奴役别的玩家成为自己的奴隶，鞭挞他获得金钱，也可以去解救自己的好友脱离别人的魔掌。

主要玩法：

1.搜索N个相应等级段的可以被奴役的玩家

2.与搜到的玩家进行PVP战斗，胜利后使他成为自己的奴隶

3.搜索处于奴隶状态的好友

4.解救好友（与好友的奴隶主）战斗，胜利后使好友成为自由人。

5.反抗，玩家自己可反抗自己的奴隶主，与他战斗后胜利后可以成为自由人。

6.鞭挞，在有奴隶的情况下对其史诗鞭挞行为获得金钱奖励。鞭挞有CD和次数限制，次数用完之后自动释放奴隶

7.释放，直接释放自己的奴隶使其成为自由人。

后台设计：

其中GameSvr是我们的游戏逻辑服务器，DB是数据服务，PVPSvr承担pvp的查询以及状态变更的工作。GameSvr把玩家的信息（等级，名字战斗力等）同步到PVPSvr。GameSvr在需要PVP操作（查询，战斗）的时候向PVPSvr发起请求。如果是战斗请求的话，PVPSvr会回给GameSvr PVP战斗对象的RoleId，然后GameSvr通过RoleId从DB中拉取对象的战斗数据进行战斗。战斗节结束后根据战斗结果，把战斗结果发给PVPSvr，PVPSvr进行状态关系的变更。

这边PVPSvr维护的玩家数据采用固定最大数量，在达到最大数量后按LRU策略淘汰。采用固定长度可以采用共享内存保存玩家数据，可以保证在重启之后不丢失数据。考虑到PVP中玩家能够改变的状态（奴隶，奴隶主），自己的奴隶，自己的奴隶主，这些状态的变化都会引发数据的变化，使得数据不会被优先淘汰。这样系统优先淘汰的会是那些最近没有上线，没有PVP状态变化的玩家，这样损失的也只是搜索对象库中的对象。这样最大数量的设置只需要保证活跃PVP玩家的状态不丢失（PVP状态会再一定时间后自动消失比如自动释放奴隶），并保证有多余的可以去保证正常的搜索冗余。按照PVP自动释放时间（2小时）计算，同时在线能够PVP的玩家1w，玩家平均在线时间40分钟计算。2小时内最对会有3w的PVP活跃玩家，PVP还需要更改PVP对象数据，这样涉及到的PVP活跃数据大概是6W。这样大概设置20W的最大数据上限应该可以满足PVPSvr的设计需求。按照单个玩家数据256byte的量算大概需要占用50mb的内存，完全可以接受。

PVPSvr也会把数据同步更新到一个用于备份的数据库，在启动时发现丢失共享内存时会自动从tcaplus拉取数据进行恢复

设计难点：

1.由于游戏的玩法设定，我们的PVP战斗是玩家可以进行操作的，并且操作很大程度决定了PVP最后的结果。所以PVP战斗的后台是不可能像大部分流行网游一样在战斗开始的时候就自动演算完战斗结果。所以会产生玩家正在战斗中这一状态。需要保证战斗中的玩家无法被其他玩家发起战斗。不然会引起类似于A在于B战斗开始之后，C又与B开始了战斗。最后A和C战斗结束的时序不同，引起的B最后的归属权的纠纷。所以既要保持战斗对象这一资源的独占性，也要保证这一独占资源能够被正常的释放。

2.搜索对战对象需要一次生成4待选对象的列表，且每次都是随机的结果。

考虑前面的设定这4个待选的对象都有可能被玩家选为PK对象，根据上面的设定战斗中的对象是不能再被PK的。那么在大量玩家查询的时候保证之前被选到过的短时间内不再次被选到也是有必要的。

根据游戏设定搜索的对象需要于玩家自己的等级相匹配，比如 20 - 29这一等极段。根据数据显示等极段内的玩家并不是均匀分布的

根据游戏设定PVP功能在30级开。按同时在线最多10w来算，改等级段最多在现在4000人左右，由于PVP是可以搜索到离线玩家来进行战斗的，按1:5的在离线比，那么大约有2w的待选数据。

最终实现：

针对第一点。考虑到在线玩家随时可能发动战斗。所以设定在线的玩家是不可以被其他人PK的。在线的玩家可不会被搜索到。正在被PK的离线玩家也是不可以再次被PK的，同样不能被搜索到。所以在PVPSvr的自维护的玩家数据中会有一个标记表示是否是能被搜索到的。然后在状态变化时更新是否能被搜索。

对于第二点。首先根据等极段，每个等极段使用一个map保存该等级段内所有可被搜索到的玩家数据的RoleID。采用并在玩家可搜索状态发生变化是做删除加入操作。等玩家等级发生变化时,将RoleI从旧等极段的map中移出，再加入新等极段的map。这样在搜索时便很容易定位到相应等极段的map。由于map的红黑树的数据结构，要是随机访问的话平均O(N/2)的开销似乎有点大(N表示等极段内玩家的数量)。与策划交流之后在，随机取N个设定的目的其实是为让每次搜索结果不重复的原因。那么只要能让每个玩家每次搜索的结果能够不一样并且尽量不采用随机访问的方法成了考虑的重点。

这边采用了一个方法，把每个等极段的map的遍历迭代子保留起来。每次查询时迭代子next 4次，找到4个RoleID，要是到头的话回到Begin开始。时间复杂度降至O(4)。由于RoleID在红黑树中都是顺序排列的，在数量足够多的情况下多数情况下是可以保证短时间内下次取得是4个不重复的ROLEID而且也不是被其他玩家所搜索到的。如果数量不够多，每次有一样的结果也是合理的。

测试效果：

以20wPVP数据信息做测试所有操作（查询，pk）都可以保持在100微秒内完成。