サーバー権限モデル

サーバー権限モデルでは、サーバーがゲーム全体の状態の唯一の真実の源であり、クライアントは自分の入力を報告することだけが信頼されます。このアーキテクチャは、公平で競争的なゲームのコアネットコード基盤であり、クライアントが自分の位置や状態を報告することを決して信頼しないため、フライハックやスピードハックなどの全体的なチートのクラスを防ぎます。

利点

ナイーブなサーバー所有システムでは、クライアントは単に自分の入力をサーバーに送信し、サーバーから送信されたゲームの結果を表示します。技術的には正しいですが、そのようなシステムは、すべてのプレイヤーアクションがサーバーに送信され、処理され、結果がクライアントに送信される必要があるため、重大な入力遅延に直面します。特に高速なゲームでは、この往復遅延により、ゲームプレイが遅延し、応答がなく、プレイできなくなります。

Robloxのサーバー権限モデルでは、遅延はクライアントが自分の入力の効果をサーバーに送信するのに加えて即座に予測することによって補償されます。たとえば、プレイヤーがキーを押すと、クライアントはサーバーの応答を待たずに、最後に知られているサーバーの状態の数フレーム先を予測します。これにより、クライアントは入力アクションの結果を即座に表示でき、ネットワーク遅延を効果的に隠し、ゲームを応答性のあるものにします。

時には、クライアントが予測を間違えることがあります（ミス予測）が、ネットワーク遅延のため、クライアントは数フレームの間に自分が間違えたことを知りません。たとえば：

ミス予測が検出されると、クライアントはサーバーの権威ある状態に基づいて予測を修正する必要があります。権威ある状態がクライアントの予測された状態と異なる場合、クライアントはロールバックして再シミュレーションする必要があります。このクライアント側の予測、ロールバック、および再シミュレーションのシステムは「遅延補償」として知られ、サーバー権限のマルチプレイヤーゲームをスムーズで応答性のあるものにするのに役立ちます。

セットアップ

サーバー権限モデルは、正しく機能するために特定の他のエンジン技術を必要とします。Explorer内のWorkspaceオブジェクトで次のプロパティ設定を確認してください。

1. Workspace.AuthorityModeはServerでなければなりません（これを設定すると、次の5つが自動的に設定されます）。
2. Workspace.NextGenerationReplicationは有効にする必要があります。
3. Workspace.PlayerScriptsUseInputActionSystemは有効にする必要があります。
4. Workspace.SignalBehaviorはDeferredでなければなりません。
5. Workspace.UseFixedSimulationは有効にする必要があります。
6. Workspace.StreamingEnabledは有効にする必要があります。

概念

サーバー権限システムは、以下のいくつかのコア概念に基づいて動作します。

クライアント予測

クライアント予測を通じて、クライアントは最後に知られているサーバーの状態の数フレーム先をシミュレートして、プレイヤー入力の効果を即座に予測します。これにより入力遅延が隠されますが、予測が後で間違っていることが判明することがあります（クライアントミス予測）ので、修正が必要です。クライアントは、サーバーに入力が意図したフレームで到着するように、最後に知られている権威あるサーバーの状態の先をシミュレートしようとします。クライアントが知られているサーバーの状態の先を予測するフレーム数は、クライアントとサーバーの間の遅延に基づいています。

クライアントミス予測

クライアントがサーバーから権威ある状態を受け取ると、その状態をそのフレームのローカルで予測した履歴記録と照合します。クライアントが予測したものとサーバーが実際に行ったことの間に違いがある場合、これはミス予測です。ミス予測は、ネットワーク遅延の変化、クライアントが予測していなかった他のプレイヤーの行動、ゲームが特定のロジックをサーバー専用で実行することなど、いくつかの理由で発生する可能性があります。

権威ある状態がクライアントの予測された状態と異なる場合、クライアントはロールバックして再シミュレーションする必要があります。

ロールバックと再シミュレーション

クライアントがミス予測を検出すると、サーバーの権威ある状態にリセットし、その後、予測されたフレームに戻るために再シミュレーションを行う必要があります。ネットワーク遅延に基づいて、クライアントはサーバーの最後に知られている権威ある状態の先をシミュレートしようとします。

要約すると、クライアントは：

1. サーバーから権威ある状態を受け取り、それを自分の予測された状態と比較します。
2. クライアントの予測が間違っていた場合：

   1. クライアントはサーバーから受け取った最後の知られている権威ある状態にロールバックします。
   2. クライアントは権威ある状態から予測された状態まで再シミュレートし、ローカル入力を再適用します。

実装

ネットワーク所有権と予測

サーバー権限モデルでは、コアゲームプレイオブジェクトをサーバー所有のままにして、通常サーバー所有に関連する入力遅延コストを負担することなく維持できます。車両、プレイヤーキャラクター、または他のゲームプレイに重要なオブジェクトなどは、他のプレイヤーと相互作用しているときでもサーバー所有のままにできます。

