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

多人游戲簡(jiǎn)史

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

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

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

客戶(hù)端預測

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

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

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

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

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

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

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

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