伺服器權限模型

在伺服器權限模型中，伺服器是整個遊戲狀態的唯一真相來源，客戶端僅被信任報告自己的輸入。這種架構是公平競技遊戲的核心網路代碼基礎，因為它通過不信任客戶端報告自己的位置或狀態來防止整個類別的作弊行為，例如飛行作弊或加速作弊。

優勢

在一個天真的伺服器擁有系統中，客戶端會簡單地將其輸入發送到伺服器，並顯示伺服器返回的遊戲結果。雖然在技術上是正確的，但這樣的系統會面臨顯著的輸入延遲，因為每個玩家的行動都必須傳送到伺服器，經過處理後再將結果發送回客戶端，然後才能顯示。對於大多數遊戲，尤其是那些快節奏的遊戲，這種往返延遲會使遊戲感覺延遲、不響應且無法遊玩。

在 Roblox 的伺服器權限模型中，延遲通過讓客戶端立即預測輸入的效果來補償，並將其發送到伺服器。例如，當玩家按下某個鍵時，客戶端不會等待伺服器的回應；相反，它會預測最後已知伺服器狀態的幾幀。這使得客戶端能夠立即顯示輸入行動的結果，有效地隱藏網路延遲，並使遊戲感覺響應迅速。

有時客戶端會錯誤地進行預測（錯誤預測），並且由於網路延遲，客戶端在幾幀內不會知道自己犯了錯。例如：

您的客戶端預測您已向前移動，但在伺服器上，另一名玩家使用了暈眩技能，阻止了您的移動。客戶端和伺服器現在有不同的狀態。

當檢測到錯誤預測時，客戶端必須根據伺服器的權威狀態來修正其預測。如果權威狀態與客戶端的預測狀態不同，客戶端必須回滾並重新模擬其預測幀。這種客戶端預測、回滾和重新模擬的系統被稱為「延遲補償」，有助於使伺服器權威的多人遊戲感覺流暢且響應迅速。

錯誤預測是伺服器權限架構中正常且預期的部分，因為客戶端本質上無法預測其他玩家的輸入，因此其他玩家的行動將始終觸發一定程度的錯誤預測。當調整得當時，隨之而來的修正是微小的，應該對玩家來說是不可察覺的。進一步閱讀高級技術以平滑和掩蓋網路伪影。

設置

伺服器權限模型需要某些其他引擎技術才能正常運行。請確認 Explorer 中 Workspace 對象的以下屬性設置：

Workspace.AuthorityMode 必須是 Server（設置此項會自動設置以下五項）。
Workspace.NextGenerationReplication 必須啟用。
Workspace.PlayerScriptsUseInputActionSystem 必須啟用。
Workspace.SignalBehavior 必須是 Deferred。
Workspace.UseFixedSimulation 必須啟用。
Workspace.StreamingEnabled 必須啟用。

概念

伺服器權限系統基於幾個核心概念運行，如下所示。

客戶端預測

通過客戶端預測，客戶端在最後已知的伺服器狀態之前模擬幾幀，以立即預測玩家輸入的效果。這隱藏了輸入延遲，但預測可能後來被證明是錯誤的（客戶端錯誤預測），因此需要修正。客戶端嘗試模擬到足夠接近最後已知的權威伺服器狀態，以便其輸入能在預期的幀上到達伺服器。客戶端將預測的幀數基於客戶端和伺服器之間的延遲。

客戶端錯誤預測

當客戶端從伺服器接收到權威狀態時，它會將該狀態與其對該幀的本地預測歷史記錄進行比較。當客戶端的預測與伺服器實際執行的內容之間存在差異時，這就是錯誤預測。錯誤預測可能由多種原因引起，包括網路延遲的變化、其他玩家以客戶端未預期的方式行動、遊戲在伺服器上獨占運行某些邏輯等。

如果權威狀態與客戶端的預測狀態不同，客戶端必須回滾並重新模擬。

