ネットワーキングの概要

マルチプレイヤー セッションでは、ゲーム ステート情報は、単一のコンピューター上にのみ存在するのではなく、インターネット接続を介して複数のマシン間でやりとりされます。プレイヤー間で情報を共有するプロセスには細心の注意を要し、いくつかの追加手順が付加されるため、マルチプレイヤー プログラミングは本質的にシングルプレイヤー ゲームのプログラミングより複雑になります。Unreal Engine には、世界で最も人気があるオンライン ゲームのいくつかを支えている堅固なネットワーキング フレームワークが備わっていて、このプロセスが簡素化されます。このページでは、マルチプレイヤー プログラミングを推進する概念の概要、およびネットワーク ゲームプレイを構築するために自由に使用できるツールについて説明します。

早期のマルチプレイヤーの計画

プロジェクトのどこかの時点でマルチプレイヤー機能が必要になる可能性がある場合は、プロジェクトの最初からマルチプレイヤーを念頭に置いてゲームプレイすべてを構築する必要があります。チームがマルチプレイヤーを作成するための追加手順を常に実装していれば、ゲームプレイを構築するプロセスにかかる手間はシングルプレイヤー ゲームとあまり変わりません。長期的に見れば、プロジェクトでチームがデバッグやサービス提供を行うことが全体として簡単になります。そして、Unreal Engine でマルチプレイヤー用にプログラミングされたゲームプレイは、シングルプレイヤーでも動作します。

それに対し、ネットワーキングなしで構築済みのコードベースをリファクタリングするには、プロジェクト全体を綿密にチェックして、ほぼすべてのゲームプレイ関数を再プログラミングする必要があり、チーム メンバーは、その時点までは当たり前だと思い込んでいたプログラミングのベスト プラクティスを学び直す必要があります。また、ネットワークの速度や安定性によって生じる技術的なボトルネックに対応する準備もできていないでしょう。

プロジェクトの終盤でネットワーキングを導入するのは、最初からネットワーキングを計画しておくより大量のリソースを必要とする厄介な作業です。したがって、プロジェクトでマルチプレイヤー機能が必要になることはないと確信している場合以外は、常に マルチプレイヤー用にプログラミングすることを強くお勧めします。

クライアント サーバー モデル

シングルプレイヤーやローカル マルチプレイヤーのゲームでは、ゲームは スタンドアローン ゲームでローカルに実行されます。プレイヤーは単一のコンピューターへの入力に接続し、すべてをそのマシン上で直接制御し、アクタ、ワールド、各プレイヤーのユーザー インターフェースなど、ゲーム内のすべてはローカル マシン上に存在します。

シングルプレイヤーやローカル マルチプレイヤーは 1 台のマシン上のみで行われます。

Unreal Engine のネットワーク マルチプレイヤー ゲームでは クライアント サーバー モデルが使用されます。ネットワーク内の 1 台のコンピューターが サーバー として機能してマルチプレイヤー ゲームのセッションをホスティングし、他のプレイヤーのコンピューターすべてが クライアント としてそのサーバーに接続します。サーバーは接続されている各クライアントとゲーム ステート情報を共有し、各クライアントが互いにやりとりする手段を提供します。

ネットワーク マルチプレイヤー ゲームは、サーバー (1) と、サーバーに接続している複数のクライアント (2) の間で行われます。サーバーはゲームプレイを処理し、クライアントはゲームをユーザーに表示します。

サーバーは、ゲームのホストとして、権限のある 唯一の真のゲーム ステートを保持します。つまり、マルチプレイヤー ゲームが実際に行われているのはサーバー上です。クライアントはそれぞれ、サーバー上で自分が所有する ポーン にゲーム内アクションを行わせるためにプロシージャ コールを送信して、Pawn のリモート コントロールを行います。ただし、サーバーがクライアントのモニターにビジュアルを直接ストリーミングするわけではありません。代わりに、サーバーはゲーム ステートに関する情報を各クライアントに レプリケート して、どのアクタが存在し、各アクタがどのように動作し、さまざまな変数がどのような値を持つかを伝えます。各クライアントは、その情報を使用して、サーバー上で起きていることと非常に近い状態をシミュレートします。

クライアントとサーバーの間の接続プロセスに関する技術的な詳細情報については、「クライアント サーバー モデル」を参照してください。

クライアント サーバーのゲームプレイの例

このモデルによってゲームプレイのプログラミング手法がどのように変わるかを、マルチプレイヤー ゲームでの 2 人のプレイヤー例で図示します。2 人のプレイヤーを プレイヤー 1 と プレイヤー 2 と呼び、プレイヤーが互いに発射物を発射するプロセスを詳しく見ていきます。

