目前在做一个超大地图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
　优点：处理比较简单
　缺点：实时性太低，对于要求同步比较精确的ＡＲＰＧ不太适合