FPS遊戲中，在玩家的延時都不一樣的情況下是如何做到遊戲的同步性的？

12-14

如果不是同步的話，遊戲的公平性怎麼保證呢？那些cf,cs的比賽是如何解決這個問題的？

聲明：下面會大量使用CSGO作為例子，這是因為Valve在多人遊戲的網路通信方面做得較好，可以當做一個典型來分析。
========================================================
先講多人競技遊戲中客戶端和伺服器是如何互動的吧

遊戲中所有的邏輯判定都是由伺服器完成的，客戶端只負責發送請求和接收伺服器的反饋，並把反饋具象化。拿CSGO做例子吧，比如你（玩家A）拿著AK瞄準了玩家B的頭開了一槍，那麼你的客戶端會向伺服器發送一個數據包，裡面包含了誰（你）拿著什麼武器（AK）從什麼位置（你在地圖上的坐標）向什麼方向（角度）開了一槍。伺服器收到後進行判定，這一槍的傷害會經過玩家B的頭部模型，判定為爆頭傷害，數值為104（這個值是瞎編的），因此判定玩家B死亡。然後向所有玩家的客戶端通信，更新當前遊戲狀態，其中會包括玩家A用AK爆頭擊殺了玩家B，也會包括其他遊戲信息，比如玩家的位置等等。你（玩家A）收到通信後再你的GUI上顯示你擊殺了玩家B，而玩家B則會收到被你擊殺的信息。

接著講一個概念，叫伺服器的通信頻率（tick rate）。事實上伺服器不是實時地向玩家通信來更新遊戲狀態的，因為這樣需要的計算量很大，同時對網路帶寬的要求也會高的不現實。因此伺服器會以一定的頻率來進行通信。 CSGO在娛樂模式下通常採用60Hz的頻率，也就是說每過1/60秒玩家的客戶端就會收到一次新的信息。如果回到上面那個例子，那麼實際情況應該是：你（玩家A）拿著AK瞄準了玩家B的頭開了一槍，你的客戶端會向伺服器發送一個數據包，伺服器接收後進行判定。判定完成後等待至下一次通信，再向所有玩家更新遊戲狀態。也就是說遊戲過程其實是一個離散的過程而非連續過程。

=====================================================================

上面的例子都假設客戶端和伺服器之間的延遲無窮小。那麼當玩家Ping很大的時候會發生什麼的呢？假設你（玩家A）與伺服器之間存在100ms的延遲（單向，往返則是200ms），其他玩家的延遲忽略不計，伺服器的通信頻率足夠大（頻率不夠大還會造成其他很嚴重的問題，這個放在後面講）。你在某一刻向伺服器發送了一個請求（比如向前走），那麼這個請求會在100ms之後到達伺服器。伺服器判定後返回結果，再經過100ms你的客戶端會收到確認，伺服器已經把你的位置向前移動了若干距離。假設客戶端在沒有收到任何伺服器的更新前畫面都不會變化，那麼著200ms內你就會覺得遊戲「卡頓」。

實際上在很多遊戲里（比如CSGO）在這200ms里你看到你自己是在向前走，實際上那只是客戶端「擅自」在繪製你前進的樣子。這是一種延遲補償策略，稱為「客戶端預測法」。也就是說客戶端能夠大致預測遊戲未來的走向，因此在接收到伺服器更新前會把預測到的畫面先繪製出來（比如移動，武器的開火效果，彈藥計數的變化等等）。收到伺服器通信後如果有出入則立刻糾正為伺服器提供的數據。這也是很多時候如果延遲很大玩家會體驗到「明明往前走了過了一會又瞬移回到之前的位置」的原因。類似的體驗還有「明明開了好幾槍而且也都顯示了過了一會彈藥計數只減少了一點點」。

