This document is about: QUANTUM 2
SWITCH TO

Server and Client Roles

概述

在確定性系統中,遊戲客戶端只與在所有客戶端上本機地運行的模擬,來交換玩家輸入。

在過去,針對所有遊戲客戶端,一個守舊的方法是必要的,就是在更新模擬的各個刷新/幀之前,等待來自所有其他玩家的輸入。Quantum的先進預測——回調系統 讓這種做法成為過去式,並且允許即時確定性模擬。

在Quantum中,預測系統允許遊戲客戶端使用輸入預測來本機地推進模擬,並且復原系統負責恢復本機遊戲狀態以及重新模擬任何錯誤預測。

一個跨遊戲平台的授權伺服器元件(Photon伺服器外掛元件)管理輸入延遲及時鐘同步,因此客戶端不需要等待最慢的客戶端來復原/確認向前的模擬。

Quantum Server-Managed predict/Rollback
在Quantum中,透過跨遊戲平台的伺服器邏輯來管理確定性輸入交換。這防止網路連線不佳的遊戲客戶端來干擾網路連線良好的玩家的體驗。

伺服器

Quantum是一個基於伺服器的解決方案。Quantum伺服器外掛元件有兩種版本,預設的跨遊戲平台的版本及自訂版本。前者適用於在 公共雲 上運行的所有遊戲,後者可以部署在專用的 Photon企業 叢集上。

針對目前的遊戲階段的 設置,由建立Photon房間的客戶端發送到伺服器的DeterminsticConfig來定義;這包含的資訊比如更新率或針對輸入接受的硬容錯,其將由伺服器使用以管理相關遊戲階段。

預設

針對 每個 Quantum應用程式ID來運行的預設外掛元件,其完成了中繼及同步客戶端輸入所需的一切事情,並且確保客戶端在本機運行一個確定性的模擬。這包含:

  • 輸入管理(時機及驗證)
  • 時鐘同步
  • 玩家索引指派

輸入管理是特別重要的,以保持向所有客戶端的輸入確認的一個健康及穩定的串流,因此確保不會出現過度復原。

輸入及驗證幀

一個經常詢問的問題是:誰簽署/授權 已驗證 幀?
答案是:技術上沒有人驗證一個幀;而是它是一個滿足以下2個條件的幀:

  1. 針對幀/刷新N的所有已驗證輸入已經從伺服器被接收;及,
  2. 所有先前的幀/刷新N-1已經使用它們的相應的已驗證輸入來被模擬。

如果滿足了這兩個條件,那麼幀將符合 已驗證。如需更多關於如何檢查幀的狀態的資訊,請參照到操作手冊中的 文件。

伺服器只是「簽署」一個已接受輸入的官方串流,並且在遊戲階段中轉傳這些已驗證輸入到客戶端。
因為輸入對推進本機模擬而言至關重要,因此與特定刷新/幀關聯的已驗證輸入足以讓所有客戶端在本機模擬一個確定性 已驗證 幀。

自訂外掛元件

專用伺服器(Photon企業)讓您做得比基礎更多。使用 Quantum自訂外掛元件,您可以針對輸入攔截、設置資料,及更多事情,來新增自訂控制,以由伺服器自訂遊戲階段管理。

注意事項: 開發及部署一個自訂外掛元件並不需要更改任何您的遊戲遊玩/客戶端程式碼。它是一個可選的步驟,可在已經完成核心遊戲之後逐步完成。

授權

如果您的目標是保留遊戲授權,您可以使用自訂外掛元件來執行以下操作:

  • 從伺服器推送完整輸入串流到後端。

  • 從所有完成遊戲的客戶端來檢查遊戲對戰結果。

    • 如果它們全部符合,就如實接受結果。
    • 如果有不符合,暫時接受多數決投票——也就是大多數客戶端發送的結果——,並且針對事後驗證來標記對戰
  • 自動事後驗證;只需以Quantum的主控台——運行器來運行已儲存重播。這不需要Unity,並且一個完整的對戰可以在幾秒內成為模擬。

注意事項: 上述的任何方面都不需要伺服器端模擬。

伺服器端模擬及作弊