スタンドアローン ゲームでは、これらのすべてのインタラクションは同じマシン上の同じ ワールド 内で行われるため、インタラクションを理解するのもプログラミングするのも、文字どおりの意味で簡単です。たとえば、オブジェクトをスポーンするときに、すべてのプレイヤーにそれが見えるのが当然であると見なすことができます。

ネットワーク ゲームでは、これらのインタラクションは複数の異なるワールド内で行われます。サーバーにあるワールド、プレイヤー 1 のクライアントにあるワールド、プレイヤー 2 のクライアントにあるワールド、そしてそのセッションに参加している他の各クライアントのワールドがあります。それぞれ異なるマシンにある各ワールドには、ポーン、ポーンの武器、ポーンが発射する発射物のコピーがあります。ゲームは実際にはサーバーでプレイされていますが、クライアントのワールドでも同じイベントが起きているように見せる必要があります。したがって、各クライアントに情報を選択的に送信して、サーバー上のワールドの視覚的表現を作成する必要があります。

このプロセスでは、ゲームプレイの基本的インタラクション (コリジョン、移動、ダメージ) と、表面的エフェクト (ビジュアル エフェクトとサウンド) と、プレイヤー個人の情報 (HUD アップデート) の間の境界が導入されます。これらのそれぞれは、ネットワーク内の特定のマシンやマシンの組み合わせに関連しています。ただし、この情報をレプリケートするプロセスは完全に自動的に行われるわけではなく、ゲームプレイをプログラミングするときに、どの情報をどのマシンにレプリケートするかを指定する必要があります。その際の主な課題は、すべてのプレイヤーに一貫したエクスペリエンスが提供されるように、どの情報をどのようにレプリケートする必要があるかを選択すること、そして使用される帯域幅ができる限り少なくなるように、レプリケートする情報の量を最小限に抑えることです。

ネットワーキングの基本概念

このセクションでは、Unreal Engine 内でネットワーク ゲームプレイを推進する概念について詳細に説明します。マルチプレイヤー ゲームを構築するのに役立ついくつかのツールの概要についても説明し、クイック リファレンスを示します。

ネットワーク モードとサーバー タイプ

ネットワーク モード は、ネットワーク マルチプレイヤー セッションに対するコンピューターの関係を表します。ゲームの 1 つのインスタンスは、以下のいずれかまたは複数のネットワーク モードを持ちます。

リッスン サーバーでは、ゲームのコピーを持つユーザーはすべて、リッスン サーバーの開始と、同じコンピューター上でのプレイの両方を行うことができるため、ユーザーは簡単に自由にサーバーを設定することができます。リッスン サーバーがサポートされているゲームでは、サーバーの開始や参加先サーバー検索のためのゲーム内 UI が備わっていることがよくあります。ただし、リッスン サーバーをホストしているプレイヤーはそのサーバー上で直接プレイしているため、ネットワーク接続を使用してプレイする必要がある他のプレイヤーより有利であり、公正さと不正行為に関する懸念が生じます。また、サーバーとしての実行と、グラフィックやサウンドなどのプレイヤー関連システムのサポートに関連する余分な処理負荷がかかります。このような要因のため、リッスン サーバーは、競争の激しい設定のゲームや、ゲームに関連するネットワーク負荷が非常に高いゲームには適していません。ただし、少人数のプレイヤー グループで、時には協力し時には競争するマルチプレイヤー ゲームでは非常に便利です。

専用サーバーは、コストが高くなり、構成も難しくなり、ゲームに参加するプレイヤーのコンピューターとは別の、独自のネットワーク接続を備えたコンピューターが必要になります。しかし、専用サーバーに参加するすべてのプレイヤーは同じタイプの接続を使用してゲームを体験することになるため、公正さが保証されます。また、専用サーバーではグラフィックのレンダリングやローカル プレイヤーのみに関連する他のロジックは実行されないため、ゲームプレイとネットワーキングをより効率的処理できます。そのため、専用サーバーは、多数のプレイヤーを必要とするゲームや、セキュリティ、公正さ、または信頼性を確保するために高性能かつ信頼性に優れたサーバーを必要とするゲームに適しています。そのようなゲームとして、MMO、競争の激しい MOBA、ペースの速いオンライン シューティングなどがあります。

スタンドアローン ゲームは、サーバーでありクライアントでもあるため、マルチプレイヤー ゲーム用に作成されたすべてのロジックは、追加の手間をかけずにシングルプレイヤーでも機能します。

