你是一個喜歡玩游戲的人嗎？尤其是多人聯(lián)機(jī)？你有沒有想過多人游戲如何在游戲服務(wù)器的幫助下工作？讓我們從一些見解開始。在大多數(shù)情況下，現(xiàn)代在線游戲使用客戶端-服務(wù)器模型。在簡單的客戶端-服務(wù)器范例中，玩家傳輸輸入，例如，點(diǎn)擊服務(wù)器、鼠標(biāo)移動和按鍵。該服務(wù)器更新在游戲世界中你的性格和與合計攜帶你的性格和其他玩家作為響應(yīng)的更新狀態(tài)恢復(fù)的狀態(tài)。

多人游戲簡史

在游戲歷史的開始，游戲是點(diǎn)對點(diǎn)的網(wǎng)絡(luò)，多臺計算機(jī)在一個完全組合的網(wǎng)狀拓?fù)浣Y(jié)構(gòu)中相互交易信息。這些類型的游戲模型仍然存在于 RTS 游戲中，并且出于某種目的很有趣。因?yàn)檫@是第一種方式——這可能是大多數(shù)人認(rèn)為游戲網(wǎng)絡(luò)運(yùn)作的方式。在下一階段的動作游戲中，點(diǎn)對點(diǎn)鎖步的限制在《毀滅戰(zhàn)士》中越來越明顯，盡管在局域網(wǎng)上玩得很好，但對于普通用戶來說，互聯(lián)網(wǎng)上的表現(xiàn)卻很糟糕。

后來，為了領(lǐng)先于 LAN，例如連接良好的大學(xué)網(wǎng)絡(luò)或大型組織，開發(fā)模型是必不可少的。這就是客戶端-服務(wù)器模型發(fā)布并取代了一些現(xiàn)有的點(diǎn)對點(diǎn)游戲系統(tǒng)的時候。1996 年，這正是 John Carmack 和他的合作伙伴在發(fā)布采用客戶端/服務(wù)器而不是點(diǎn)對點(diǎn)的 Quake 時所做的。

現(xiàn)在代替每個玩家運(yùn)行相同的游戲代碼并直接相互交互，每個玩家現(xiàn)在都是一個“客戶端”，他們都只與一個稱為“服務(wù)器”的網(wǎng)絡(luò)進(jìn)行通信。游戲不再需要在所有設(shè)備上都具有確定性，因?yàn)橛螒驅(qū)嶋H上是在服務(wù)器上。每個客戶端都作為一個啞終端有效地工作，顯示游戲在服務(wù)器上進(jìn)行時的估計。這是一個很好的行動。游戲?qū)嵺`的本質(zhì)現(xiàn)在取決于客戶端和服務(wù)器之間的相關(guān)性，而不是游戲中的延遲對等點(diǎn)。玩家在游戲中途暫停和恢復(fù)也變得可以容忍，并且隨著客戶端/服務(wù)器降低每個玩家平均所需的帶寬，玩家數(shù)量增加。接下來發(fā)生的事情將永遠(yuǎn)改變這個行業(yè)。以前，問題當(dāng)然是延遲。后來，開發(fā)人員清除并繼續(xù)使一切正常工作。

客戶端預(yù)測

在最初的 Quake 中，您經(jīng)歷了計算機(jī)和服務(wù)器之間的延遲。例如，按向前，您將等待數(shù)據(jù)包傳輸?shù)椒?wù)器并返回給您所需的時間，然后才能真正開始；在另一種情況下，按開火并等待相同的延遲，然后再進(jìn)行射擊。如果您嘗試過任何現(xiàn)代 FPS，例如“使命召喚”、“現(xiàn)代戰(zhàn)爭”，您會覺得體驗(yàn)更好，沒有延遲。因此，為了消除延遲，客戶端很快就會處理比以前更多的代碼。它不是向服務(wù)器提供輸入并在發(fā)回的狀態(tài)之間插入的啞終端。相反，它能夠根據(jù)您的輸入，在客戶端機(jī)器上為您的玩家角色操作游戲代碼的子集，從而部分地和快速地預(yù)測您的角色的演變。現(xiàn)在，只要您向前推進(jìn)，客戶端和服務(wù)器之間的往返就沒有停頓——您的角色立即開始向前移動。

多人游戲服務(wù)器架構(gòu)

服務(wù)器將具有“垂直掃描速率”，即它頻繁更新玩家信息的速率。最好是匆忙，因?yàn)樵谟螒蛑忻恳豢潭己苤匾?。通常，需要多次滴答才能為用戶提供?shí)時體驗(yàn)。打勾表示信息每秒更新的次數(shù)。在每個刻度上，客戶端可能會向游戲世界發(fā)送玩家的動作、攻擊或任何變化。服務(wù)器上運(yùn)行著一個權(quán)威版本的世界。但是使用了各種方法來確保消費(fèi)者在采取行動之前不會期待另一端。

可能存在確定性動作和非確定性動作。在確定性動作中，服務(wù)器可以根據(jù)原始數(shù)據(jù)預(yù)測對象的未來狀態(tài)。例如，要給出槍聲事件，服務(wù)器只需要了解一些主要信息，例如方向和力量。根據(jù)此信息，服務(wù)器可以指導(dǎo)客戶端如何完成播放。在非確定性回復(fù)中，服務(wù)器無法預(yù)測未來的事件。因此，客戶端希望向服務(wù)器發(fā)送一致的數(shù)據(jù)流。獲得輸入數(shù)據(jù)，執(zhí)行模擬后，服務(wù)器傳輸包含所有客戶端點(diǎn)的正式版本的容器。

模擬代碼使用這些數(shù)據(jù)流，影響運(yùn)動并將它們固定到特定的圖形位置。這種模擬可以在服務(wù)器和消費(fèi)者上運(yùn)行。從編程方面來說，我們想要處理延遲問題。同時需要消息來報告，事情也就過去了。服務(wù)器和消費(fèi)者都必須玩弄時間來處理延遲。

為了在按鍵后為玩家提供即時反饋，客戶端可以預(yù)測服務(wù)器在獲得玩家輸入后的工作情況并很快執(zhí)行此操作。然后客戶端將其新位置報告給服務(wù)器。為了預(yù)測精確的狀態(tài)變化，客戶端還必須影響游戲環(huán)境。但是，由于延遲，客戶端和服務(wù)器可能會變得不合適。服務(wù)端可能會頻繁的通知客戶端此時需要進(jìn)行改進(jìn)，這會出現(xiàn)在玩家無法操作的動作中。

為了補(bǔ)償同步問題，一個計劃是讓服務(wù)器允許在它認(rèn)為玩家的狀態(tài)應(yīng)該是什么和玩家報告的狀態(tài)之間有一定數(shù)量的變化。一旦附加上，管理本地玩家的位置變化會很快導(dǎo)致游戲更加穩(wěn)定。 每個客戶端機(jī)器都會向服務(wù)器傳輸一個恒定的數(shù)據(jù)包流，其中每個數(shù)據(jù)包都包含對玩家輸入的簡單更新。每個刻度，客戶端可能會指定鼠標(biāo)位置或按下的鍵。這是帶寬不足的流。

模擬代碼使用這些輸入流，模擬運(yùn)動并將它們固定到角色位置。這種模擬可以在服務(wù)器和客戶端上運(yùn)行。服務(wù)器在接收到相關(guān)輸入時授予數(shù)據(jù)包，將使用傳輸模擬游戲位置。在大多數(shù)情況下，這將與客戶的假設(shè)準(zhǔn)確匹配。這些客戶位置僅與移動對象進(jìn)行比較。所有不變的對象永遠(yuǎn)不會更新。