技術上可以在伺服器運行完整的模擬,沒有任何限制。然而,從實際及成本的角度,這樣做不太合理。

通常這個問題出現在打擊作弊者的努力上。如果這是您最大的擔憂,那麼這就沒問題。

遊戲是確定性的,因此沒有辦法在人們通常理解的情況下「作弊」。在驗證對戰結果或回應投訴的情況下,您可以簡單地使用已經被伺服器驗證的官方輸入串流,以在您的端來完整地確認一個對戰結果——請參見先前的章節。可以不在伺服器上運行模擬的一個主——複本的情況下完成這件事。

客戶端

本機客戶端運行遊戲(在Quantum中的模擬+在Unity中的檢視)。它的工作是:

  • 及時發送輸入到伺服器。如果輸入沒有及時到達伺服器,它將被替換。
  • 基於已同步時鐘來預測幀。
  • 從伺服器接收一個輸入確認的連續的串流,復原(如需要)並且驗證幀。請參見先前的章節的 輸入及驗證幀 以了解流程的概述。

已驗證 幀的本機模擬以一個固定的更新率來運行。已預測 幀的數量各有不同,並且當模擬已經在本機遊戲階段累積了足夠的差量時間,預測將繼續。

假設頻繁復原,這意味著針對已預測幀,30hz的模擬率可以實際上以300hz來運行。雖然這可能看起來高得離譜,但它只是簡單地轉化為每1個已驗證幀1個復原+10個已預測幀。已預測幀的事情是它們被模擬,然後在復原時再次模擬。

在Unity中針對檢視的更新率是獨立於模擬率。為了簡化示例,讓我們假設一個30hz的Unity更新,這意味著各個Unity更新:

  • 推進1個已驗證幀(分派1個完整的已模擬重幀+已同步事件);及,
  • 復原所有已預測刷新並且重新模擬它們,從最新的已驗證開始直到已同步——時鐘(與RTT/2成比例)。

為了保證預測——復原系統即便在高Ping下也能平順地工作,您需要確保已預測刷新是足夠「輕量」的,以在前述的率下運行;減輕載入的一個方法是使用在預測剔除中的組建,其有助於預測相機周圍的實體,也就是在玩家的檢視中。

輸入、Ping及延遲

伺服器使用DeterministicConfig 中的HardTolerance,作為接受輸入的時機限制。如果伺服器沒有在已定義的時間框架內接收輸入,它將替換客戶端的輸入。

客戶端的本機復原的 最大 長度是:hard-tolerance + RTT/2 + jitter。伺服器針對每個客戶端來執行這個限制。這保證一致的體驗,不受到玩家數量的影響,因為它將玩家的體驗品質繫結到他們 自己的 網路品質;換句話說,如果一個客戶端有不好的網路連線,這只會影響他們自己的體驗,而其他所有人將維持平順。

正在參與遊戲階段的玩家更多,其中至少一人出現網路問題的機率就增加,因此這也變得更重要。

TL;DR:

這些是Quantum遊戲的基礎組建模塊:

客戶端:

  • 遊戲客戶端模擬器:與Quantum伺服器通信,運行本機模擬,執行所有輸入預測及復原。
  • 自訂遊戲遊玩程式碼:由顧客使用Quantum ECS來開發為一個獨立的純粹C#模擬(與Unity解耦)。
    除了提供一個組織高效能程式碼的框架之外,Quantum的API提供一系列可在任何遊戲中重複使用的預先組建的元件(資料)及系統(邏輯),比如確定性3D向量數學,2D及3D物理引擎,導航網格路徑尋找器等等。

伺服器:

  • Quantum伺服器外掛元件:在遊戲客戶端之間管理輸入時機及傳遞,作為時鐘同步源。
  • Quantum自訂外掛元件:可以擴展伺服器外掛元件以整合顧客主機端的後端系統(對戰配對、玩家服務等等)。

已預測 vs 已驗證幀:

  • predicted:客戶端基於本機客戶端預測的輸入,在任何幀率上模擬CPU輕量的「已預測」幀。
  • verified:當接收到伺服器驗證的輸入串流時,客戶端以一個已確定幀率來模擬CPU重量的「已驗證」幀;錯誤預測被復原並且重新預測。
Back to top