回滾和重新模擬

當客戶端檢測到錯誤預測時，它必須重置為伺服器的權威狀態，然後重新模擬以跳回其預測的幀。根據網路延遲，客戶端嘗試模擬到足夠接近最後已知的權威伺服器狀態，以便其輸入能在預期的幀上到達伺服器。

在上面的圖中，客戶端在伺服器之前模擬了 2 幀。它為幀 3 發送其輸入，這些輸入在伺服器的預期幀（3）上到達。伺服器發送幀 3 的權威狀態，客戶端在幀 7 收到它。客戶端發現它錯誤預測了幀 3，因此它重置為伺服器的幀 3，並在模擬幀 7 之前重新模擬幀 4、5 和 6。玩家可能會看到明顯的網路伪影，例如突然的移動。

總結來說，客戶端：

接收來自伺服器的權威狀態並將其與自己的預測狀態進行比較。
如果客戶端的預測不正確：
1. 客戶端回滾到從伺服器接收到的最後已知權威狀態。
2. 客戶端從權威狀態重新模擬到其預測狀態，重新應用任何本地輸入。

實現

網路擁有權和預測

在伺服器權限模型中，您可以保持核心遊戲對象由伺服器擁有，而不會產生通常與伺服器擁有相關的輸入延遲成本。像汽車、玩家角色或其他遊戲關鍵對象可以保持由伺服器擁有，即使在與其他玩家互動時也是如此。

默認情況下，Roblox 將自動預測靠近本地玩家 Character 的具有模擬訪問的屬性，但如果您想要更細粒度的控制，可以使用 RunService:SetPredictionMode() 明確強制實例的預測開啟或關閉。

自動預測適用於整個物理組件，而不是單個實例。當客戶端預測一個部件時，它還會預測通過焊接、關節或約束與其物理連接的每個部件，以及這些部件的父 Model 和該模型內的任何 Humanoid。例如：

一個焊接到預測角色的劍模型成為角色組件的一部分，因此它會自動預測。
一個父級為角色但不與其物理連接的模型是一個單獨的組件。只有當它在客戶端的模擬半徑內或您使用 RunService:SetPredictionMode() 強制開啟預測時，才會進行預測。

要檢查特定實例是否當前被預測，可以從客戶端調用 RunService:GetPredictionStatus()。

模擬同步

在伺服器權限模型中，客戶端和伺服器都必須運行核心模擬，並且客戶端的模擬需要能夠在發生錯誤預測時回滾並重新模擬。為了啟用這一點，請將您的核心邏輯寫在通過 RunService:BindToSimulation() 綁定的函數中，這些函數在客戶端和伺服器上都會初始化。

在重新模擬期間，Roblox 將重新運行通過 BindToSimulation() 綁定到模擬的函數。處理玩家輸入、與同步的物理對象互動以及更新核心遊戲狀態應該在這些綁定函數內進行。

在綁定的模擬函數內，使用 time() 進行任何基於時間的邏輯，例如驅動動畫速度或隨時間波動的值。當 Workspace.AuthorityMode 為 Enum.AuthorityMode.Server 時，time() 在客戶端和伺服器之間是同步的，並使用固定步長模擬時間。在重新模擬期間，它會回到權威幀並在客戶端重播幀時向前推進，因此每次模擬幀時都會返回一致的值。

其他時間函數不共享此行為。tick() 和 os.time() 讀取本地設備時鐘，而 os.clock() 測量從任意本地基準開始的經過時間。它們在客戶端和伺服器之間不同步，並且在重新模擬期間不會回滾，因此避免在影響模擬的邏輯中使用它們。

ModuleScript 名為 Simulation 在 ReplicatedStorage 中：

模擬

local RunService = game:GetService("RunService")
local Players = game:GetService("Players")

local Simulation = {}

Simulation.Initialize = function()
	RunService:BindToSimulation(function(deltaTime)
		-- 讀取玩家輸入
		-- 更新遊戲狀態
	end)