既然扯到這裡了那就認真的講下延遲補償策略（lag compensation）。一般補償策略分伺服器端和客戶端兩類。前面的預測法屬於客戶端一側的。其他的客戶端一側的策略還有插幀法。所謂插幀法就是客戶端會記錄之前一次從伺服器收到的信息，然後在接受到下一次通信的時候不立刻更新遊戲畫面，而是逐漸的更新畫面（比如兩次通信間玩家B移動了10單位距離，客戶端會繪製玩家B以一定的速度移動了這10單位距離，而非立刻繪製玩家B瞬間移動了10單位距離）。插幀法的問題在於如果玩家並未沿直線運動且其直線路徑中有本應不能通過的物體在（比如繞過一堵牆），客戶端會繪製出該玩家穿牆而非繞過去的動作。

---------------------------------------------------------------------------------------------------------------------------
在伺服器端常用的策略有：
1.「眼不見為凈」法。很多時候伺服器不去補償玩家的延遲是一個合理的做法，特別是如果遊戲內進行的事件非常多（想想行星邊際2裡面千人同圖混戰的情形）。浪費寶貴的伺服器資源去補償個別玩家的延遲是不明智的。這個策略的缺點很明顯，就是玩家有可能會對遊戲體驗不滿意。

2.「倒帶」法。採用倒帶法的伺服器會記錄剛剛過去一段時間內（比如0.5秒）遊戲內的所有信息。當一個有延遲的玩家（比如200ms）向伺服器發送一個請求，那麼伺服器在處理這個請求的時候會調取0.2秒前遊戲的狀態然後進行判定，在把判定結果對所有客戶端進行同步。如此一來該玩家的操作雖然有延遲但也能與他/她所看見的畫面一致。該策略的最大問題在於它讓不同延遲之間的玩家被迫體驗較大的延遲。舉個例子，假設遊戲里擊殺時間（TTK）足夠小，玩家A（10ms延遲）和玩家B（延遲200ms）對射，兩人都是空血（一次攻擊即死），A比B先開火（時間差很小，比如50ms）。玩家A的次攻擊很快（10ms後）就得到了處理並記錄在伺服器中，玩家B被判死亡。然而在200ms後玩家B的請求到達，伺服器倒帶0.2秒，此時玩家AB都未死亡，因此玩家B的攻擊有效，玩家A也被判定為死亡。如果沒有延遲，那麼伺服器應該會判定玩家B死亡，因此玩家B將無法攻擊，玩家A應該存活。換句話說採用倒帶法的伺服器里如果有一個延遲很大的玩家將會拖累其他低延遲玩家的遊戲體驗。

----------------------------------------------------------------------------------------------------------------------------
Bonus：
前面的例子都是以伺服器的通信頻率足夠高為前提的，下面簡要描述一下低通信頻率帶來的問題。這裡我要舉的例子是大名鼎鼎的《戰（和諧）地4》（下稱BF4）。

BF4在剛剛發布的時候可謂是Bug滿天飛整一個就是半成品，其中非常嚴重的就是網路通信問題（netcode issue）。根據製作組DICE提供的信息，BF4的通信頻率是10Hz。這是一個相當低的設定了，大多數FPS的通信頻率在30Hz左右，而CSGO為60Hz，電子競技比賽時一般伺服器的通信頻率還會提高到120Hz（因為比賽時大家都是在一個區域網里所以延遲很小高頻通信能夠更加精確反映遊戲內狀態）。由此帶來什麼糟糕的後果呢？

