目前在做一個超大地圖MMORPG的場景管理部分，客戶端通過動態預讀解決了超大圖量的動態加載，但是在做人物行走的時候遇到了一些問題：
　　一張地圖上的PLAYER和NPC等是存放在一個list中的，地圖超大那么上面的PLAYER就可能超多（預計大于２００），這樣的話每個行走動作都要發送２００條以上的消息，這對于服務器是一種很大的負擔，而且這種負擔是呈級數增長（10個玩家都走一步服務器將發送10*10=100條消息，而200個的話就是200*200=40000條消息?。赡苋魏畏掌鞫紵o法負擔。
　　肯定有很多朋友都遇到了類似的問題，很想知道大家是怎么解決的？
　　

方案一：
　·服務器上每個場景用一個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
　優點：處理比較簡單
　缺點：實時性太低，對于要求同步比較精確的ＡＲＰＧ不太適合