[轉載]網路遊戲的同步

標籤：blog   http   io   ar   os   使用   sp   strong   資料   

     [轉自margincc的cnblogs 2010-12-18 13:13 ,如果涉及到侵權請及時聯絡我們，一經確認會在第一時間刪除~不過我們是出於學習的目的，小組裡面6個人只有我一個打醬油的懇請各位大大高抬貴手！]

　　近期完成一個稍稍涉及網路同步的遊戲，結合網路上查到的一點資料和自己的心得做個小結。

      遊戲描述：略形象的歸納為地圖中5個玩家在5個不同位置訊息，地圖中有20個道具，玩家選擇出發時間，出發角度和出發速度去奔向某道具。現在玩家1向server發訊息，準備從當前currposition出發，對應的currtime，currangle，currspeed都確定，假定前方有prop1，現在伺服器收到訊息currservertime，然後廣播玩家1的出發，那麼玩家2，玩家3，玩家4，玩家5可能又由於網路原因接收到訊息的時間是time2，time3，time4，time5。如果玩家1發出訊息時開始繪圖，玩家2，3，4，5接收到訊息時繪圖，這裡就會產生一個不同步問題，玩家1和玩家2，3，4，5對應有一個time2，3，4，5-currtime的時間誤差。而且中間還可能有5個玩家的本地時間並不相同的情況。

      首先可以通過伺服器驗證群發方式解決：玩家1發出訊息的時候並不進行繪圖，而是掛起等待伺服器接收玩家1訊息，廣播給5位玩家之後大家一起繪圖。考慮5個玩家本地時間不同的情況和網路延時時間，我們可以在玩家開始遊戲的前進行一個玩家本地時間和伺服器時間的誤差比較，在伺服器和5個用戶端記錄每個玩家和伺服器的時間誤差motifytime1，2，3，4，5。在伺服器收到出發訊息時，根據motifytime1，2，3，4，5確定玩家1，2，3，4，5每個人收到玩家1出發訊息的繪圖時間。這個方案在網路延遲很大發出訊息的玩家會感覺極其不順。很多並不是很需要及時通訊的遊戲會採用這種方式。

      如果玩家1在發出訊息時就繪圖，也可以通過motifytime方式進行同步，在伺服器收到玩家1訊息時，通過motifytime1計算出伺服器中的玩家1出發時間，進行廣播後玩家2，3，4，5根據自己的motifytime2，3，4，5判斷接收到訊息的時間和伺服器發來的時間是否滿足motifytime2，3，4，5範圍，超出範圍則計算出超出的時間，*speed後可以得到實際玩家1已經走到的位置positon1，當然我們可以用一個稍微快一點的speed到達position1後面的一點位置。

      還有一種好像是目前主流的解決方案，筆者沒有實踐拷貝網路資料：

      首先用戶端需要在登陸世界的時候建立很多張廣播列表，這些列表在用戶端後台和伺服器要進行不及時同步，之所以要建立多張列表，是因為要廣播的類型是不止一種的，比如說有local message,有remote message,還有global message 等等，這些列表都需要在用戶端登陸的時候根據伺服器發過來的訊息建立好。在建立列表的同時，還需要獲得每個列表中廣播對象的TimeModified，並且要維護一張完整的使用者狀態列表在後台，也是不及時的和伺服器進行同步，根據本地的使用者狀態表，可以做到一部分決策由用戶端自己來決定，當用戶端發送這部分決策的時候，則直接將最終決策發送到各個廣播列表裡面的用戶端，並對其時間進行校對，保證每個用戶端在收到的訊息的時間是和根據本地時間進行校對過的。那麼再採用預測拉扯中提到過的計算提前量，提高速度行走過去的方法，將會使同步變得非常的smooth。該方案的優點是不通過伺服器，用戶端自己之間進行同步，大大的降低了由於網路延遲而帶來的誤差，並且由於大部分決策都可以由用戶端來做，也大大的降低了伺服器的資源。由此帶來的弊端就是由於訊息和決策權都放在用戶端本地，所以給外掛提供了很大的可乘之機。
      基於這種方案的導航Dead Reckoning演算法:

      大家都知道，在網路傳輸的時候，延遲現象是很普遍的，而在基於Server/Client結構下的網路遊戲的同步也就成了很頭疼的問題，在保證用戶端響應使用者本地指令流暢的情況下，沒法有效保證的同步的及時性。首先，這套同步方案是基於用戶端之間的同步的。下面我們先來說一些本文中將用到的名詞概念：
