roblox-networking

roblox-networking

使用する場面

タスクの主な内容が、Roblox エクスペリエンスにおけるマルチプレイヤー通信、レプリケーション、または信頼境界に関する場合に、このスキルを使用します。

• RemoteEvent、UnreliableRemoteEvent、RemoteFunction の使用方法を設計またはレビューする場合。
• クライアントが送信できる内容と、サーバーが導出または検証しなければならない内容を判断する場合。
• 安全なリモートのペイロード形式を選び、引数を検証し、レプリケーションのタイミングに対処する場合。
• スパム、不正なペイロード、実行不可能なリクエスト、またはエクスプロイトによる悪用からサーバーのロジックを保護する場合。
• クライアントがアクションを開始しつつ、サーバーが権威を維持するインタラクションを構築する場合。
• ネットワーク所有権、クライアント予測による物理挙動、または Touched に関連するエクスプロイトのリスクについて検討する場合。
• 競技性のあるゲームプレイやサーバーが権威を持つゲームプレイで、サーバー権威の考え方、予測、ロールバックを考慮した構造、または入力ルーティングを適用する場合。
• ストリーミングによってクライアントが現在見たりアクセスしたりできる対象が変化しても、正しく動作しなければならないマルチプレイヤーロジックを設計する場合。

次のようなタスクが主な内容の場合、このスキルは使用しないでください。

• 永続データのアーキテクチャ、保存形式、トレードデータの保存、または DataStore と MemoryStore の設計。
• 主な目的が、エンジン API を幅広く調べること。
• Open Cloud、OAuth、または外部 Web 連携。

判断ルール

• 主な質問が「クライアントとサーバーは、安全かつ正確に通信するにはどうすればよいか？」であれば、このスキルを使用します。
• 機能がリモート、レプリケーションのタイミング、シミュレーション対象パーツの所有権、またはサーバー検証に依存する場合は、このスキルを使用します。
• 一方向の通知や状態通知には RemoteEvent を優先し、破棄可能で継続的に変化するデータに限って UnreliableRemoteEvent を使用します。同期的な応答が本当に必要な場合に限り、RemoteFunction を使用します。
• 共有ゲーム状態、報酬、戦闘結果、移動の許可、その他のプレイヤーに影響するあらゆるアクションについて、サーバーを権威として扱います。
• クライアントがアクションをリクエストできる場合は、状態を変更したり結果をブロードキャストしたりする前に、サーバー側で権限、コンテキスト、型、構造、値の範囲、頻度を検証します。
• タスクの主な内容が、スクリプトの配置場所、コアサービス、属性、バインダブル、または基本的なランタイム構造であり、ネットワークやセキュリティが中心ではない場合は、roblox-core に引き継ぎます。
• タスクの主な内容が、データの永続化またはサーバー間の状態である場合は、roblox-data に引き継ぎます。
• タスクの主な内容が、クラスやメンバーの網羅的な検索である場合は、roblox-api に引き継ぎます。
• リクエストにネットワークと対象外のシステムが混在する場合は、マルチプレイヤーと信頼境界に関する部分だけを回答し、それ以外は明示的に対象外とします。
• 判断に迷う場合は、永続化、クラウド認証、または幅広い API カタログの案内に踏み込む内容を省きます。

手順

1. まず、情報の各要素を分類します。
   • クライアントからの入力意図。
   • サーバーが導き出す権威ある状態。
   • 複製される表示または通知。
   • 破棄可能なテレメトリまたは装飾的な更新。
2. 用途に合った、最も限定的なネットワークプリミティブを選びます。
   • 非同期の一方向通信には RemoteEvent を使用します。
   • 頻繁に送信され、更新の欠落や順序の入れ替わりを許容できるデータには UnreliableRemoteEvent を使用します。
   • 待機が許容され、判断の主体がサーバーであることが明確な、短時間で完了するリクエスト／レスポンス処理に限り RemoteFunction を使用します。