1.遊戲體驗的不連貫。BF4的客戶端，和其它很多遊戲一樣有應用客戶端預測法來補償延遲。但是因為伺服器更新的頻率是在太慢了（0.1秒才更新一次，人類的反應時間差不多略小於0.1秒，即玩家已經可以感覺到其中的不連貫）。拿移動來舉例吧，玩家正常的前進，突然玩家的延遲很短暫的增加了一下然後又回到正常（也就是spike），那麼其中某一次移動的請求就會花更多的時間到達伺服器。客戶端這邊因為沒有收到伺服器的通信而繪製了玩家前進的樣子，0.1秒後伺服器告知客戶端實際的位移小於繪製的距離，客戶端進行糾正（瞬間向後退）而0.1秒可以前進很大一段距離了（至少肉眼可以感覺出來有變化了），如此瞬移回退讓玩家感覺非常不舒服，即使延遲很小隻要有變化就有可能發生這種情況。同樣的情況適用於玩家看到的其他玩家所在的位置。在伺服器中敵人的位置往往比客戶端上顯示的要滯後，因此很多時候明明瞄準了卻打不中。相對的，如果提高通信頻率，客戶端「擅自」繪製的畫面和伺服器數據能夠以更高的頻率進行糾正，其中每次產生的變化都不會讓玩家察覺。

2.「瞬間」擊殺（Instant Kill）。BF4里的自動武器射速絕大多數都超過了600RPM（即每0.1秒一發），高射速武器如AEK971可以達到900RPM甚至更高。而大多數武器在近距離內都是造成25傷害（玩家滿血100）。因此玩家（A）完全可以在0.1秒內發射至少2發子彈，在近距離內擊殺生命值小於等於50的玩家（B）（這個邊界值隨射速提高而提高，如AKE971可以在0.1秒於近距離擊殺生命小於等於75的玩家）。假設玩家A開始射擊的一瞬間伺服器剛好進行了一次對客戶端的通信，玩家A在之後的兩次發送射擊請求都被伺服器接收並判定（玩家B死亡），而一直到玩家A開火後的0.1秒內玩家B都沒有接收到任何被攻擊的信息。0.1秒後玩家B死亡，而玩家B的客戶端只能繪製一次玩家A開火（雖然收到兩次開火的信息），且因為玩家B已經死亡客戶端只顯示kill cam。簡單來說玩家B完全沒有還手或者躲藏的機會，因為玩家B一直都認為自己沒有受到攻擊，只是在一瞬間就被A打死了。對玩家A來說整個過程沒有任何問題，而玩家B則是個冤大頭。此時的BF4已經失去了競技的平衡性。
--------------------------------------------------------------------------------------------------

在BF4發布八個月後（沒錯，八個月，期間發布了數款BF4的DLC），發行商EA（果然不要臉）終於決定要修復這些問題。一開始他們決定吧BF4的伺服器端通信頻率提高到30Hz。然而BF4是一款複雜度遠遠超過其他FPS遊戲的一款作品（64人，海陸空載具，彈道分析【BF里的子彈並非是在發射的瞬間就擊中了敵人而是要經過一定的飛行時間才會擊中，且還會受到重力影響而下墜】），30Hz的通信頻率就已經讓很多玩家的電腦吃不消了。後來採取了一個折中策略，玩家附近的遊戲狀態以30Hz的頻率進行更新，而距離玩家較遠的信息繼續以10Hz的頻率來更新。同時還提供一個選項允許客戶端以更高的頻率向伺服器「索要」數據（當然其中造成的硬體負擔不可小覷）。目前BF4的網路通信已經恢復到「可玩」的狀態。根據某些資深玩家推測，BF4的伺服器無法以超過30Hz的頻率進行通信，主要原因是其引擎寒霜3內核有缺陷。因此BF4不太可能成為一款競技遊戲走向電競舞台。

=======================================================
更新（閑扯淡內容）：
感覺既然扯了BF4的低頻通信那就再在戰地系列裡擴展一下吧。
最早出現低頻（10Hz）通信的戰地系列遊戲是戰地：叛逆連隊2（BF:BC2），然後戰地3（BF3）也沿用了一樣通信頻率。細心的玩家會發現自BFBC2以來所有的戰地系列遊戲使用的都是寒霜（Frostbite）引擎（BFBC2是寒霜，BF3是寒霜2，BF4和戰地：硬仗BFH是寒霜3）。使用低頻和引擎的關係很大（如之前所述）。