アクタのレプリケーション

レプリケーションとは、ネットワーク内の異なるマシン間でゲーム ステート情報を複製するプロセスのことです。レプリケーションが正しく設定されていれば、異なるマシンでのゲームのインスタンスが同期されます。デフォルトでは、ほとんどのアクタでレプリケーションは有効になっておらず、すべての関数はローカルに実行されます。C++ の Actor クラスの bReplicates 変数または Actor ブループリントの [Replicates (レプリケートする)] 設定を true に設定することで、指定したクラスのアクタに対してレプリケーションを有効にすることができます。

ネットワーク対応ゲームプレイの作成に最もよく使用されるレプリケーション機能を以下に示します。

作成、破壊、動きなどのよく使用されるユースケースは自動的に処理されますが、他のすべてのゲームプレイ機能は、レプリケーションを有効にしていても、デフォルトでは自動的にはレプリケートされません。どの変数とどの関数をレプリケートするかをゲームに合わせて厳密に指定する必要があります。上述のすべてのレプリケーション機能の詳細については、「アクタのレプリケーション」を参照してください。

アクタ、ポーン、およびキャラクターの以下の機能はレプリケートされません。

• スケルタル メッシュ コンポーネント と スタティック メッシュ コンポーネント
• マテリアル
• アニメーション ブループリント
• パーティクル システム
• サウンド エミッタ
• 物理オブジェクト

これらはそれぞれ、すべてのクライアント上で個別に実行されます。ただし、これらのビジュアル要素を動作させる変数がレプリケートされている場合は、すべてのクライアントが同じ情報を持つことになるため、同じ方法で近似的にシミュレートされます。

ネットワーク ロールとネットワーク権限

アクタの ネットワーク ロール によって、ネットワーク ゲーム中にどのマシンがそのアクタを制御するかが決まります。権限のある アクタが、そのアクタのステートを制御すると見なされ、そのネットワーク マルチプレイヤー セッション内の他のマシンに情報をレプリケートします。リモート プロキシ は、リモート マシン上でのそのアクタのコピーであり、権限のあるアクタからのレプリケートされた情報を受け取ります。この処理は、Local Role 変数と Remote Role 変数で追跡されていて、以下のいずれかの値を持ちます。

Unreal Engine で使用されるデフォルトのモデルは server-authoritative (サーバー主導型) であり、常にサーバーがゲーム ステートに対する権限を持っていて、情報は常にサーバーからクライアントにレプリケートされます。サーバー上のアクタの Local Role 変数の値は「Authority」であり、リモート クライアント上での対応アクタの Local Role 変数の値は「Simulated Proxy」または「Autonomous Proxy」であると想定できます。

アクタのネットワーク ロールの詳細については、「アクタの Role と Remote Role」を参照してください。

クライアントの所有権

ネットワーク ゲーム内のポーンは、特定のクライアントのマシン上の PlayerController が所有しています。ポーンがクライアントのみの関数を呼び出すと、その関数がどのマシンで呼び出されたとしても、所有しているプレイヤーのマシンのみに送られます。Owner 変数が特定のポーンに設定されているアクタは、関連付けによってそのポーンが所有するクライアントに属し、クライアントのみの関数も、その所有者のマシンに送られます。C++ で IsLocallyControlled 関数を使用するか、またはブループリントで Is Locally Controlled ノードを使用して、ポーンがそれを所有するクライアント上にあるかどうかを判断します。

コンストラクション時にはポーンにコントローラーが割り当てられていない可能性があるため、カスタム Pawn クラスの コンストラクタで IsLocallyControlled を使用しないでください。

所有権の詳細については、「アクタとアクタが所有する接続」を参照してください。

関連性と優先度

関連性 は、マルチプレイヤー ゲーム中にアクタをレプリケートする価値があるかどうかを判断するために使用されます。関連性がないと見なされたアクタは、レプリケーション時にカリングされます。そうすることによって、関連性があるアクタをより効率的にレプリケートできるように帯域幅が抑えられます。アクタがどのプレイヤーにも所有されていなくて、物理的にどのプレイヤーの近くにもない場合、そのアクタは関連性がないと見なされてレプリケートされません。関連性がないアクタはサーバー上には引き続き存在して、権限のあるゲーム ステートに影響を与えることがありますが、プレイヤーが近づくまではクライアントに情報が送信されません。IsNetRelevantFor 関数を上書きすることによって関連度を手動で制御でき、NetCullDistanceSquared プロパティを使用して、アクタが関連性があると見なされる距離を決定できます。