　　網狀網路：用戶端之間構成的網路
　　節點：網狀網路中的每個用戶端
　　極限誤差：進行同步的時候可能產生的誤差的極值
　　恩，在探討其原理的之前，我們先來看看我們需要一個什麼樣的環境。首先，需要一個網狀網路，網狀網路如何構成呢？當有新節點進入的時候，通知該網路裡面的所有節點，各節點為該用戶端在本地建立一個副本，登出的時候，則通知所有節點銷毀本地關於該節點的副本。然後每個節點該儲存一些什麼資料呢？首先有一個很重要的包需要儲存，叫做協議資料包（PDU Protocol Data Unit），PDU包含節點的一些相關的運動資訊，比如當前位置，速度，運動方向，或者還有加速度等一些資訊。除PDU之外，還有其他資訊需要儲存，比如說節點用戶端人物的HP，MP之類的。然後，保證每個節點在最少8秒之內要向其它節點廣播一次PDU資訊。最後，設定一個極限誤差值。到此，其環境就算搭建完成了。下面，我們就來看看相關的具體演算法：
　　假設在節點A有一個小人（路人甲），開始跑路了，這個時候，就像所有的節點廣播一次他的PDU資訊，包括：速度（S），方向（O），加速度（A）。那麼所有的節點就開始類比路人甲的運動軌跡和路線，包括節點A本身（這點很重要），同時，路人甲在某某玩家的控制下，會不時的改變一下方向，讓其跑路的路線變得不是那麼正規。在跑路的過程中，節點A有一個值在不停的記錄著其真實座標和在後台類比運動的座標的差值，當差值大於極限誤差的時候，則計算出當前的速度S，方向O和速度A（演算法將在後面介紹），並廣播給網路中其他所有節點。其他節點在收到這條訊息之後呢，就可以用一些很平滑的移動把路人甲拉扯過去，然後重新調整類比跑路的資料，讓其繼續在後台類比跑路。
　　很顯然，如果極限誤差定義得大了，其他節點看到的偏差就會過大，如果極限偏差定義得小了，網路頻寬就會增大。如果定義這個極限誤差，就該根據各種資料的重要性來設計了。如果是回合制的網路遊戲，那麼在走路上把極限誤差定義得大些無所謂，可以減少頻寬。但是如果是及時打鬥的網路遊戲，那麼就得把極限誤差定義得小一些，否則會出現某人看到某人老遠把自己給砍死的情況。

 

      同步是網路遊戲很重要的問題，如何同步也牽扯到各個方面的問題，比如說遊戲的規模，遊戲的類型以及各種各樣的方面，對於規模比較大的遊戲，在同步方面可以下很多的工夫，把訊息分得十分的細膩，對於不同的訊息採用不同的同步機制，而對於規模比較小的遊戲，則可以採用大體上一樣的同步機制，究竟怎麼樣同步，沒有個定式，是需要根據自己的不同情況來做出不同的同步決策的。

      筆者完成的是一個休閒遊戲，採用了第二種方式做預測拉扯方式完成，對玩家操作採用先繪圖，其他玩家接收訊息後預測拉扯。同時伺服器端也建立一幅地圖資源和玩家操作環境，類似伺服器和用戶端都是一幅地圖下同樣的位置更新，由伺服器做定期更細玩家座標，並在關鍵的獲得道具等訊息處理有伺服器決定。

 

     最後摘抄以為網路大蝦的的一點總結：

 

      以下六點，將助你分清楚哪些我們可以努力，哪些我們不值得努力，弄明白即時遊戲中同步問題關鍵之所在，巧妙的化解與規避遊戲，最終在適合普遍使用者網路環境中(200ms)，實現即時快速互動遊戲：