我在這裡想講的是同樣是使用低頻通信，同樣存在嚴重的網路通信問題，BFBC2被譽為神作被很多戰地系列的老玩家奉為經典，而BF4被黑的死去活來（youtube上和Reddit論壇上甚至有針對DICE的檄文）的原因。

BFBC2是2009年發布的FPS遊戲，是第一款使用寒霜引擎的多人FPS（當時也是DICE拿來賣引擎的作品，和孤島危機類似）。在發布後立刻好評如潮，時至今日在北美依然有不少伺服器在線供玩家遊戲（包括其DLC越南）。當時很多玩家都沒有注意到低頻通信帶來的問題，即使瞬殺等問題存在。這裡最主要的一個原因在於BFBC2中武器的設定。

BFBC2中所有的武器（除去栓動狙擊步槍和攜帶獨頭彈的泵動式霰彈槍）傷害都比較小，常規的突擊步槍和卡賓槍通常需要5-7發（擊中軀幹）才能擊殺一個滿血的敵人，遠距離需要更多，而輕機槍往往需要7法以上，但遠距離傷害不減少。這主要帶來的一個特徵就是TTK（擊殺時間）相對當時很多主流FPS遊戲都要長（相比使命召喚，CS：S等，網遊不考慮在內）。因此在10Hz的通信環境下，要出現和BF4中類似的瞬殺的情況條件苛刻很多（玩家的生命值必須非常低，而不是50%或者75%以下）。同時BFBC2中的武器射速普遍沒有那麼高（高射速應該是從BF3開始的），因而即使玩家生命值很低需要擊殺的時間也可能會超過0.1秒，那麼玩家就能夠有足夠的反應時間。另外BFBC2最多只允許32人同服遊戲，近距離的接戰沒有那麼混亂，玩家感覺到「莫名其妙就死了」的概率也低很多。

在BFBC2發布後的一段時間開始有玩家注意到了網路通信中的瑕疵，並嘗試在youtube上製作視頻進行說明，但並沒有得到很多響應。說到底當時BFBC2絕對是跨時代的作品，其優秀的遊戲品質和創新的設定讓玩家對網路通信中的瑕疵更加寬容。試想一下，BFBC2是世界上第一款引入全場景可破壞的FPS遊戲，是第一款強調步兵小隊作戰的戰地遊戲，是第一款主推快攻（rush）模式的FPS遊戲（這個模式貌似還是只在戰地系列中有，RO2和Insurgency有類似的模式但不同），玩家自然對其百般推崇。網路通信中的小瑕疵？沒關係，玩的爽就行。

---------------------------------------------------------------------
到了BF4發布的時候，很多玩家怒了。
第一，BF4很大程度上只是BF3換了層皮，而且開發很不完善，bug很多（前面有提到），玩家對DICE極度不滿，自然就有人出來挑刺。
第二，BF4武器射速以及傷害模型的問題，使得網路通信質量問題更加凸顯，youtube上大量的視頻都表明要復原通信問題比BFBC2簡單很多。

說起來EA和DICE也是臉皮很厚的，發布後八個月（之前提到過）才開始嘗試修復。他們的理由是：「開發人員去度假了」。

網遊技術發展真夠慢的，怎麼大家十年前在討論同步問題，十年後還有人在討論這個問題呢？何為延遲補償？如何進行坐標差值？B客戶端屏幕上A已經跑到東邊了，但是收到伺服器說「A正在西邊往北跑」，B到底該何去何從？

各位說了那麼多DR，TimeWrap，LockStep，自己實現過沒有？有產品上線沒有？這些問題明明很簡單，卻總被形容得雲山霧罩的，離落地編碼還是那麼的遙遠。我若干年前的一個實現版本，將簡明扼要的解決這個問題：
--------------------------------------------------------------------------------------------------------------