デフォルトでは、RobloxはローカルプレイヤーのCharacterの近くにあるプロパティを自動的に予測しますが、より細かい制御が必要な場合は、RunService:SetPredictionMode()を使用してインスタンスの予測を明示的にオンまたはオフにすることができます。

シミュレーション同期

サーバー権限モデルでは、クライアントとサーバーの両方がコアシミュレーションを実行する必要があり、クライアントのシミュレーションはロールバックして再シミュレーションできる必要があります。これを有効にするには、RunService:BindToSimulation()を介してバインドされた関数内にコアロジックを書き、クライアントとサーバーの両方で初期化されたModuleScriptに配置します。

再シミュレーション中、RobloxはBindToSimulation()を介してシミュレーションにバインドされた関数を再実行します。プレイヤー入力の処理、同期された物理オブジェクトとの相互作用、コアゲーム状態の更新は、これらのバインドされた関数内で行う必要があります。

バウンドシミュレーション関数内の時間ベースのロジック（アニメーション速度の駆動や時間の経過に伴う値の振動など）にはtime()を使用します。Workspace.AuthorityModeがEnum.AuthorityMode.Serverの場合、time()はクライアントとサーバー間で同期され、固定ステップシミュレーション時間を使用します。再シミュレーション中、権威あるフレームに巻き戻り、クライアントがフレームを再生するにつれて進行するため、各フレームがシミュレートされるたびに一貫した値を返します。

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は、予測されたインスタンスのすべてのプロパティをシミュレーションアクセスを介して自動的に同期します。カスタムデータについては、属性が予測されたインスタンスを同期するための主要な方法です。このようなインスタンスでは、サーバーの真実の源とクライアントの予測との間で属性値に不一致があると、完全なロールバックと再シミュレーションがトリガーされます。

属性の制限

属性が複製されるためには、次のすべての基準を満たす必要があります。

• それはそのInstanceの最初の64の属性の中にある。
• 名前は最大50文字を含む。
• 文字列型の属性の場合、その値は最大50文字を含む。

シミュレーションアクセス

エンジンAPIリファレンスの多くのプロパティとメソッドには、シミュレーションアクセスラベルが含まれています。たとえば、BasePart.CFrameなどです。このラベルが付いているプロパティは、サーバー権限システムによって予測されます。さらに、このラベルが付いているプロパティとメソッドのみが、RunService:BindToSimulation()でバインドされた関数内でアクセスできます。

入力アクション

サーバー権限のゲームでは、クライアントがゲームの状態に影響を与える主な方法は入力アクションシステムを介してです。これらの入力はサーバーに送信され、再シミュレーション中にクライアントで再生されます。その結果、InputActionsはコアシミュレーションに影響を与えるすべての入力に使用され、処理される前に妥当性を確認する必要があります。

InputContextsは、エンジンがInputContextの所有権を知るためにPlayerの子孫である必要があります。1つのアプローチは、InputContextsをReplicatedStorageのフォルダーに追加し、ServerScriptServiceの下にあるScriptを使用して、プレイヤーごとにInputContextsをクローンすることです：

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

このパターンを使用すると、クライアントとサーバーの両方でRunService:BindToSimulation()内ですべてのプレイヤーのInputActionsを読み取ることができ、特定のフレームの同じデータを受信し、前のフレームの入力を属性に記録できます。たとえば、RunAction入力アクションがトリガーされたときにキャラクターのランをトリガーするために使用します。

リモートイベント

リモートイベントは、サーバー権限モデル内でクライアントとサーバー間の明示的な通信を促進するために引き続き使用できます。たとえば、サーバーはリモートイベントを使用して、プレイヤーがポイントを獲得したりオブジェクトを拾ったりするデータをブロードキャストし、クライアントはリモートイベントをサーバーに入力を送信するための代替APIとして使用できます。たとえば、ボタンの押下や3Dワールド内のオブジェクトのタップなどです。

アニメーション、サウンド、エフェクト

クライアント側のエフェクト（アニメーションやサウンドなど）は、クライアントシミュレーションが権威あるサーバー状態の単なる予測であることを考慮して記述する必要があります。BindToSimulation()は、バインドされた関数内から呼び出すことができるプロパティやメソッドを制限し、同期されたシミュレーション状態にのみ書き込むようにガイドします。このシミュレーションの結果を表示し、エフェクトやサウンドをトリガーするなどは、シミュレーションの結果を読み取り、希望するエフェクトをトリガーするRenderSteppedに接続された別の関数で行うべきです。

予測されたシミュレーションのレンダリングに関するさらなるガイダンスは、高度な技術ガイドで説明されています。

例プロジェクト

このドキュメントに加えて、以下のテンプレートがスタートを助けることができます：