• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            教父的告白
            一切都是紙老虎
            posts - 82,  comments - 7,  trackbacks - 0

            目前在做一個超大地圖MMORPG的場景管理部分,客戶端通過動態(tài)預(yù)讀解決了超大圖量的動態(tài)加載,但是在做人物行走的時候遇到了一些問題:
              一張地圖上的PLAYER和NPC等是存放在一個list中的,地圖超大那么上面的PLAYER就可能超多(預(yù)計大于200),這樣的話每個行走動作都要發(fā)送200條以上的消息,這對于服務(wù)器是一種很大的負(fù)擔(dān),而且這種負(fù)擔(dān)是呈級數(shù)增長(10個玩家都走一步服務(wù)器將發(fā)送10*10=100條消息,而200個的話就是200*200=40000條消息!),可能任何服務(wù)器都無法負(fù)擔(dān)。
              肯定有很多朋友都遇到了類似的問題,很想知道大家是怎么解決的?
              

            方案一:
             ·服務(wù)器上每個場景用一個list來保存上面的player和NPC
             ·玩家行走、進入和離開等事件發(fā)給list中的所有player
             ·客戶端的list保有該場景上的所有player和npc
             優(yōu)點:處理起來簡單直接
             缺點:發(fā)送的消息會隨玩家數(shù)量的增加而暴增、客戶端負(fù)擔(dān)很重

            方案二:
             ·服務(wù)器上每個場景用一個list來保存上面的player和NPC
             ·玩家行走、進入和離開等事件只發(fā)給該玩家一定范圍內(nèi)的Player
             ·客戶端的list只保有本玩家附近的player和npc
             ·在服務(wù)器可以考慮使用hash表來優(yōu)化查詢速度
             優(yōu)點:減少了服務(wù)器發(fā)送消息的數(shù)量、減輕了客戶端的負(fù)擔(dān)
             缺點:實現(xiàn)相對復(fù)雜,服務(wù)器負(fù)擔(dān)大大加重(因為要不斷判斷玩家間的位置關(guān)系)

            方案三:
             ·在服務(wù)器上把場景劃分為小區(qū)域(大于屏幕大小)。每個區(qū)域?qū)?yīng)一個list,場景中的所有對象按他們的位置加入到對應(yīng)區(qū)域的list中,那么每次行走只需要把消息發(fā)送給最多4個相臨區(qū)域的Player
             ·客戶端的list只保有本玩家附近的player和npc
             優(yōu)點:大大減輕了服務(wù)器遍歷list的負(fù)擔(dān)、減少了發(fā)送消息的數(shù)量、減輕了客戶端的負(fù)擔(dān)
             缺點:實現(xiàn)非常復(fù)雜、而且在服務(wù)器需要不斷判斷玩家是否跨越區(qū)域

            方案四:
             ·服務(wù)器上場景的每個TILE保存一個Object指針用來綁定該格子上的player或NPC
             ·玩家行走、進入和離開等事件發(fā)給玩家周圍一定范圍內(nèi)的player
             ·客戶端保有該player周圍一定范圍內(nèi)的player和npc
             優(yōu)點:處理起來極為直接、避免了耗時鏈表遍歷(典型的以空間換時間)
             缺點:地圖每個TILE都要加入一個指針變量(管理不善容易出錯)、每次發(fā)送場景廣播要遍歷所有TILE

            方案五:
             ·服務(wù)器上每個場景用一個list來保存上面的player和NPC
             ·不使用事件通知,而使用狀態(tài)位置通知的方式通過定時發(fā)送狀態(tài)來更新客戶端的player和npc狀態(tài)
             ·客戶端保有該player周圍一定范圍內(nèi)的player和npc
             優(yōu)點:處理比較簡單
             缺點:實時性太低,對于要求同步比較精確的ARPG不太適合

            posted on 2009-09-09 10:36 暗夜教父 閱讀(1394) 評論(1)  編輯 收藏 引用 所屬分類: Game Development

            FeedBack:
            # re: 超大地圖MMORPG的場景管理(轉(zhuǎn))
            2009-11-10 16:38 | pig345
            看看云風(fēng)說的那個AOI吧。  回復(fù)  更多評論
              

            <2009年9月>
            303112345
            6789101112
            13141516171819
            20212223242526
            27282930123
            45678910

            常用鏈接

            留言簿(2)

            隨筆分類

            隨筆檔案

            文章分類

            文章檔案

            搜索

            •  

            最新評論

            閱讀排行榜

            評論排行榜

            伊人久久大香线蕉综合网站| 久久久久久久97| 久久av高潮av无码av喷吹| 亚洲国产成人久久综合野外| 久久久久青草线蕉综合超碰 | 一级做a爰片久久毛片16| 久久亚洲欧洲国产综合| 亚洲va久久久噜噜噜久久天堂| 亚洲狠狠综合久久| 午夜久久久久久禁播电影| 久久国产精品视频| 国内精品久久久久久99蜜桃 | 浪潮AV色综合久久天堂| 久久综合给合综合久久| 久久综合久久综合久久| 久久人人爽人人爽人人AV| 亚洲七七久久精品中文国产| 久久综合久久久| 久久最近最新中文字幕大全| 久久发布国产伦子伦精品| 精品熟女少妇AV免费久久| 亚洲国产精品一区二区三区久久| 激情综合色综合久久综合| 久久亚洲高清观看| 久久久国产精品福利免费| 97久久精品无码一区二区 | 亚洲日韩欧美一区久久久久我| 亚洲国产成人久久综合碰碰动漫3d| 人人狠狠综合久久88成人| 久久人人爽爽爽人久久久| 亚洲精品乱码久久久久66| 狠狠综合久久综合88亚洲| 影音先锋女人AV鲁色资源网久久| 国产精品久久婷婷六月丁香| 久久久久人妻一区二区三区| 色综合久久无码中文字幕| 精品无码久久久久国产| 久久国产精品久久| 日本精品久久久久久久久免费| 久久综合日本熟妇| 亚洲国产精品无码久久久不卡|