超大地图MMORPG的场景管理
一张地图上的PLAYER和NPC等是存放在一个list中的，地图超大那么上面的PLAYER就可能超多（预计大于２００），这样的话每个行走动作都要发送２００条以上的消息，这对于服务器是一种很大的负担，而且这种负担是呈级数增长（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中，那么每次行走只需要把消息发送给最多４个相临区域的Player
·客户端的list只保有本玩家附近的player和npc
优点：大大减轻了服务器遍历list的负担、减少了发送消息的数量、减轻了客户端的负担
缺点：实现非常复杂、而且在服务器需要不断判断玩家是否跨越区域
方案四：
·服务器上场景的每个TILE保存一个Object指针用来绑定该格子上的player或NPC
·玩家行走、进入和离开等事件发给玩家周围一定范围内的player
·客户端保有该player周围一定范围内的player和npc
优点：处理起来极为直接、避免了耗时链表遍历（典型的以空间换时间）
缺点：地图每个TILE都要加入一个指针变量（管理不善容易出错）、每次发送场景广播要遍历所有TILE
方案五：
·服务器上每个场景用一个list来保存上面的player和NPC
·不使用事件通知，而使用状态位置通知的方式通过定时发送状态来更新客户端的player和npc状态
·客户端保有该player周围一定范围内的player和npc
优点：处理比较简单
缺点：实时性太低，对于要求同步比较精确的ＡＲＰＧ不太适合