関連するすべてのアクタをゲームプレイの単一フレーム中にレプリケートするのに十分な帯域幅が利用できないことがあります。そのために、アクタには、どのアクタを最初にレプリケートするかを決定する 優先度 値があります。デフォルトでは、ポーンと PlayerController の NetPriority 値は「3.0」であるために、それらは優先度が最も高いアクタになりますが、基本アクタの NetPriority 値は「1.0」です。正常にレプリケートされていない時間が長いアクタほど、レプリケートされるまでは、その後のパスごとにアクタの優先度が高くなります。

アクタの関連度と優先度の詳細については、「ネットワーク優先度」を参照してください。

変数のレプリケーション

変数およびオブジェクト参照にレプリケーションを追加するには、C++ の UPROPERTY マクロで Replicated 指定子または ReplicateUsing 指定子を使用するか、またはブループリントの [Details (詳細)] パネルで [Replicated (レプリケート済み)] を指定します。権限のあるアクタで、レプリケートされた変数の値が変化すると、その情報は権限のあるアクタから、セッションに接続されているリモート プロキシに自動的に送信されます。

RepNotifies

特定の変数のレプリケートされた情報をアクタが正常に受け取ったときに応答として呼び出される RepNotify 関数を指定できます。RepNotifies は、変数がアップデートされたときにのみローカルにトリガーされるため、権限のあるアクタでの変数の変化に対応してゲームプレイのロジックをトリガーするためのオーバーヘッドが少ない方法として利用できます。この機能を利用するには、C++ の UPROPERTY マクロで ReplicatedUsing 指定子を使用するか、またはブループリントで変数の [Replication (レプリケーション)] 設定を変更します。

RepNotifies は、他のゲームプレイ機能に関係なく、レプリケートする必要がある変数に追加できて、追加のネットワーク呼び出しを作成するより帯域幅がかなり少なくなるため、RPC (レプリケートされた関数) を使用するより望ましい方法です。

リモート プロシージャ コール (RPC)

リモート プロシージャ コールは、レプリケートされた関数とも呼ばれます。RPC はどのマシンからでも呼び出すことができますが、そのネットワーク セッションに接続されている特定のマシン上で実装が実行されるように指示されます。RPC には次の 3 つのタイプがあります。

ブループリントでイベントおよび関数に同じ値を指定するには、[Details (詳細)] パネルの [Replicates (レプリケートする)] ドロップダウンで、利用可能な 3 つの値のいずれかに設定します。

C++ で関数を RPC として指定するには、UFUNCTION マクロで Server、Client、NetMulticast のいずれかの指定子を指定します。それらのコード実装では、_Implementation サフィックスを使用します。

ExampleClass.h

	//Declaration of Server RPC MyFunction.
	UFUNCTION(Server, Reliable, WithValidation)
	void MyFunction(int myInt);
Copy full snippet

//Declaration of Server RPC MyFunction. UFUNCTION(Server, Reliable, WithValidation) void MyFunction(int myInt); ExampleClass.cpp

	//Implementation of Server RPC MyFunction.
	void AExampleClass::MyFunction_Implementation(int myInt)
	{
		//Gameplay code goes here.
	}
Copy full snippet

//Implementation of Server RPC MyFunction. void AExampleClass::MyFunction_Implementation(int myInt) { //Gameplay code goes here. }

関数を RPC に指定すると、その関数にゲームプレイのロジックを記述して、他の関数と同様の方法で呼び出すことができます。RPC の詳細については、「リモート プロシージャ コール」を参照してください。

信頼性

RPC は「信頼できる」または「信頼できない」として指定する必要があります。デフォルトでは、ブループリントでの関数およびイベントは「信頼できない」と見なされます。関数を「信頼できる」に設定するには、[Details (詳細)] パネルで [Reliable (信頼できる)] 設定を true に設定します。C++ では、RPC の UFUNCTION マクロに Reliable または Unreliable のいずれかの指定子を追加して、そのステータスを Server、Client、NetMulticast のいずれかに指定します。

信頼できない RPC は、意図した送信先に届くことは保証されていませんが、信頼できる RPC より高速かつ頻繁に送信できます。信頼できない RPC は、ゲームプレイに不可欠ではない関数や、非常に頻繁に呼び出される関数に最適です。その例として、アクタの動きはフレームごとに変化する可能性があるため、信頼できない RPC を使用してレプリケートされています。

信頼できる RPC は、意図した送信先に届くことが保証されていて、正常に届くまでキューに残ったままです。信頼できる RPC は、ゲームプレイに不可欠であり、あまり頻繁に呼び出されない関数に最適です。その例として、コリジョン イベント、武器の発射の開始や終了、アクタのスポーンなどがあります。

