目前在做一个超大地图MMORPG的场景管理部分,客户端通过动态预读解决了超大图量的动态加载,但是在做人物行走的时候遇到了一些问题:
  一张地图上的PLAYER和NPC等是存放在一个list中的,地图超大那么上面的PLAYER就可能超多(预计大于200),这样的话每个行走动作都要发送200条以上的消息,这对于服务器是一种很大的负担,而且这种负担是呈级数增长(10个玩家都走一步服务器将发送10*10=100条消息,而200个的话就是200*200=40000条消息!),可能任何服务器都无法负担。
  肯定有很多朋友都遇到了类似的问题,很想知道大家是怎么解决的?
  通过在新浪论坛和大家的讨论,得到了以下几个方案,希望对大家有所启发:

方案一:

 ·服务器上每个场景用一个list来保存上面的player和NPC

 ·玩家行走、进入和离开等事件发给list中的所有player

 ·客户端的list保有该场景上的所有player和npc

 优点:处理起来简单直接

 缺点:发送的消息会随玩家数量的增加而暴增、客户端负担很重

方案二:

 ·服务器上每个场景用一个list来保存上面的player和NPC

 ·玩家行走、进入和离开等事件只发给该玩家一定范围内的Player

 ·客户端的list只保有本玩家附近的player和npc

 ·在服务器可以考虑使用hash表来优化查询速度

 优点:减少了服务器发送消息的数量、减轻了客户端的负担

 缺点:实现相对复杂,服务器负担大大加重(因为要不断判断玩家间的位置关系)

方案三:

 ·在服务器上把场景划分为小区域(大于屏幕大小)。每个区域对应一个list,场景中的所有对象按他们的位置加入到对应区域的list中,那么每次行走只需要把消息发送给最多4个相临区域的Player

 ·客户端的list只保有本玩家附近的player和npc

 优点:大大减轻了服务器遍历list的负担、减少了发送消息的数量、减轻了客户端的负担

 缺点:实现非常复杂、而且在服务器需要不断判断玩家是否跨越区域

方案四:

 ·服务器上场景的每个TILE保存一个Object指针用来绑定该格子上的player或NPC

 ·玩家行走、进入和离开等事件发给玩家周围一定范围内的player

 ·客户端保有该player周围一定范围内的player和npc

 优点:处理起来极为直接、避免了耗时链表遍历(典型的以空间换时间)

 缺点:地图每个TILE都要加入一个指针变量(管理不善容易出错)、每次发送场景广播要遍历所有TILE

方案五:

 ·服务器上每个场景用一个list来保存上面的player和NPC

 ·不使用事件通知,而使用状态位置通知的方式通过定时发送状态来更新客户端的player和npc状态

 ·客户端保有该player周围一定范围内的player和npc

 优点:处理比较简单

 缺点:实时性太低,对于要求同步比较精确的ARPG不太适合

05-23 16:27