影子跟隨演算法由普通DR（dead reckoning）演算法發展而來，我將其稱為「影子跟隨」意再表示演算法同步策略的主要思想：

屏幕上現實的實體（entity）只是不停的追逐它的「影子」（shadow）。
伺服器向各客戶端發送各個影子的狀態改變（坐標，方向，速度，時間）。
各個客戶端收到以後按照當前重新插值修正影子狀態。
影子狀態是跳變的，但實體追趕影子是連續的，故整個過程是平滑的。

前面的1號終端控制紅色飛船P1向左飛，並把自己的狀態時時告訴伺服器

後面的2號終端上接收到飛船P1的影子S1的狀態（向左移動），並讓P1的實體追趕S1

網路性能指標一：帶寬，限制了實時遊戲的人數容量
網路性能指標二：延時，決定了實時遊戲的最低反應時間

使用該演算法可以容易的開發出一款馬里奧賽車，或者Counter Strike，詳細說明見後：

演算法比較：

幀間同步：不同客戶端每幀顯示相同的內容，鍵盤/時鐘數據傳到伺服器，伺服器確認後所有終端做出響應，多用於區域網遊戲，比如紅警（需要等待客戶端），街霸II的網路版（360），可參考 LockStep，TimeWrap演算法，網速要求高，複雜度低，見我的舊文幀鎖定演算法。
插值同步：不同客戶端顯示不同步，但是狀態同步，常見的Dead Reckoning（或叫導航插值），效果好，但複雜度高。常見於競速類遊戲和 FPS遊戲。

演算法定義：

時間：單位為幀（FPS=10），開始由伺服器告訴向所有客戶端，每5分鐘同步。
玩家：每個玩家控制自己的實體，並在每貞將狀態改變告知伺服器。
狀態：狀態數據 = 實體ID + 坐標 + 方向 + 速度 + 時間（貞）。
插值：收到新狀態包後將根據其運動方向與時間，根據現有時間計算新狀態。
跟隨：實體不停的追蹤自己的影子，追上後與影子保持狀態同步。

相位滯後：可選參數，實體與影子保持一定距離同步，相當於保持一定車距，這樣在控制者突然停止的時候，不容易因為網路延遲跑過了又被拉回來。

慣性移動：可選參數，開始移動或者停止或者改變方向都有加速度，這樣就不需相位滯後了。

每次伺服器向各個客戶端同步時間的時候，由於延遲，所有客戶端的時間都是慢於伺服器的，這沒有關係，只要大家在一定誤差範圍內以相同的速度增加，就完全沒有問題。

圖2 IDC網路響應

在公網平均130ms的Latency下，是不存在「完全的」的同步情況。如何通過消除/隱藏延時，將用戶帶入快速的互動式實時遊戲中，體驗完美的互動娛樂呢？

讓所有的用戶屏幕上面表現出完全不同的表象是完全沒有問題的；

把這些完全不同表象完全柔和在一個統一的邏輯中也是完全沒有問題的。

需要根據具體情況，分清楚哪些我們可以努力，哪些我們不值得努力，弄明白實時遊戲中同步問題關鍵之所在，巧妙的化解與規避遊戲，最終在適合普遍用戶網路環境中(200ms)，實現實時快速互動遊戲。

案例解析：Counter Strike

實現CS的話，首先我們需要給人物移動加上慣性，比如靜止狀態突然開始移動，那麼需要0.5-1秒的加速過程，而移動中突然停止也需要0.5-1秒的減速過程，這樣就實現了無差別同步，不需要相位滯後來避免拉扯影響用戶感。

同時開槍射擊採用客戶端判斷，也就是說如果我看見你在牆前面，開槍射中，那麼我向伺服器發送「我擊中你了」，這時有可能真實的你在牆後，那麼表現出來的就是我看見我打中你了（減不減血由服務段判斷），而你沒有看見我，覺得我穿牆打中你了。

圖3 CS的同步邏輯

