プレイヤーにスムーズで反応性の高いエクスペリエンスを提供しながら、複雑な物理メカニズムをサポートするために、Roblox 物理エンジン は、サーバーとすべての接続されたクライアント間で計算が分配される 分散物理システム を使用しています。このシステム内で、エンジンは物理的にシミュレートされた ネットワーク所有権 をクライアントまたはサーバーに割り当て、物理学の計算作業を分割します。
クライアントは、サーバーとの通信の遅延がないため、所有するパーツの より反応性の高い 物理インタラクションを経験します。ネットワーク所有権は、物理計算を個々のクライアント間で分割できるため、サーバーが他のタスクを優先するようになり、サーバーのパフォーマンスが向上します。
ベースパーツの所有権
デフォルトでは、サーバーはどの BasePart にも所有権を保持します。さらに、サーバー は常に アンカーされた BaseParts を所有し、手動で所有者を変更することはできません。
クライアントのハードウェア容量とプレイヤーの 近距離に基づいて、エンジンは自動的にその部分の所有権をクライアントに割り当てます。たとえば、プレイヤーのキャラクターに近いパーツは、プレイヤーが所有する可能性が高い。
アセンブリの所有権
物理ベースのメカニズムに固定部品がない場合、アセンブリ内の所有権設定 は、そのメカニズム内のすべてのアセンブリに同じ所有権を設定します。
孤立したアセンブリが 部分ではない より広いメカニズムの一部である場合、その所有権はサーバーに移行します。サーバーは常に固定された BaseParts を所有しているためです。同じアセンブリをアンカー解除すると、前の所有状態が失われ、エンジンによる自動処理に戻ります。
1つのアセンブリをより広いアセンブリメカニズム内にアンカーすると、その所有権はサーバーに移行しますが、他のアセンブリの所有権は変更されません。同じアセンブリをアンカー解除すると、以前設定された所有権が戻ります。
所有権を設定中
複雑な物理インタラクションがあるエクスペリエンスや、直接の制御を割り当てる必要がある場合など、サーバー側の呼び出しを介して BasePart:SetNetworkOwner() の所有権を設定できます。
ゲームプレイに重要なオブジェクトで、クライアントが操作できないように手動で SetNetworkOwner(nil) を呼び出すことができる一方で、クライアントが不安定な物理インタラクションを引き起こす可能性があるため、保守的に行う必要があります。:
また、サーバー は常に アンカー付きの BaseParts を所有しており、手動で所有者を変更することはできません。車両にドライバー用の VehicleSeat オブジェクトと乗客用の Seat オブジェクトがあり、両方が車両アセンブリに含まれているものを考えてください。デフォルトの所有権ルールでは、プレイヤーキャラクターが Seat （パッセンジャー）に座り、その後別のプレイヤーが VehicleSeat （ドライバー）に飛び込むと、 パッセンジャー が全車両の物理的所有権を獲得します。なぜなら彼らが最初に入ったからです。ドライバは、入力が認識される前に複数のネットワークサイクルを待たなければならず、車両は応答性が低下します。
次の Script は、ドライバにネットワーク所有権を手動で割り当てることでこれを修正します。その中で、VehicleSeat はその Occupant を座っている Humanoid に設定し、スクリプトは座席の Changed イベントを聞いて、プレイヤーが座席に座るときにキャッチします。ドライバーが座席を離れると、車両のネットワーク所有権は BasePart:SetNetworkOwnershipAuto() で自動に戻ります。
local Players = game:GetService("Players")
local vehicleSeat = script.Parent
vehicleSeat.Changed:Connect(function(prop)
if prop == "Occupant" then
local humanoid = vehicleSeat.Occupant
if humanoid then
-- キャラクタからプレイヤーを取得する
local player = Players:GetPlayerFromCharacter(humanoid.Parent)
if player then
vehicleSeat:SetNetworkOwner(player)
end
else
-- シートが空いているときに所有権をリセットする
vehicleSeat:SetNetworkOwnershipAuto()
end
end
end)
スムーズなパフォーマンスと応答性を保つには、車両の上部にあるすべてのゆるい BaseParts の所有権を、車両を制御する同じクライアントに割り当てることを忘れないでください。
所有を視覚化する
ネットワーク所有のデバッグを助けるため、スタジオはプレイテスト中にオブジェクトの周りに色付きの境界線をレンダリングできます。
| 概要カラー | 説明 | |
|---|---|---|
| (緑) | クライアントがパーツを所有し、シミュレートしています。 | |
| (赤) | パーツは、クライアントがシミュレートしている「バッファゾーン」内にありますが、まだ他のものに所有されています。クライアントはこの後、所有権を得るかもしれません、または拒否するかもしれません。 | |
| (白/グレー) | サーバーまたは他のクライアントが、自動ネットワーク所有または part:SetNetworkOwner() を通じて明示的に割り当てて、パーツを所有します。 | |
マルチクライアントシミュレーション では、それぞれのクライアントに所有権を示すユニークな色が割り当てられ、これは サーバー ビューに反映され、特定の時点でどのクライアントがどの部分を所有しているかを判断するのに役立ちます。
ネットワーク所有の視覚化を有効にするには：
3D ビューポートの右上隅にある ビジュアライゼーションオプション ボタンをクリックします。
ドロップダウンメニューで、 ネットワーク所有者 を切り替えます。
セキュリティ上の懸念
クライアントが BasePart に所有権を持っているとき、Roblox は物理計算を確認できません。クライアントはこれを悪用し、BasePart をテレポートしてサーバーに悪いデータを送信したり、壁を通り抜けたり、空を飛んだりすることができます。
さらに、 イベントはネットワーク所有と結び付いており、クライアントが所有する イベントをネットワーク上で発射し、サーバーが何も触らないとしても、サーバーに送信できます。たとえば、クライアントはスクリプトインジェクションでイベントを発射して、マップ全体で別のプレイヤーに剣の取引ダメージを与えることができますので、クライアントによって発射されたイベントの有効性をチェックすることが重要です。
ロブロックス経験の詳細なセキュリティ戦略とチート排除戦略については、セキュリティ戦略とチート排除を参照してください。