[转载] 作者: 缘夙之
目前在做一个超大地图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不太适合