This document is about: QUANTUM 2
SWITCH TO

Cheat Protection

概述

安全性及防作弊是線上多人遊戲中最重要的議題。Quantum的確定性提供了處理這些議題的獨特功能。此頁面將討論內建防護的細節,並提供以Photon Quantum建立做好防護的線上遊戲的最佳作法。

對於開發者而言,注意所有與安全性相關的議題,以及注意處理這些議題的步驟及時間點,是相當重要的。雖然可能可以在伺服器上運行全模擬,但從實用和成本角度而言,這是非常罕見的作法。

  • 運行伺服器相當花成本,特別是當遊戲還沒有產生營收的時候。
  • 在大多數案例,作弊者只佔使用者基數的很小一部分。
  • 製作一個100%防止作弊的遊戲是一個過於理想化的概念,即使只是接近這樣的作法,都是一項艱巨的任務。
  • 有一些遊戲類型最大限度地依賴安全性。
簡單且最重要的建議是:現在撰寫遊戲,並且逐漸地新增這些更為複雜的安全檢查。在沒有自訂伺服器的情況下上線並取得成功是絕對可行的。

在文檔中,使用了下列用語:

  • 一個 遊戲後端 是指由客戶建立及主控的線上服務;
  • 一個 自訂伺服器(/外掛程式) 是指一個Photon主控的客戶自訂的Quantum外掛程式;以及
  • Quantum公用雲端 是指Photon主控的非自訂的Quantum伺服器。

透過確定性的防作弊

即使沒有伺服器來運行模擬,一個確定性遊戲的最大優勢是其作弊穩固性;如果一個玩家修改了他的客戶端,舉例而言更改了他的角色的速度,它將 不會影響任何其他玩家。他們可能會注意到作弊的玩家的怪異行為(比如不斷撞到牆上),但其他方面他們的體驗不會受到影響。

這個原因很簡單:各個客戶端確定性地在本機運行完整的模擬,並且與其他客戶端只共享輸入。

可信任的對戰結果

對戰結果用於更新一個遊戲後端中的玩家進度。在最安全的情況下,這是從運行遊戲邏輯的伺服器上完成的。

然而,在轉為權威遊戲伺服器之前,有一些可用的重複運算,可能可以在一個節省成本的方式下確保結果。

原型 客戶端推送他們各自的結果到開發者遊戲後端。這對於原型而言很好,並且遊戲也可以以這個設定來啟動。第一件事是有一個可以填入結果以發送到後端的資料結構。
多數決 客戶端個別地推送對戰結果,但是後端基於多數決來選擇結果。發送(可能地)遭竄改的資料的極端者可被識別。不需要等待客戶端的確認,只要立即顯示他們的結果給他們看,並且只在後端驗證結果 _之後_ 儲存進度。
重新模擬重播 如果無法透過多數決或一個統計評估而達成一致,則標記該對戰以進行重新驗證,並且收集玩家的輸入歷史。有了輸入歷史、組態檔案及資產資料庫,Quantum模擬可以在Unity之外運行,以重新檢查結果(重播)。請參見在Quantum SDK中的Quantum-主控台-運行器專案,並且閱讀下列章節以了解如何存取重播資料。
自控觀眾裁判 使用一個裁判觀眾,一個.Net應用程式,其可以連接到即時對戰,並且同步運行模擬,之後從它來提交最終結果,而非讓玩家來發送它。
自訂Quantum伺服器 在伺服器上運行模擬,並且提交其結果(請參見Quantum-自訂-外掛程式SDK)。

如何存取重播資料

Quantum 2.1及更早版本

  • 由一個客戶端要求發送
  • 從自控觀眾裁判發送
  • 從自訂Quantum伺服器發送

Quantum 2.2.(已計劃)

  • 針對Quantum公用雲端使用者的可組態的網路回調,以串流已驗證的輸入歷史到另一個後端

自控觀眾裁判

Quantum模擬可以以一個spectator來加入;一個觀眾是一個客戶端,其可以連接到伺服器,並且運行一個完整的遊戲,但不能發送輸入。這可以用來從一個被信任的來源來開始及初始化遊戲。

  1. 建立一個觀眾應用程式(在Unity之外運行)。
  2. 在任何地方運行它,以安全地與遊戲後端通信,以開始及準備一個Photon房間。
  3. 開始一個Quantum遊戲。
  4. 讓其他客戶端延遲加入模擬(請參見在Quantum SDK中的Quantum-主控台-觀眾專案)。
為了觀眾目的而新增另一個人工的客戶端到Photon房間,將增加CCU計數,其是伺服器成本的基礎。對於低玩家計數(一對一)的遊戲而言,這可能是一個問題,因為它明顯地增加CCU計數。

自訂Quantum伺服器

在Quantum伺服器上運行自訂程式碼,需要租用Photon企業伺服器。這將在下列方面啟用授權:

  • 可以運行 在伺服器上的遊戲模擬 到:
    • 針對 遊戲結果 有一個受信任的來源
    • 啟用 伺服器快照 (當使用公用Quantum雲端時由客戶端發送)
  • 可以插入 伺服器控制的秘密 到遊戲中(伺服器命令)
  • 可以攔截及 取代 DeterministicConfigRuntimeConfigRuntimePlayer
  • 可以 儲存已驗證的重播

保護客戶端控制的遊戲組態

在一個對戰開始時,兩個重要的 共享組態檔案由客戶端所發送DeterministicConfig(Quantum設定)及RuntimeConfig(遊戲設定)。伺服器將接受第一個收到的(DeterministicConfig、RuntimeConfig),在大多數案例中這多少是隨機的。

客戶端也發送另一個組態,其描述玩家卸載:RuntimePlayer。 為了讓它與儲存在一個後端的玩家進度進行驗證,需要一個Quantum伺服器外掛程式。

公用Quantum雲端 針對DeterministicConfigRuntimeConfig選擇一個隨機的來源
自訂Quantum伺服器 在從開發者後端擷取所有組態之後,所有組態可被攔截及取代
儀表板(Quantum 2.2中加入) 可透過關聯Photon儀表板中的一個應用程式帳號,在公用雲端伺服器上強制DeterministicConfig
網路回調(Quantum 2.2中加入) 開發者後端可調用一個在Photon儀表板上組態的webrequest,來驗證RuntimeConfigRuntimePlayer

自訂驗證

我們不提供一個驗證服務,或一個玩家資料庫,但我們絕對建議以新增一個專用或第三方的 驗證服務

Photon Realtime自訂驗證

確定性為一個不利條件

雖然確定性有非常多的好處,它也有這種科技類型所固有的一些值得一提的不利之處。

完美資訊問題

有了Quantum,每個客戶端都可以存取在本機模擬遊戲所需的所有資訊(除了其他玩家的輸入之外)。這意味著用於一個卡片遊戲及戰爭迷霧類的功能的 客戶端控制的秘密很容易被駭客控制

其他邊緣案例比如讓客戶端「猜測」 下一個隨機數字建立機器人 的能力。

使用總和檢查碼來偵測作弊者

針對即時遊戲,不建議使用Quantum總和檢查碼偵測,來作為一個偵測作弊者的方法。

  • 總和檢查碼計算相當昂貴,而且可能導致中斷;以及,
  • 對於 每個 正在遊戲階段中的客戶端,內建機制將立即停止模擬。
Back to top