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

            永遠(yuǎn)也不完美的程序

            不斷學(xué)習(xí),不斷實(shí)踐,不斷的重構(gòu)……

            常用鏈接

            統(tǒng)計(jì)

            積分與排名

            好友鏈接

            最新評論

            網(wǎng)絡(luò)游戲的位置同步(轉(zhuǎn)載)

            有關(guān)位置同步的方案實(shí)際上已經(jīng)比較成熟,網(wǎng)上也有比較多的資料可供參考。在《帶寬限制下的視覺實(shí)體屬性傳播》一文中,作者也簡單提到了位置同步方案的構(gòu)造過程,但涉及到細(xì)節(jié)的地方?jīng)]有深入,這里專門針對這一主題做些回顧。

              最直接的同步方案就是客戶端在每次發(fā)生位置改變時(shí)都向服務(wù)器報(bào)告 ,服務(wù)器再轉(zhuǎn)發(fā)給周圍的其他玩家,其他客戶端將對應(yīng)的游戲?qū)嶓w移動到新的位置上。

              但是這樣存在一個(gè)問題,每個(gè)玩家的位置都是自己先開始移動,一段時(shí)間之后才在其他玩家的客戶端上表現(xiàn)出來。如果只是希望每個(gè)客戶端上看到的游戲?qū)ο蠖纪瑫r(shí)開始移動,那可以讓玩家的每一步操作都由服務(wù)器確認(rèn)之后再執(zhí)行,這樣誤差將縮減到不同客戶端之間的網(wǎng)絡(luò)延時(shí)差。但是顯然的,這樣的做法不可能真正被采用,因?yàn)檫@將使得玩家的游戲體驗(yàn)非常的糟糕。有誰能忍受連每走一步路都要卡一下的游戲呢?

              既然一定存在先后時(shí)間差,那需要一種方法來讓不同客戶端上看到的玩家位置不至于有太大的誤差,尤其是不能有影響到游戲公平性的誤差存在。根據(jù)誤差出現(xiàn)的直接原因:時(shí)間差,我們應(yīng)該能夠想到一個(gè)解決方案,那就是讓其他客戶端設(shè)法彌補(bǔ)掉這段時(shí)間差內(nèi)少走的距離。這樣的話也就要求我們的消息包中多帶一個(gè)開始移動的時(shí)間數(shù)據(jù),用于其他客戶端在收到這個(gè)消息包時(shí)計(jì)算對應(yīng)的玩家實(shí)體已經(jīng)移動過的時(shí)間和距離。

              我們以一個(gè)實(shí)際的例子來說明如何減少這種誤差的影響。假設(shè)玩家A以速度V從P1點(diǎn)去到P2點(diǎn),A的網(wǎng)絡(luò)延時(shí)為T1,在A旁邊有個(gè)玩家B,他的網(wǎng)絡(luò)延時(shí)為T2。B收到服務(wù)器轉(zhuǎn)發(fā)過來的移動包時(shí),A在其自己的客戶端上已經(jīng)移動了T1+T2的時(shí)間,在這段時(shí)間內(nèi)他自己已經(jīng)走過了V*(T1+T2)的距離。如果這時(shí)在B的客戶端上開始將實(shí)體A從P1移動到P2,那顯然兩個(gè)客戶端上看到的A的位置始終存在V*(T1+T2)的誤差。

              為了使A在B客戶端上顯示的位置與其實(shí)際位置的誤差盡可能的縮小,一個(gè)簡單的做法是直接將A的位置向前拖V*(T1+T2)然后開始移動,這樣兩者之間的誤差便消除了。但這樣會使得客戶端的顯示太魯莽,要讓其看起來平滑一些,我們可以考慮使用一些算法,比如計(jì)算出A從當(dāng)前位置走到P2點(diǎn)還需要的時(shí)間,然后加快其速度使其在規(guī)定的時(shí)間內(nèi)到達(dá)P2點(diǎn),這樣A和B看到的最終時(shí)間是相同的,但中間過程還是存在較多誤差。另一種較好的做法是先讓A以一個(gè)可接受的較快速度移動到其當(dāng)前應(yīng)該所在的位置稍前一點(diǎn)的地方,然后以正常速度移動到P2點(diǎn),這樣后面的移動情況與其實(shí)際移動情況基本吻合了。

              看起來這個(gè)方案很完美,但是這里卻忽略了一個(gè)問題:我們假設(shè)的是每次移動時(shí)都知道玩家要去的確切位置。這在靠鼠標(biāo)點(diǎn)擊來移動的2D游戲中是正好合適的,但是在WOW一類的靠鍵盤來移動的3D游戲中卻沒有辦法采用。WOW中的移動消息都只能向服務(wù)器報(bào)告當(dāng)前的坐標(biāo)及朝向信息。

              這類移動的位置同步其實(shí)也可以采用類似方案,服務(wù)器將移動玩家的當(dāng)前位置信息廣播給周圍的其他玩家,當(dāng)然其中也包含了時(shí)間戳。當(dāng)其他玩家收到這個(gè)移動包后,表示的是在過去的某個(gè)時(shí)間里該玩家移動到了這個(gè)位置。如果只是簡單地將其對應(yīng)的實(shí)體移動到這個(gè)位置,那同樣的,也存在位置誤差。

              與上一種情況類似,如果我們知道該玩家的移動速度,再通過數(shù)據(jù)包中的時(shí)間戳,假設(shè)該玩家還在以相同的速度朝相同的方向移動,那我們也可以預(yù)測出該玩家從開始移動到現(xiàn)在這段時(shí)間內(nèi)他走了多遠(yuǎn)了距離。我們也可以將其位置做適當(dāng)?shù)男拚⑹蛊淅^續(xù)移動下去。

              我們需要先停下來考慮一下這些算法的部分細(xì)節(jié)。其中出現(xiàn)了一些數(shù)據(jù)是否應(yīng)該包含在我們的每個(gè)消息包中,也就是我們需要考慮的另外一個(gè)問題:移動同步的消息中應(yīng)該包含哪些數(shù)據(jù),以及這些數(shù)據(jù)到底應(yīng)該向哪些玩家廣播。

              對于2D游戲的情況來說,我們的算法需要的數(shù)據(jù)有:玩家的速度V,玩家開始移動的時(shí)間T0,收到數(shù)據(jù)包的時(shí)間T1,玩家當(dāng)前位置P1和玩家要去的位置P2。T1和P1從當(dāng)前客戶端上都可以取到,而速度V一般來說不會經(jīng)常改變,至少不是每次移動時(shí)都不一樣,所以我們可以為速度的改變設(shè)計(jì)單獨(dú)的消息碼,這樣V值也是可以在客戶端上取到的。最后,每個(gè)移動消息中包含的數(shù)據(jù)只需要有移動到的位置P2和開始移動的時(shí)間T0。

              其他客戶端在使用特定算法將玩家移動到P2后會將其停在此處,直到收到下一個(gè)移動包時(shí)再開始移動。而對于在移動過程中又收到了新的移動包的處理過程基本類似,不做過多描述。

              對于3D游戲的情況,算法是基本相同的,但是沒有目標(biāo)點(diǎn),替換為移動方向,比如是向正前方移動,還是向左或向右移動等。在這種情況下,只要沒有收到玩家停止移動的消息,其他客戶端上都會以最后一次收到的移動包的狀態(tài)來繼續(xù)模擬移動。

              所以,在網(wǎng)絡(luò)偶爾卡一下的時(shí)候也會出現(xiàn)一些奇怪的現(xiàn)象。比如WOW中,看到隊(duì)友直沖沖地走下了懸崖,你剛喊了句“怎么掉下去了?”只見隊(duì)友又從身后走出來,還冒出一句:“沒啊,我就在你旁邊!”

              關(guān)于數(shù)據(jù)要向哪些人廣播的問題,其實(shí)很簡單,哪些人會看到這個(gè)玩家就需要向哪些人廣播。不管是直接在主屏幕上看到還是在大地圖上看到的代表其位置的一個(gè)點(diǎn)。但是,針對不同的人使用的廣播策略還是存在差異。

              在《帶寬限制下的視覺實(shí)體屬性傳播》一文中提出了一個(gè)方案很值得參考。該方案提出的基礎(chǔ)是因?yàn)?D空間透視的原因,離你很遠(yuǎn)的一個(gè)玩家移動了10米,最終在你的顯示器上看到的位移可能只有一個(gè)象素;而離你不到一米的一個(gè)玩家雖然只移動了一米,但最終顯示出來的位移可能會有幾十個(gè)象素。所以,遠(yuǎn)處玩家的移動并不需要非常嚴(yán)格的關(guān)注,但近處玩家的移動同步需要非常高的優(yōu)先級。

              這個(gè)方案的實(shí)現(xiàn)還依賴于另一項(xiàng)技術(shù)要求,玩家的屬性更新以一定的頻率來進(jìn)行,更新時(shí)比較一下當(dāng)前屬性值與上次更新時(shí)的屬性值,如果存在差異則通知客戶端更新,另外如果中間跳過了某次更新也不會對客戶端表現(xiàn)及游戲公平性造成什么影響。比如這里要處理的玩家坐標(biāo),第一次移動到A點(diǎn),第二次從A點(diǎn)又移動到B點(diǎn),如果移動到A點(diǎn)的更新包沒有發(fā)送,直接發(fā)送了移動到B點(diǎn)的更新包,這將不會對游戲邏輯產(chǎn)生大的影響。

              這套方案基本上是為3D游戲的實(shí)體屬性廣播優(yōu)化而設(shè)計(jì)的,在2D游戲中很難使用。一是斜45度視角的2D游戲中屏幕頂端、中間和底部任何一個(gè)位置上的玩家移動,其距離和象素比是完全相同的,因?yàn)楫嬅娌淮嬖谕敢暎砸簿蜎]有遠(yuǎn)處對象更新頻率低這一可能。另外2D游戲中的移動與3D游戲也存在差異,具體情況前面有詳細(xì)描述,2D游戲中基本上每一次移動都需要廣播,不能跳過哪一個(gè),否則玩家看到的現(xiàn)象就是在亂跑,這也必將影響到技能的使用等游戲邏輯。

              有關(guān)位置同步所涉及到的一些技術(shù)細(xì)節(jié)及優(yōu)化方案上面描述了一部分,但是在實(shí)際的應(yīng)用中是否會使用還是要看具體游戲的需求。比如大話類型的游戲,其本身對位置的精確同步就沒有要求,兩個(gè)客戶端上出現(xiàn)一前一后的移動也不會影響任何的游戲邏輯,所以前面提到的同步方案可能都用不上。

              而對于一些同步要求很高的游戲,如WOW中盜賊這類職業(yè)的需求,上面的方案可能還不夠細(xì)致,還需要設(shè)計(jì)更加有效的同步方案。

              另外,在位置同步過程中還有一個(gè)不容忽視的問題是外掛。我們不能像WOW那樣完全依賴客戶端,如果沒有暴雪那樣強(qiáng)硬的封號措施,游戲也就成為了外掛們的溫床。所以,如何在服務(wù)器端模擬每個(gè)客戶端的移動,如何檢測出客戶端是否存在作弊行為,也是需要重點(diǎn)關(guān)注的一個(gè)問題。

            posted on 2008-05-05 11:15 狂爛球 閱讀(203) 評論(0)  編輯 收藏 引用


            只有注冊用戶登錄后才能發(fā)表評論。
            網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


            欧美精品国产综合久久| 99久久精品无码一区二区毛片| 97精品伊人久久久大香线蕉| 国产精品九九久久精品女同亚洲欧美日韩综合区| 久久噜噜电影你懂的| 久久精品国产精品国产精品污| …久久精品99久久香蕉国产| 久久99国产精品一区二区| 国产无套内射久久久国产| 精品国产乱码久久久久久人妻| 久久精品一区二区三区AV| 精品久久久久久久久午夜福利| 久久人人爽人人爽人人AV| 久久久噜噜噜久久| 久久综合狠狠综合久久综合88| 99久久精品国产免看国产一区| 精品国产青草久久久久福利| 久久综合综合久久综合| 91久久精品国产91性色也| 久久久久久午夜成人影院| 久久亚洲国产成人精品无码区| 久久国产欧美日韩精品| 伊人久久精品无码二区麻豆| 久久亚洲av无码精品浪潮| 国产精品久久免费| av无码久久久久久不卡网站| 久久婷婷五月综合成人D啪| 久久国产视频99电影| 久久九九久精品国产免费直播| 色偷偷88888欧美精品久久久| 久久精品国产一区二区三区| 久久男人中文字幕资源站| 色播久久人人爽人人爽人人片aV| 国产成人无码精品久久久免费 | 亚洲综合伊人久久综合| 亚洲日本va中文字幕久久| 国产精品久久久久久久人人看| 一本久久综合亚洲鲁鲁五月天| 2021国产精品久久精品| 俺来也俺去啦久久综合网| 亚洲国产二区三区久久|