關鍵狀態進行緩存，不然如果別人向前連續跳五次，每次取得狀態都取到最高點的話，別人客戶端上的影子和跟隨的實體會奇怪的持續的飛在天上，所以需要將起跳和落地這兩個關鍵狀態緩存，實體追趕時只有追上的第一個狀態（一號影子）才能追逐第二個狀態（二號影子）。

由此可以在完全時間同步的情況下平滑的跑動、跳躍，開槍射擊採用客戶端判斷後手感得到提高，唯一需要擔心的就是外掛，外掛多是實時遊戲的代價，只能通過Cheating
Death等工具防止了。

案例解析：馬里奧賽車

用該演算法實現馬里奧賽車是很簡單的，影子和實體都使用慣性，由於賽車慣性很大，不容易有突變的狀態更新，所以效果會比FPS遊戲更好。

玩家碰到道具後，馬上在屏幕上隱藏該道具的顯示並通知伺服器，由伺服器決斷道具屬誰，由於剛碰到道具就隱藏所以不會有碰到道具卻在一段時間內無法取得延遲現象。

遊戲道具系統實現也很容易，比如那個將當前第一名炸毀的道具，它的描述是：原角色+對象角色+約定發生時間。既然知道對象是誰，什麼時間發生，那就更本不需要怎麼同步了，所有客戶端和伺服器在該時間讓炸彈爆炸就得了，這種手法類似即時戰略遊戲。

遊戲還有一類道具是可以發射的烏龜殼，這個東西屬於有彈道的發射物，類似Quake裡面的某些武器，需要作一些同步處理，基本特性是伺服器判斷起決定作用，客戶端同步判斷，如果客戶端與伺服器都判斷集中，那就集中；如果客戶端判斷集中而伺服器判斷沒有集中，那會看到該角色似乎被打了一下，但很快又恢復了速度向前沖。

由於賽車本身就具備慣性比較大的特點，因此同步效果是比較好的，可以在更大的延遲情況下表現得和FPS差不多（比如300ms效果相當於FPS的200ms）。

非可靠包：

該「影子跟隨演算法」支持非可靠傳輸協議，如果使用非可靠傳輸，那麼我們按照特定頻率（如每秒10次）定時發送狀態更新，因為協議中每個更新包出了位置外還有速度、方向和時間，甚至還能加速加速度，因此我們丟一個包沒有關係，可以根據後來的包重新計算插值。只有關鍵狀態更新時才需要可靠傳輸，這就避免了TCP中丟包時RTO指數增長造成的延遲了。

負面情況：

該演算法缺點就是無法向「幀間同步」演算法那樣，每次發送按鍵給伺服器，伺服器處理後再反饋結果，在區域網中（平均延遲&<5ms），這樣的效果相當於單機遊戲一樣即時，遊戲性也能很複雜。然而在Internet中（平均延遲130ms，設計基準200ms，每秒最多發送10個數據包）該演算法卻不能像單機遊戲那樣有複雜的場景互動，有類似格鬥遊戲的即時的動作判定。

許多策劃在設計實時動作遊戲時很多設計我們都難以實現，這樣因為策劃不容易明白哪些我們能做，哪些我們不能做。即便程序員精通同步理論，策劃也經常碰壁。

當多數設計被程序員回復「無法實現」後，策劃只有採取一種消極設計（砍掉很多有意思的互動元素），於是網路遊戲的表現力到今天還是差單機遊戲一大截。

這些問題也並不能因為「影子跟隨演算法」的提出而得到改進，大於100ms的判定時間，都很難做到即時。

最後，該演算法編碼複雜度比其他同步策略高，因為伺服器需要計算一份影子數據，各個客戶端需要計算一份影子數據，還需要計算實體追趕，而這三種計算都需要在同樣的時鐘下保持一致，這就增加了編碼與調試的複雜度。

總結話題：

