• <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)

            隨筆分類

            隨筆檔案

            文章分類

            文章檔案

            搜索

            •  

            最新評論

            閱讀排行榜

            評論排行榜

            国产亚洲精久久久久久无码77777| 久久青草国产手机看片福利盒子| 久久精品一区二区三区中文字幕 | 国产韩国精品一区二区三区久久| 久久99久国产麻精品66| 久久国产精品一国产精品金尊| 午夜肉伦伦影院久久精品免费看国产一区二区三区 | 超级碰碰碰碰97久久久久| 狠狠狠色丁香婷婷综合久久俺| 色诱久久av| 无码精品久久一区二区三区| 亚洲国产成人久久综合一| 国产精品久久婷婷六月丁香| 精品久久久久久无码中文野结衣| 亚洲欧洲日产国码无码久久99| 久久久久久青草大香综合精品| 99久久国产主播综合精品| 国产激情久久久久影院老熟女| 久久精品成人免费看| 国产999精品久久久久久| 欧美亚洲国产精品久久蜜芽| 99精品伊人久久久大香线蕉| 久久久久久亚洲精品不卡| 色偷偷91久久综合噜噜噜噜| 国产精品久久久久蜜芽| 久久午夜无码鲁丝片| 精品久久久久久久久久中文字幕 | 久久精品国产乱子伦| 国内精品久久久久久久久电影网| 久久人妻少妇嫩草AV无码蜜桃| 色偷偷88888欧美精品久久久| 97久久久久人妻精品专区| 久久精品国产99久久丝袜| 99久久精品国产一区二区| 精品久久久久久久久久中文字幕| 国产成人无码精品久久久久免费 | 亚洲国产精品成人久久蜜臀 | 色播久久人人爽人人爽人人片AV| 伊人久久大香线蕉综合Av| 久久久久18| 中文精品99久久国产|