3. リモートの契約は明確かつ小規模に保ちます。
   • 安定した引数の順序と、文字列キーを持つ辞書を優先します。
   • メタテーブル、関数値、型の混在したテーブル、複製されないインスタンス、またはネットワークを介したテーブルの同一性の維持に依存しないでください。
   • 任意のオブジェクトツリーではなく、識別子、コンパクトな値、または検証済みの複製されたインスタンスを渡します。
4. 結果ではなく意図を中心にリモートを設計します。
   • クライアントは「このターゲットに対してインタラクトを押した」または「ここからこの着弾点に向けて発射しようとした」と伝えます。
   • サーバーが、そのアクションが許可されているかを判断し、結果を計算します。
   • クライアントが報酬、ダメージ、インベントリの変更、または制限のないインスタンスの変更を直接宣言するリモートは避けてください。
5. クライアントがトリガーするすべてのリクエストをサーバーで検証します。
   • 権限／コンテキスト：プレイヤーは生存しており、範囲内で、適切な状態にあり、今その操作を行うことが許可されていますか？
   • 型／形状：引数の型、サイズ、インスタンスクラスは想定どおりですか？
   • 値の妥当性：あり得ない数値、NaN、inf、範囲外のベクトル、未知の ID を拒否します。
   • タイミング：高コストな処理や多数の宛先へのブロードキャストの前に、プレイヤーごとのレート制限またはクールダウンを適用します。
6. サーバーからクライアントへの再ブロードキャストは、特権的な操作として扱います。
   • あるクライアントから他のクライアントへの無条件な中継は決して行わないでください。
   • まず検証し、その後、表示に必要な最小限の安全なデータのみをブロードキャストします。
7. RemoteFunction は慎重に使用します。
   • 呼び出し元は待機することを想定します。
   • コールバックは高速かつ決定的に保ちます。
   • クライアントでエラーが発生したり、切断されたり、応答が返らなかったりするとサーバーが停止または失敗する可能性があるため、重要な処理での InvokeClient() は避けてください。
8. 複製について明示的に考慮します。
   • リモートが到着しても、関連するインスタンスやプロパティがすでにクライアントに複製されているとは限りません。
   • ストリーミングが有効な場合、クライアントは離れたワークスペースのコンテンツを現在保持していないことがあります。
   • 存在を前提とするのではなく、WaitForChild()、複製を考慮した設計、タグ、またはモデルのストリーミング制御を使用します。
9. ネットワークオーナーシップは、セキュリティ上のコストを伴うパフォーマンス向上の手段として扱います。
   • クライアント所有の物理演算は、応答性を高められます。
   • クライアント所有の物理演算は悪用される可能性もあり、サーバー側での Touched ベースのロジックは特にリスクが高くなります。
   • 検証の負担を受け入れて応答性を高める価値がある場合を除き、ゲームプレイ上重要な物理演算はサーバー所有のままにします。
10. 権威あるゲームプレイや対戦型ゲームプレイでは、次の点に従います。

• サーバーが信頼できる唯一の情報源であり、クライアントは主に入力を提供するという、サーバー権威の考え方を優先します。
• 中核となる権威あるシミュレーションに影響する入力には、Input Action System を使用します。
• シミュレーション状態は、ローカルの描画やエフェクトと分離して管理します。

11. 例を説明する際は、範囲内にとどめます。

• マルチプレイヤー通信、検証、オーナーシップ、権威、ストリーミングの正確性に焦点を当てます。
• 永続化アーキテクチャ、クラウド API、汎用 API カタログに話を広げないでください。

リファレンスの参照

• リモートによる選択、方向性、引数の形式に関する制限、安全なペイロードの設計については、references/remote-events-and-callbacks.md を開いてください。
• レプリケーションのタイミング、レイテンシーの想定、ゲームプレイの責務をどちら側が担うかについては、references/client-server-runtime.md を開いてください。
• セキュリティの考え方、防御的な設計、レート制限のパターンについては、references/security-and-defensive-design.md を開いてください。
• 具体的な検証レイヤー、安全な再ブロードキャストのパターン、クライアント起点のインタラクションの保護については、references/client-server-boundary-guidance.md を開いてください。
• 物理演算の応答性、クライアント所有のパーツ、または Touched の妥当性が問題に関係する場合は、references/network-ownership.md を開いてください。
• 権威あるシミュレーション、予測、ロールバックを考慮した構造、レイテンシーを意識した設計については、references/server-authority-model-and-techniques.md を開いてください。
• ネットワーク接続または権威あるゲームプレイが、アクション指向のクロスプラットフォーム入力ルーティングに依存する場合は、references/input-action-system.md を開いてください。
• 正確性がストリーミングされたワークスペースのコンテンツ、レプリケーションのフォーカス、またはローカルに存在しない可能性のあるモデルに依存する場合は、references/streaming-and-replication-behavior.md を開いてください。