Internet特點是「高帶寬，高延遲」，可以說從本質上Internet就不是為了遊戲而設計的。故此Internet絕對意義的同步是不存在的。「影子跟隨演算法」的核心思想有幾個：時鐘同步，客戶端先行，平滑追趕。通過這三個特性，我們能夠在近似時間同步的情況下，模擬各種物體的移動過程，而使用該演算法的前提是設計者需要根據各個遊戲的特性研究不同的優化技巧，策略因遊戲而變。

比如發送狀態更新包時，不需要每次都發送，而可以只發送改變的狀態。什麼時候我們覺得改變了？就是當客戶端實體與自己的影子之間的誤差大於某特定數值時我們才發送更新包，這樣雖然玩家在原地做左右搖擺的小幅度移動，只要沒有超出範圍，都不需要發送新的狀態更新，其他玩家機器上看起來，它是站著不動的。

比如當發現某客戶端5秒鐘沒有相應了，那麼就將該人物的影子凍結住，永遠不要為了等待某個數據而不讓遊戲進行下去。

本演算法需要客戶端與伺服器維護相同的時鐘，當每5分鐘同步的時候，直接根據伺服器的時鐘替換當前時鐘就行了，不需要重新計算所有影子的位置，因為後續的狀態數據將會馬上刷新這些狀態。更不需要將測量到的PING值考慮進去，該演算法與PING具體值無關。

當發現策劃案子不可行時，尋找近似替代方案，比如減少「一次性的」「決定性的」事件發生，比如延長導彈在空中飛行的時間，比如將敵人加入HP分多次打死，而不是以及斃命，等等，都是大家可以發揮想像的地方。

相關例子：

文章相關DEMO如果有需要的話，可向我索要。

參考閱讀：

韋易笑（2006），幀鎖定演算法

韋易笑（2005），網遊同步法則

首先，不存在通用的延遲解決方案。

其次，延遲處理方案其實非常簡單，最多只是麻煩些而已。關鍵在於兩點：
1.重點偏向。開發商，你們願意偏向於哪個重點？公平？刺激？照顧低延遲？節約流量？等等。不同的重點偏向，會帶來不同的系統設計、演算法，會導致不同的用戶體驗。

2.代價。開發商，你們願意為了提高用戶體驗，花費何種代價？普通渣渣淘汰二手伺服器還是超高主頻的定製伺服器？渣渣二線聯通鐵桶網路還是骨幹BGP放核心節點然後專線到各省各IDC的子CDN節點？

最後提醒：
設計一款網路遊戲，在需求收集時期就需要把網路問題考慮進去，而不是等遊戲都做好了，再去根據網路做優化。

網路延時是無法避免的，延時長短也是無法量化的，因此無法做到和單機一樣的效果。可以通過一些類似於時間戳之類的概念去修正——接受數據方根據相對時間來決定遊戲的邏輯表現。但是這樣會又造成表現上的時間黑洞，也就是所謂的「跳幀「。但至少從數據上看，是近似同步了。

沒有絕對的同步，伺服器會模擬你的動作，你可能突然卡了一下沒發過去，但是伺服器那已經動了，你要是偏差的太多，就拉會拉人，導致你會看到有些人閃來閃去，具體規則就看設計了

CF這種FPS類型的遊戲，當ping高於50的時候通信延遲就會比較明顯了，達到100則有明顯感覺的延遲。而ping的好壞依賴於伺服器的DNS和寬頻運營商，上行速度太小會影響通信傳輸。
而我國大部分寬頻都是ADSL，在一些需要30HZ以上傳輸數據的遊戲里，對網路和硬體都是考驗，而ADSL上行速度被限制嚴重所以很多時候用ADSL的用戶會ping很高，實際是由於上行帶寬很小或被佔用。
遊戲同步性，樓上回答很好了，不多說。

請問一下，類似《球球大作戰》或《貪吃蛇大作戰》使用的是哪一種同步策略啊？