信頼できる関数を使いすぎると、キューのオーバーフローが発生する可能性があります。そうなると、接続が強制的に切断されます。レプリケートされた関数をフレームごとに呼び出す場合は、その関数を信頼できない関数にしておく必要があります。プレイヤー入力にバインドされている信頼できる関数がある場合は、プレイヤーがその関数を呼び出すことができる頻度を制限する必要があります。

検証

WithValidation 指定子は、関数の実装に加えて、受信したその関数のデータを検証する関数が存在することを表します。この検証関数には、関与している関数と同じ署名がありますが、元の戻り値の代わりにブール値を返します。検証関数が true を返すと、RPC の Implementation の実行が許可され、false を返すと、実行が阻止されます。

ExampleClass.cpp

	//Validation of Server RPC MyFunction
	bool AExampleClass::MyFunction_Validation(int myInt)
	{
		/*
			If the value of myInt is negative, we do not want to allow MyFunction_Implementation to run.
			Therefore we only return true if myInt is greater than zero.
		*/
		return myInt >= 0;		
	}
Copy full snippet

//Validation of Server RPC MyFunction bool AExampleClass::MyFunction_Validation(int myInt) { /* If the value of myInt is negative, we do not want to allow MyFunction_Implementation to run. Therefore we only return true if myInt is greater than zero. */ return myInt >= 0; }

ヒントと参考文献

効率的で一貫性のあるマルチプレイヤー システムをゲームで実装するための基本的なガイドラインを以下に示します。

レプリケートされたアクタの基本的なチェックリスト

レプリケートされたアクタを作成するには以下の手順に従います。

• アクタの [Replicated (レプリケート済み)] 設定を true に設定します。
• レプリケートされたアクタを動かす必要がある場合は、[Replicate Movement (動きをレプリケートする)] を true に設定します。
• レプリケートされたアクタをスポーンまたは破壊する場合は、必ずサーバー上で行います。
• マシン間で共有する必要があるすべての変数がレプリケートされるように設定します。通常、これはゲームプレイに不可欠な変数に適用します。
• Unreal Engine の事前作成済みの Movement コンポーネントはレプリケーション用にビルド済みであるため、できる限りをそのコンポーネントを使用します。
• サーバーが権限を持つモデルを使用している場合は、プレイヤーが実行できるすべての新しいアクションが Server 関数によってトリガーされるようにします。

ネットワーキングのヒント

• RPC およびレプリケートされたブループリント関数の使用はできる限り少なくします。代わりに RepNotify を使用できる場合は、以下のようにする必要があります。
• Multicast 関数では、セッションで接続されている各クライアントに対して余分なネットワーク トラフィックが発生するため、特に Multicast 関数は控えめに使用します。
• レプリケートされていない関数がサーバー上でのみ実行されることが保証されている場合は、サーバーのみのロジックをサーバーの RPC に含める必要はありません。
• 信頼できる RPC をプレイヤー入力にバインドする場合は慎重に行います。プレイヤーが素早く繰り返してボタンを押す可能性があり、その場合、信頼できる RPC のキューがオーバーフローすることになります。信頼できる RPC をプレイヤーがアクティベートできる頻度を何らかの方法で制限する必要があります。
• ゲームで RPC またはレプリケートされた関数を (Tick などで) 頻繁に呼び出す場合は、「信頼できない」に設定しておく必要があります。
• 一部の関数は、ゲームプレイのロジックへの応答として呼び出した後に、RepNotify への応答としてその関数を呼び出してクライアントとサーバーで並列実行されるようにすることで再利用できます。
• アクタのネットワーク ロールをチェックすると、ROLE_Authority であるかどうかを確認できます。これは、サーバーとクライアントの両方でアクティベートされる関数で実行をフィルタリングするのに便利な方法です。
• C++ で IsLocallyControlled 関数を使用するか、またはブループリントで Is Locally Controlled 関数を使用して、ポーンがローカルに制御されているかどうかを確認できます。これは、所有しているクライアントに関連しているかどうかに基づいて実行をフィルタリングするのに便利です。
• コンストラクション時にはポーンにコントローラーが割り当てられていない可能性があるため、コンストラクタ スクリプトで IsLocallyControlled を使用しないでください。

チュートリアル

上述の指針に従って単純なマルチプレイヤー ゲームを実装する方法についての詳細なウォークスルーについては、「マルチプレイヤー ゲームのプログラミング クイックスタート ガイド」を参照してください。その他のチュートリアルについては、以下のリンク先を参照してください。