チェックリスト

• クライアントとサーバー間の契約は、クライアントが宣言する結果ではなく、プレイヤーの意図に基づいて定義されています。
• 選択したリモートプリミティブは、必要な信頼性と応答動作に合致しています。
• リモートのペイロードには、安定したレプリケーションに安全な形式を使用しています。
• サーバーは共有状態を変更する前に、権限、コンテキスト、型、構造、値を検証します。
• サーバーは、悪用されやすいエントリーポイントにレート制限またはクールダウンを適用します。
• サーバーからクライアントへのブロードキャストは検証後にのみ行い、無条件の中継は行いません。
• RemoteFunction の使用には正当な理由があり、その範囲が制限されています。
• 特に、リモートが新たに作成されたコンテンツやストリーミングされたコンテンツを参照する場合、レプリケーションのタイミングに関する前提が明示されています。
• ネットワーク所有権の選択には明確な意図があり、必要に応じてサーバー側の検証と組み合わせています。
• Touched、近接、クリック、ドラッグによるインタラクションは、エンジンが発生させたという理由だけで信頼していません。
• 権威あるゲームプレイでは、クライアントのシミュレーション結果を信頼せず、クライアントの入力とサーバー所有の状態を使用します。
• 入力に関するガイダンスは、Input Action System のネットワーク接続または権威ある用途に焦点を当てています。
• 永続化アーキテクチャ、Open Cloud、OAuth、または広範な API カタログの内容は含まれていません。

よくある間違い

• 誰がダメージを受けたか、どの報酬を獲得したか、どの状態変更がすでに発生したかを、クライアントにサーバーへ伝えさせる。
• 非同期の RemoteEvent とサーバー側の状態を使うほうが安全なのに、手軽さを理由に RemoteFunction を使う。
• 検証せずに、あるクライアントのペイロードをほかのすべてのクライアントにブロードキャストする。
• 型が混在したテーブル、メタテーブルを使うオブジェクト、巨大なペイロード、または送信側にしか存在しないインスタンスをリモート経由で渡す。
• NaN、inf、サイズ超過の文字列、または偽装されたインスタンス参照を拒否し忘れる。
• リモートを送信すれば、関連するパーツ、属性、またはモデルがすでにレプリケーションされていると思い込む。
• サーバー側のレート制限なしで、クライアントのクールダウンに依存する。
• クライアント所有の物理演算や Touched イベントを、接触を示す権威ある証拠として扱う。
• 順序どおりに届く必要がある状態に、信頼性の低いチャネルを使う。
• 権威あるシミュレーションの中核ロジックと、ローカル専用のアニメーション、カメラ、VFX のコードを混在させる。

例

クライアント起点のインタラクションを安全に設計する

-- Client: request an interaction attempt, not the reward itself.
InteractRemote:FireServer(targetId)

-- Server: verify range, state, and target validity before applying effects.
InteractRemote.OnServerEvent:Connect(function(player, targetId)
    -- Validate player state, target existence, distance, cooldown, and permissions.
    -- Then mutate shared state on the server.
end)

破棄可能な更新に限って信頼性の低いリモートを使う

-- Suitable for frequent cosmetic aim or camera direction updates.
AimDirectionRemote:FireServer(lookVector)

• パケットの欠落や順序の入れ替わりを許容します。
• インベントリ、ダメージ、スコア、または一度限りのトランザクションには、このパターンを使わないでください。

権威あるシミュレーションをレンダリングから分離する

-- Core state changes live in shared/server-side simulation logic.
-- Local VFX and sounds react to the synchronized state afterward.