網路遊戲同步問題綜述

標籤：blog   http   使用   ar   資料   sp   art   問題   log   

http://blog.csdn.net/yxriyin/article/details/23377271

最近看了比較多的網路同步問題因為我只做過回合制，沒做過arpg，所以稍微去看看大致是怎麼實現的。基本上可以歸為兩個問題：玩家位置同步和戰鬥指令同步。玩家位置同步的情況要比戰鬥指令同步的情況簡單，不過正因為如此，你為了更好的同步，就會採取複雜的同步策略。另外，這兩種同步其實是息息相關的，戰鬥肯定會涉及到位置判斷。所以我打算一起思考這兩個問題。

     首先我們要知道在arpg遊戲中，是需要對時協議的，就是說用戶端和服務端的時間戳記要基本保持一致。至於這個對時的頻率和策略，可以有各種最佳化的版本，我們只考慮最簡單的情況，就是每隔一段時間同步時間戳記。一般可能是5HZ或者10HZ，當然戰鬥時候肯定會高些，平時可以降低些。

     為啥需要一個時間戳記呢？因為不論是位置同步，還是防止玩家使用加速器，包括用戶端作弊等，在有時間戳記的情況下會簡化很多。

      首先利用對時協議可以讓用戶端和服務端得知網路延遲的大概時間。雖然是大概，但也是比較準確的。

     為了更好的闡述問題，我們假定玩家A,網路延遲為1s，玩家B，網路延遲為2s。這是非常大的延遲，因為如果是100ms左右的延遲，其實不用採取任何技術你都能跑得比較爽。

     玩家A本來位於座標5，下達了向座標10移動的指令，玩家速度為1，服務端接收到指令的時候，玩家理論上其實已經到座標6了，這裡我們是無法讓玩家A等待伺服器響應再移動的，因為沒人受得了我移動一下都要卡1s。服務端知道網路延遲為1s，所以可以輕易估算出位置為6，同時向B通知A的位置, B獲得了A的座標，其實A應該已經到8了，當然B也知道網路延遲，所以也能估算出A的位置應該是8。一切看上去都似乎還可以，但不難發現一些問題。首先，網路延遲是不穩定的，忽高忽低，根據時間戳記去計算，是需要檢測其合法性。比如延遲高達10s，你估算的結果都快讓玩家瞬移了，我們可以判定10s的延遲肯定是不合理，甚至可以丟棄這個包。假定2s一下的延遲才會進入估算，而2s以上的，恐怕還是當做2s來處理。那玩家如果作弊呢?發各種各樣奇怪的位置過來，這也是需要檢測的，服務端肯定有玩家原來的位置，通過與玩家新位置的比較，看看兩者的時間差有沒有可能做這樣的移動，如果沒可能，說明有作弊嫌疑，多次發現，就直接踢下線處理。這樣似乎解決了這個問題。但再思考，玩家A下達這個指令後，B將A同步到8，突然A的第二條指令來了，A跑到5.5之後，其實往回跑了，同理，服務端接收到資訊，發現A的位置是5.5,這和本來預測的位置6相差0.5,說明自己的預測產生了誤差，我們依然採取相信用戶端的做法，因為假如你強行同步A位置為6，那麼玩家A會產生往回跑的奇怪體驗。這時服務端通過估算A在4.5,當然A可能突然停下來，這個問題我們不考慮，因為只需要增加一個停下來的指令或者判斷目標位置就可以解決。服務端這時候通知B，A到4.5了，B收到資訊，估算出A應該在2.5，發現問題所在了吧，A本來應該在8的怎麼突然跑到2.5了？當然由於中間只經過了0.5秒，所以A在B看來還沒到8，只是在向8跑的路上，大概是7。如果我們沒有任何估算，那麼情況會變成A在6，服務端認為是5,同時告訴B A在5，延遲了1， 如果A跑到5.5回頭，那麼A其實在4.5,服務端認為是5，B收到也是5，這樣看起來似乎也沒那麼糟糕。那麼問題的癥結來了，如果不估算，那麼毫無疑問，服務端獲得的位置是用戶端延遲前的資料，用戶端得知其他玩家的位置則是兩邊延遲的疊加。這絕不是一個好的策略。那麼估算的風險我們也看到了，可能會誤打誤撞反而是誤差變大。我們發現誤差變大的原因是玩家突然變嚮往回跑，導致經過一堆延遲後的速度相反，反而是誤差增大。但也許這些都不是問題，這裡我拷貝雲風大大的一段話：

 

一種，收到的資訊是屬於其它玩家的。我們從最新得到的狀態資訊，預測一段時間之後（比如一秒後的狀態），用一條直線運動去修正。即，設想一秒後這個玩家在哪裡，然後反推回現在應該用什麼速度運動可以在一秒後到達那個地方。

另一種，收到的資訊是屬於自己的，即伺服器認可的自己的狀態（並廣播給別人了）。這個偏差是由於伺服器的預測補償造成的。為了保持使用者的操作手感，對於不太極端的偏差，我們全部不修正，而是依然發送用戶端自己操作的位置狀態給伺服器。伺服器那邊玩家是處於一種離散的運動狀態的。而其他人見到你會再做預測補償；如果和伺服器相差過於劇烈，則直接跳轉到伺服器認可的新位置。

這裡幾乎全部相信用戶端的行為，以擷取最好的操作手感。防止用戶端作弊是另外一個話題，也不是不能解決的，但目前不要碰了。