1. 基本情況：
   (A) 網路效能指標一：頻寬，限制了即時遊戲的人數容量
   (B) 網路效能指標二：延時，決定了即時遊戲的最低反應時間

2. 兩個基本原則：
   (A) 讓所有的使用者螢幕上面表現出完全不同的表象是完全沒有問題的。
   (B) 把這些完全不同表象完全柔和在一個統一的邏輯中也是完全沒有問題的。

3. 同步的十二條基本對應策略：
   (A) 最大可能減少遊戲中的資料轉送
   (B) 將阻塞通訊放到線程池中實現
   (C) 永遠不要為了等待某個資料而不讓遊戲進行下去
   (D) 利用預測和插值改進遊戲的效果
   (E) 當使用預測插值的時候傳送的資料不僅包括座標，還需要速度和加速度
   (F) 將輸入資料枷鎖或者隊列化(例如鍵盤訊息佇列)，直到下次發送資料的時刻，傳統的方法是在固定的時間(發送資料前)檢測鍵盤，在遊戲的原理上隱藏延時
   (G) 使用事件調度表，將需要在所有使用者用戶端同時發生的事件，提前廣播到所有使用者
   (H) 使用多次攻擊來殺死一個精靈，盡量減少一次性的、確定性、延時敏感的事件
   (I) 延長子彈或者火箭在空中飛行的時間(在其飛行的同時，在所有用戶端進行預測插值)
   (J) 所有物體從一個地方移動到另外一個地方都需要時間，避免諸如“瞬間移動”的設計
   (K) 盡量使遊戲中所有精靈，飛船或者其他物體，都按照可預測的軌跡運行，比如在移動中增加慣性
   (L) 充分發揮創造力，盡最大可能的合并遊戲中前後相關的事件，合并遊戲中存在的延時此問題，需要在技術上改進的同時也需要策劃有所重視，規避一些影響較大的設計，巧妙的隱藏"延時"

4. 同步問題現狀：
   (A) 重視程度不夠：很多人尚未意識到此問題的存在，曾有公司花半年時間打算做一款“松鼠大戰”的網路版。
   (B) 技術上無徹底解決方案：對於多數程式員，單機遊戲技術善未成熟就匆匆步入網路時代。
   (C) 研究這個技術需要條件：需要有實力的公司才能提供，無此條件，即便有能力的程式員也無法成功。

5. 目前網遊的三大技術難題：
   (A) 伺服器的響應問題：如何使伺服器在支援越來越多的人數的情況下提供最高的響應
   (B) 同步問題：如上在有限的網路響應情況下，實現快速即時類遊戲，提供最完美的互動
   (C) 伺服器分布式問題：如何在統一使用者資料的情況下，利用分部式將各個分散的“世界”統一到一個“世界”中。
   誰能真正解決好以上三個問題，配合策劃在設計上的突破，將使其他人在至少兩年內無法超越。
   
6. 相關補充：
   (A) 網格技術現在還是抄作，真正用到遊戲中，還有很多技術痛點需要突破(比如：目前網格的單位計算時間是以秒計算).
   (B) 其實與很多人想法相反的是現在3D技術早已不是主要的矛盾。而現在國內外對於以上三個問題可以說處於同一個起跑線上，完全有機會取得先機。
   (C) 現在解決同步問題已經很緊迫，而同時所需要的環境也已經成熟，只要有所關注，半年之內可以得出較成熟的結論

 

 

    下半部分文字作者blog  http://blog.csdn.net/skywind/

[轉載]網路遊戲的同步