Fusion 2 とは?
概要
Fusion 1.1から2.0への変更点はこちらをご覧ください
Fusionは、Unity向けの新しい高性能な状態同期ネットワークライブラリです。一般的なUnityのワークフローに自然に統合できるようなシンプルさを念頭に構築され、データ圧縮・クライアントサイド予測(Client-Side Prediction)・ラグ補償(Lag Compensation)などの高度な機能を標準で提供しています。
Fusion内部では、最小のCPUオーバーヘッドで帯域幅を削減する最先端の圧縮アルゴリズムが使用されています。データは結果整合性(Eventual Consistency)のある部分的なチャンクで転送され、関心領域(Area Of Interest:AOI)の設定によって大人数のプレイヤーにも対応します。
FusionのAPIは、UnityのMonoBehaviour
と似たコードで記述できるよう設計されています。例えば、RPCやネットワーク上の状態は、メソッドの属性やMonoBehaviour
のプロパティとして定義され、明示的なシリアライゼーションを必要としません。ネットワークオブジェクトはプレハブで定義することができ、Nested PrefabやPrefab Variantにも対応します。
Fusionでゲームプレイのコードを記述する基礎となるAPIは、入力・ネットワークプロパティ・RPCです。
ネットワークプロパティの使用例:
C#
[Networked] public int lives { get; set; }
入力の定義と設定(クライアントサイド予測による移動):
C#
public struct NetworkInputData : INetworkInput
{
public Vector3 direction;
}
public class InputPollBehaviour : SimulationBehaviour, INetworkRunnerCallbacks
{
public void OnInput(NetworkRunner runner, NetworkInput input)
{
NetworkInputData data = new NetworkInputData();
if (Input.GetKey(KeyCode.LeftArrow))
{
data.direction.x = -1;
}
else if (Input.GetKey(KeyCode.RightArrow))
{
data.direction.x = 1;
}
if (Input.GetKey(KeyCode.DownArrow))
{
data.direction.z = -1;
}
else if (Input.GetKey(KeyCode.UpArrow))
{
data.direction.z = 1;
}
input.Set(data);
}
}
入力の使用例(クライアントサイド予測による移動):
C#
public override void FixedUpdateNetwork
{
if (GetInput(out NetworkInputData data))
{
data.direction.Normalize(); // normalize to prevent cheating with impossible inputs
_characterController.Move(5 * data.direction * Runner.DeltaTime);
}
}
リモートプロシージャコール(RPC)の宣言例:
C#
[Rpc(RpcSources.InputAuthority, RpcTargets.StateAuthority)]
public void RPC_Configure(string name, Color color)
{
playerName = name;
playerColor = color;
}
適切なモードの選択
Fusionは同じAPIで、3つのまったく異なるネットワークトポロジーと、ネットワーク接続を行わないシングルプレイモードに対応しています。
Fusionを使い始める際には、まずどちらのモードを使用するかを選択することになります。
以下のクアドラント(Quadrant)は、どのモードがどのアプリケーションに適しているかを判断するのに役立つでしょう。
チュートリアル
既に使用するモードが決まっているなら、さっそくチュートリアルを始めましょう。
まだ使用するモードが決まっていないなら、これ以降の説明を読み進めましょう。
クアドラントの比較
クアドラントでは、4つのオプションが示されています。
- Fusion - Dedicated Server(サーバーモード)
- Fusion - Client Host(ホストモード)
- Fusion - Shared(共有モード)
- Quantum
これらは、以下のようなカテゴリーで比較されています。
- 推奨されるゲームジャンル:どんなゲームジャンルに適しているか?
- チート対策:プレイヤーはどの程度簡単にチートできるか?
- サーバー複雑性:オンラインが使用できるようになるまでのセットアップはどの程度複雑か?
- モバイル品質:モバイル上でゲームやアプリケーションはどの程度動作するか?
- コストパフォーマンス:どの程度費用がかかるか?
プロジェクトごとに要件は異なるため、選択するPhoton製品の違いを比較して理解することが重要になります。このドキュメントはPhoton Fusionにフォーカスしているため、Photon Quantumについて詳しく知りたい場合はこちらをご覧ください。
推奨されるゲームジャンル
ゲームのジャンルによって、最適なFusionのモードは異なります。
- Fusion - Dedicated Server(サーバーモード):強固なチート対策が可能なため、大人数の対戦ゲームに適しています。サーバーがゲーム全体の状態権限を持つため、永続性が必要なゲームにも適しています。
- Fusion - Client Host(ホストモード):ホストとのP2P接続が可能なため、多くの物理演算が必要なゲームに適しています。また、プレイヤーが2~4人程度のゲームにも適しています。プレイヤーがホストとなるゲームは、専用サーバーを運用するコストを抑えて、チート防止の利便性を優先したい開発者にとっては理想的な選択となります。
- Fusion - Shared(共有モード):プレイヤーが頻繁に入室/退室してもゲームプレイが妨げられないような、カジュアルゲーム・大人数のプレイヤーが参加するゲームに適しています。
推奨されるゲームジャンルはFusionのモード間で被りがあるため、開発するゲームに最適なモードを調べるためには、モード間の違いを十分に理解することが大切です。
チート対策
チートプレイヤーが野放しになっていると、ゲーム体験が台無しになりますが、残念ながらそれがオンラインゲームの現実です。チートに関しては、様々なチート対策がFusionにはデフォルトで備わっています。
- Fusion - Dedicated Server(サーバーモード):専用サーバーがゲーム全体の状態権限を持つため、チート対策は強固です。チートを試みるプレイヤーがいても、サーバーはそれを検証して防ぐことが可能で、チートを試みるクライアントを弾くこともできます。ゲームプレイでネットワーク入力とネットワークプロパティを使用した場合、スピードハックやメモリ改ざんのような、ゲームプレイの状態に影響を与えるチートは不可能になります。適切に設計されたサーバーモードで可能なチートは、エイムボット(ユーザーの入力を代行するプログラム)やウォールハック(これはインタレストマネジメントで制限できます)のみです。
- Fusion - Client Host(ホストモード):ホストプレイヤーがサーバーの役割も担うため、ホスト以外のクライアントには、サーバーモードと同等のチート対策が適用できます。しかしホストプレイヤーは、完全な情報にアクセスでき、あらゆる値を更新できるためチート可能です。
- Fusion - Shared(共有モード):各プレイヤーがオブジェクトに対する状態権限を持つため、予防策がとられていなければチートは可能です。これは、任意のネットワークプロパティの値を更新したり、任意のタイミングでRPCを送信する等を含みます。
サーバー複雑性
この観点でFusionの3つのモードを比較すると、専用サーバーを使用するサーバーモードのみが独特なモードとなります。専用サーバーのセットアップには、サーバー用にヘッドレスビルドしたゲームと、それを実行する内製またはサードパーティーのサーバーホスティングソリューションが必要です。これは、より多くの管理運用コストが発生することになります。
モバイル品質
オンラインマルチプレイヤーを備えたモバイルゲームは人気がありますが、モバイル端末の限定的な性能やワイヤレス接続のために、難易度が高い分野となっています。
- Fusion - Shared(共有モード):モバイルゲームで推奨されるモードです。高速・高性能なFusionで、P2Pではなくクラウドサーバーに接続する共有モードは、快適に動作します。また、共有モードは再シミュレーションを実行する必要がないモードになるため、多くのケースでCPU使用率を抑えられます。
- Fusion - Dedicated Server(サーバーモード):追加でサードパーティーのサーバーホスティングを行うことで、運用コストは高価になるため、高ARPUのタイトルでのみ推奨されます。
- Fusion - Client Host(ホストモード):特殊なユースケースを除き、モバイルではホストモードは推奨されません。プレイヤーの一人がサーバーの役割も担うため、その貧弱な接続の影響で、モバイル用途は難易度が高く信頼性に欠けます。モバイルゲームはプレイヤーの離脱率が高く、ホストがゲームを離脱した際には、ホストマイグレーションのための一時停止が発生します。また、モバイルのNATパンチスルー成功率は他のプラットフォームより低い(モバイルのネットワークでは許可されない)ため、接続がCloudを介してリレーされる分だけ追加の遅延が発生します。
WebGLビルド
WebGLでは、共有モードを強く推奨します。
WebGLで共有モードを使用すると、Cloudサーバーへ直接接続が確立されるため、ホスト(サーバー)モードより遅延が抑えられます。CPU使用率も抑えることができて、これはシングルスレッドのみで動作するWebGLでは重要です。
ホスト(サーバー)モードは推奨されず、デフォルトでは無効です。
サーバーモードでもホストモードでも、技術的にはWebGLビルドをサーバーにすることができますが、パフォーマンスやネットワークの制限のため推奨しません。典型的なものとして、WebGLはシングルスレッドで動作し、ページのフォーカスが外れる(バックグラウンドのタブになる)と一時停止します。これがプレイヤーなら問題ありませんが、セッションのサーバーが一時停止すると、セッション内のプレイヤー全員が影響を受けます。さらに、WebGLビルドをサーバーにした場合、WebGLビルドはP2P接続はサポートされないため、常にリレー接続となります。
WebGLでホスト(サーバー)モードを有効にするには、NetworkProjectConfig
のEnable ClientServer Modes in WebGL builds
をtrue
にします。
コストパフォーマンス
Photon製品の使用料は「同時接続ユーザー数(CCU)」と「帯域幅」の2つから成ります。CCUコストは、Fusionの3つすべてのモードで同じです。帯域幅コストは、ネットワークを介してユーザー間でどれだけのデータが通信されたのかによります。ホストモードまたは共有モードを使用する場合は、帯域幅使用量が大きな要因になることを覚えておいてください。適切に最適化されたFusionのゲームが、転送量の無料枠を超えることはありません。サーバーモードを使用する場合は、帯域幅コストはサードパーティーのサーバーのプロバイダーに依存します。Fusionの価格についてはこちらをご覧ください。
ネットワークトポロジーの違い
サーバーモード(Server Mode)
サーバーモードでは、サーバーが全てのオブジェクトに対する完全かつ独占的な状態権限を持ちます。例外はありません。
クライアントは、入力をサーバーに送信する(そしてサーバーがその入力を反映する)か、RPCを使用して変更をリクエストすることでのみ、ネットワークオブジェクトを変更することができます。
サーバーアプリケーションは、ヘッドレスモードでUnityのビルドを実行します。ビルドは、専用サーバーかクラウドサーバーでホストする必要があります。Photonでは、Fusionのサーバーアプリケーションをホストするためのサーバーは提供していません。
クライアントサイド予測
クライアントサイド予測はマルチプレイで評判の良い技術方式で、サーバーからの応答を待つことなく、クライアントが自身の入力を使って自身の動作を予測します。これによって遅延が隠蔽され、ゲームプレイが軽快になります。
Fusionのサーバーモードでは、クライアントが直接変更するネットワーク上の状態は全てローカル上の予測となり、サーバーから実際の正しいスナップショットを受信すると上書きされます。サーバーから受信した状態までロールバックして、ローカル上の(それまで予測していた)ティックまでの再シミュレーションを進める処理は、サーバーリコンシリエーション(Server Reconciliation)と呼ばれます。
それまでの予測が正確だった場合の処理はシームレスとなり、正確でなかった場合は状態が更新されます。ネットワーク上の状態とレンダリングする状態は分けられているため、新しい状態を即座に描画に反映するか、補間・誤差修正・スムージングなどを使用してビジュアルアーティファクトを軽減しながら描画します。
ホストモード(Host Mode)
ホストモードでは、ホストはサーバーとクライアントを兼用します。ホストはクライアントでもあるので、プレイヤーとして入力のポーリングやレンダリングを行います。
全般的にこのモードはサーバーモードと同等ですが、専用サーバーをホストする必要がない分だけ運用コストは安くなります。しかしこれは信頼性とのトレードオフで、悪意のあるホストのチートを防げません。
ファイアウォールやルーターの内側でホストモードを実行する場合、Photon Cloudは必要に応じてUDPホールパンチングやパケットリレーを透過的に行います。
セッションはホストが所有するため、ホストが通信を切断するとセッションは失われますが、Fusionはホストマイグレーション(Host Migration)機能によって、ホストの通信が切断された場合に新しいクライアントへホスト権限を委譲することができます。ただし、ホストモードでは(共有モードとは異なり)自動で権限の委譲は行われないので、クライアント側で特別な処理を実装する必要があります。
共有モード(Shared Mode)
共有モードでは、ネットワークオブジェクトの権限が各クライアントに分散されます。具体的には、各クライアントは自身がスポーンしたオブジェクトの状態権限を最初に持ちますが、他のクライアントに状態権限を移譲したり、任意で状態権限の取得を許可制にしたりできます。
共有モードでは、クライアントサイド予測やロールバックなどの機能を使用できません。シミュレーションは、全てのクライアントが常に同じティックレートで順方向に(ロールバックせずに)進みます。
共有モードのセッションはPhoton Cloudが所有していて、接続しているクライアントがいる限り存続します。マスタークライアントが切断されたとしても、新しいマスタークライアントが割り当てられ、前のマスタークライアントが持っていたネットワークオブジェクトの状態権限が委譲されるため、ゲームプレイが妨げられることはありません。これは前述したホストマイグレーションのメカニズムとは異なることに留意してください。
Fusionの共有モードは多くの点でPhoton Unity Networking(PUN)に似ていますが、より機能が充実し、高速で、ランタイムアロケーションのオーバーヘッドがありません。
Back to top