用戶端到底以怎樣的頻率發送那些位置資訊給伺服器呢？

策略應該是這樣的：

每次發送完一個完整的位置資訊後，預測伺服器看待這個位置資訊包一秒後的位置大約在哪裡。每次變化做一個累積，一秒內都但不用立刻發送。但每次小的狀態改變都和假設的預測位置做一些比較，如果位置偏差比較大，就可以提前發送。否則一直累計到一秒再發送。

這個一秒的周期可以根據實際測試情況來調整。可能一秒太短，也可能過長了。

每次收到伺服器發送過來的新的玩家位置資訊時，都在裡面會找到一個時間戳記，表識的包發出的伺服器時間。用戶端可以驗算之前的網路延遲是否正確。如果網路延遲穩定在一個固定值，說明沒有問題。但如果延遲值為負數，則說明之前的對時流程中網路不穩定（可能是因為上下行時間偏差比較大造成的，也可能是當時伺服器負載很大，造成了較大的內部延遲），造成本地時間和伺服器時間的時差計算錯誤。這個時候重新發起對時流程就好了。

以上就是雲風部落格中內容，我們可以看到對於B玩家而言，A玩家其實已經不再誤差範圍內，應該直接將它變成2.5或者4.5,這麼來看由於剛才我們分析B大概在7左右，如果從7變成4.5似乎還是可以接受的。畢竟本來我們就是從5變成了8.一切也沒那麼糟，當然如果你要把它變成2.5，那麼只能使用瞬移了，不然玩家總是以一種比常人快的速度運動了。所以，我個人更喜歡保守估計，不要說太滿，寧願延遲一些位置，也不要過頭了。

 

基於上述的結論，我們來看看玩家只是跑動的話毫無疑問是感覺到流暢的，因為所有人都沒有等待就看到自己開始移動了，一切似乎都很完美。但是，如果是戰鬥呢，先不說pvp，我們就將pve好了，玩家對怪物進行攻擊，如果有網路延遲，我們不得不等待，因為這個是不能放在用戶端計算的（當然確實有遊戲這麼做，這個我會再寫一篇部落格探討）。我們不能信任用戶端，所以玩家延遲1s在攻擊出手，這似乎非常蛋疼。然後看怪物，怪物攻擊玩家是用戶端發起呢還是服務端處理呢?首先我們對怪物也是要做位置同步的，因為怪物的AI肯定是用戶端直接處理。假設是用戶端發起，它同樣也有延遲的問題，不過由於是怪物，也就無所謂了。但是我們說了移動是瞬間的，那麼玩家攻擊了，然後直接跑走，卻發現攻擊要在1s後才響應，自己明明要跑走，卻突然去攻擊了對方一下。這裡有一個技術叫做用戶端預測。當你攻擊怪物的時候，用戶端按照服務端的代碼去執行，所以你確實看到自己毫無延遲的砍了下去，當然服務端那邊也會計算，不過是1s之後的了，這時候你收到了服務端計算的結果，如果結果和用戶端計算的是一樣的，那麼恭喜，你啥都不幹就行了，玩家非常流暢的結束了戰鬥。但如果服務端計算和用戶端不一致呢？沒錯，由於暴擊機率，閃避機率等等的存在，很可能你用戶端打中了服務端卻沒有打中，當你發現狀態不一致，你就直接同步處理狀態。那麼問題來了，我用戶端預測的意義在哪?只是為了播放那幾下攻擊，然後發現怪物慢慢的在1s後作出響應，而我還是默默的攻擊著。虛幻引擎作者說：用緩衝技術，用戶端儲存狀態和指令，當服務端狀態發送過來時不是單純的同步，而是將緩衝中無效的指令先去掉，比如已經過時的指令。然後再把服務端發過來的狀態插入第一個，用操作緩衝中的指令繼續預測，獲得到最新的狀態進行同步。但你馬上就意識到了，那豈不是不停的重複指令了？沒錯，你會發現你殺死了一個怪，突然這個怪又活了，又被你殺死了。為了避免這個問題，我們要確保每個指令其實只是被執行一次，也就是說你每次預測同步都只是執行一次的動作後更新結果，如果這些指令執行過了，那麼你不用執行了，單純的去同步結果就好了。當然還是會有怪物突然加血減血的問題。而且這個技術的最大問題在於你的用戶端也要有服務端的對應的邏輯代碼。對於真大作才能如此霸氣。所以不打算採用這種技術。

 

那麼我們只能老實接受這個延遲帶來的坑爹現象了嘛？還是有些小技巧的。比如攻擊前搖，你攻擊的時候，先要抖一下，這個抖可能沒有實際作用，但確實的提供了短暫的時間等待服務端返回結果。這當然不算啥技術，但是我們不得不正視一個事實，網路不好肯定體驗就會變差，而且打不過網路好的玩家。比如pvp，無延時的玩家，幾乎是發出一個指令就打到你了，你一點辦法都沒有。老實的等待被打吧。當你攻擊別人時，你覺得打中了，但到了伺服器那邊發現人家老早走遠了。所以如果是pve，還是能對網路不好的玩家做些補償，畢竟能打中就當做打中好了。

 

基本就這些了，講的可能比較亂。想看其他資料的參考我轉載的一篇部落格，網路同步啥啥的，有幾篇英文寫的特別好。

網路遊戲同步問題綜述