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來加入；一個觀眾是一個客戶端，其可以連接到伺服器，並且運行一個完整的遊戲，但不能發送輸入。這可以用來從一個被信任的來源來開始及初始化遊戲。
- 建立一個觀眾應用程式（在Unity之外運行）。
- 在任何地方運行它，以安全地與遊戲後端通信，以開始及準備一個Photon房間。
- 開始一個Quantum遊戲。
- 讓其他客戶端延遲加入模擬（請參見在Quantum SDK中的Quantum-主控台-觀眾專案）。
自訂Quantum伺服器
在Quantum伺服器上運行自訂程式碼，需要租用Photon企業伺服器。這將在下列方面啟用授權：
- 可以運行 在伺服器上的遊戲模擬 到：
- 針對 遊戲結果 有一個受信任的來源
- 啟用 伺服器快照 （當使用公用Quantum雲端時由客戶端發送）
- 可以插入 伺服器控制的秘密 到遊戲中（伺服器命令）
- 可以攔截及 取代
DeterministicConfig、RuntimeConfig及RuntimePlayer - 可以 儲存已驗證的重播
保護客戶端控制的遊戲組態
在一個對戰開始時，兩個重要的 共享組態檔案由客戶端所發送：DeterministicConfig（Quantum設定）及RuntimeConfig（遊戲設定）。伺服器將接受第一個收到的（DeterministicConfig、RuntimeConfig），在大多數案例中這多少是隨機的。
客戶端也發送另一個組態，其描述玩家卸載：RuntimePlayer。
為了讓它與儲存在一個後端的玩家進度進行驗證，需要一個Quantum伺服器外掛程式。
| 公用Quantum雲端 | 針對DeterministicConfig及RuntimeConfig選擇一個隨機的來源 |
|---|---|
| 自訂Quantum伺服器 | 在從開發者後端擷取所有組態之後，所有組態可被攔截及取代 |
| 儀表板（Quantum 2.2中加入） | 可透過關聯Photon儀表板中的一個應用程式帳號，在公用雲端伺服器上強制DeterministicConfig。 |
| 網路回調（Quantum 2.2中加入） | 開發者後端可調用一個在Photon儀表板上組態的webrequest，來驗證RuntimeConfig及RuntimePlayer。 |
自訂驗證
我們不提供一個驗證服務，或一個玩家資料庫，但我們絕對建議以新增一個專用或第三方的 驗證服務。
確定性為一個不利條件
雖然確定性有非常多的好處，它也有這種科技類型所固有的一些值得一提的不利之處。
完美資訊問題
有了Quantum，每個客戶端都可以存取在本機模擬遊戲所需的所有資訊（除了其他玩家的輸入之外）。這意味著用於一個卡片遊戲及戰爭迷霧類的功能的 客戶端控制的秘密 將 很容易被駭客控制。
其他邊緣案例比如讓客戶端「猜測」 下一個隨機數字 或 建立機器人 的能力。
使用總和檢查碼來偵測作弊者
針對即時遊戲，不建議使用Quantum總和檢查碼偵測，來作為一個偵測作弊者的方法。
- 總和檢查碼計算相當昂貴，而且可能導致中斷；以及，
- 對於 每個 正在遊戲階段中的客戶端，內建機制將立即停止模擬。