end

return Simulation

使用屬性進行狀態同步

Roblox 自動同步所有具有模擬訪問的預測實例上的所有屬性。對於自定義數據，屬性是同步標記為預測的實例的主要方式；在這些實例上，伺服器的真相來源和客戶端的預測之間的任何屬性值不匹配都將觸發完整的回滾和重新模擬。

使用屬性來存儲影響您核心模擬的遊戲數據，包括玩家健康、彈藥、庫存或自定義規則（請參見限制）。

僅在通過 BindToSimulation() 綁定的函數內對預測實例的屬性進行寫入，以確保 Roblox 能夠完全跟踪相關的遊戲狀態並正確地重新模擬。

屬性限制

為了能夠被複製，屬性必須滿足以下所有標準：

它是其 Instance 上的前 64 個屬性之一。
它的名稱最多包含 50 個字符。
如果是字符串類型屬性，其值最多包含 50 個字符。

模擬訪問

引擎 API 參考中的許多屬性和方法都包含模擬訪問標籤，例如 BasePart.CFrame。具有此標籤的屬性將由伺服器權限系統進行預測。此外，只有具有此標籤的屬性和方法才能在通過 RunService:BindToSimulation() 綁定的函數內訪問。

創建和刪除實例

在通過 BindToSimulation() 綁定的函數內，您可以使用 Instance.new()、Instance:Clone() 或 Instance.fromExisting() 創建實例。客戶端立即創建實例，當伺服器的權威副本到達時，Roblox 將其與伺服器的權威副本合併。詳細信息，請參見預測實例創建。

刪除實例的方式不同。Instance:Destroy() 沒有模擬訪問，並且您無法更改已在 DataModel 中的實例的 Parent，因此在綁定函數內調用任一操作會導致錯誤。相反，請在模擬內的屬性中記錄刪除實例的意圖，然後在模擬外部刪除實例，例如在伺服器的 PostSimulation 連接中。

伺服器腳本 - 在模擬外部刪除實例

local RunService = game:GetService("RunService")

local character = script.Parent

RunService.PostSimulation:Connect(function()
	-- "SwordEquipped" 是當玩家卸下劍時由模擬寫入的
	local sword = character:FindFirstChild("Sword")
	if sword and not character:GetAttribute("SwordEquipped") then
		sword:Destroy()
	end
end)

Tools 在伺服器權限模型中尚未完全支持。Humanoid:EquipTool() 和 Humanoid:UnequipTools() 沒有模擬訪問，因此無法在綁定函數內調用。要構建可裝備的物品，例如劍，請在模擬內克隆並焊接 Model 到角色，並使用屬性跟踪其是否被裝備。

輸入行動

在伺服器權威遊戲中，客戶端影響遊戲狀態的主要方式是通過輸入行動系統。這些輸入被發送到伺服器，並在客戶端的重新模擬期間重播。因此，應該對所有影響核心模擬的輸入使用 InputActions，並且在處理之前應檢查其有效性。

重申一下，請勿在伺服器權威遊戲的核心模擬中使用傳統事件，例如 UserInputService.InputBegan。

請注意，InputContexts 必須是 Player 的子項，以便引擎知道誰擁有 InputContext。一種方法是將您的 InputContexts 添加到 ReplicatedStorage 下的文件夾中，並使用 Script 在 ServerScriptService 下為每個玩家克隆 InputContexts：

InputSetup

local Players = game:GetService("Players")
local ReplicatedStorage = game:GetService("ReplicatedStorage")

local InputsFolder = ReplicatedStorage:WaitForChild("Inputs")

local function onPlayerAdded(player)
	local clone = InputsFolder:Clone()
	clone.Parent = player
end

Players.PlayerAdded:Connect(onPlayerAdded)

for _, player in Players:GetPlayers() do
	onPlayerAdded(player)
end