UE4 MultiPlayer Online Deep Dive 基礎編1 -Getting Started- (historia様ご講演) #UE4DD

© historia Inc. #UE4DD
Multiplayer Online Deep Dive
- Getting Started -
historia Inc.
原龍

https://github.com/HogeTatu/UE4Plugin_WebApi

本日の Deep Dive のお題目
Multiplayer Online

Multiplayer Online (MO)
人数少人数（多くても30人程度）
プレイ時間短い（長くても60分程度）
求められるものリアルタイム性が高い（低レイテンシ）
ゲームデザイン
• アクション
• 格闘ゲーム
• FPS, TPS
• MOBA (Multiplayer Online Battle Arena)

本日の流れ
TravelingDedicated Server
RPC / Replicate
導入（オンライン機能概要）
はじめに、機能概要と Traveling 周りをヒストリアからご説明
TCP
Plugin

本日の流れ
RPC / Replicate
RPC / Replicate を中心に、バイキング様からご説明
TCP
Plugin

本日の流れ
RPC / Replicate
Dedicated Server を中心に、ソレイユ様からご説明
TCP
Plugin

http://cedric-neukirchen.net/Downloads/Compendium/UE4_Network_Compendium_by_Cedric_eXi_Neukirchen.pdf
本日の内容は Cedric ‘eXi’ Neukirchen 様の資料を参考にさせて頂いています。
こちらも合わせてご確認頂けると、理解が進むと思われます。

ネットワークモード

UE4 は Client-Server (C/S) モデル
Client 1
Server
Client 2 Client 3
ゲームプレイフローを制御

Listen Server (プレイヤーの1人がサーバーを担当)
Client 1
Server
Client 2 Client 3

Dedicated Server (専用のインスタンスがサーバーを担当)
Client 1 Client 2 Client 3 Client 4
Server

同期処理
1. Replicate (プロパティ同期)

Actor のプロパティを C/S 間で同期
C++
/** 同期するプロパティ */
UPROPERTY(Replicated)
int32 SampleProperty;
/** 同期するプロパティを ActorChannel に通知 */
void ASampleActor::GetLifetimeReplicatedProps(
TArray<FLifetimeProperty>& OutLifetimeProps) const
{
Super::GetLifetimeReplicatedProps(OutLifetimeProps);
DOREPLIFETIME(ASampleActor, SampleProperty);
}

Actor のプロパティを C/S 間で同期
Blueprint

Actor のプロパティを C/S 間で同期後、コールバック通知
C++
UPROPERTY(ReplicatedUsing=OnRep_SampleProperty)
int32 SampleProperty;
/** プロパティ同期通知コールバック */
UFUNCTION()
void OnRep_SampleProperty();
※ GetLifetimeReplicatedProps はコールバックの有無で変更なし

Actor のプロパティを C/S 間で同期後、コールバック通知
Blueprint

Actor Channel ?
 C/S 間で Actor と SubObject を同期するための通信チャンネル
 Actor のスポーン情報を持ち、レプリケートされた Actor の生成 / 破棄を管理する
 所有する FObjectReplicator がプロパティ同期と RPC を行う

Server Client
Actor
Actor Channel
Actor
Actor Channel
• プロパティの差分抽出
• リクエストされた RPC
• アクターの生成
• プロパティの反映
• RPC の実行
Actor がレプリケートされる流れ

GetLifetimeReplicatedProps の役割
 FObjectReplicator がパケットレイアウトを決めるために、
同期するプロパティを判断する際に利用される
 同期するプロパティを設定しつつ、同期される条件（≒タイミング）を
指定することも可能

Actor のプロパティを同期する条件を指定
C++
UPROPERTY(Replicated)
int32 SampleProp;
/** 同期するプロパティを ActorChannel に通知 */
void ASampleActor::GetLifetimeReplicatedProps(
TArray<FLifetimeProperty>& OutLifetimeProps) const
{
Super::GetLifetimeReplicatedProps(OutLifetimeProps);
DOREPLIFETIME_CONDITION(ASampleActor, SampleProp, COND_SkipOwner);
}

Actor のプロパティを同期する条件を指定
Blueprint

プロパティ同期条件一覧
 COND_None
常時同期（条件なし）
 COND_InitialOnly
初回同期のみ
 COND_OwnerOnly
Actor の所有者のみ
 COND_SkipOwner
Actor の所有者以外
 COND_SimulatedOnly
Role=ROLE_SimulatedProxy のみ
 COND_AutonomousOnly
Role=ROLE_AutonomousProxy のみ
 COND_SimulatedOrPhysics
Simulated もしくは bRepPhysics のみ
 COND_InitialOrOwner
初回同期もしくは Actor の所有者
 COND_Custom
条件をランタイムで変更できる ※詳しくは後述
 COND_ReplayOrOwner
リプレイ時もしくは Actor の所有者
 COND_ReplayOnly
リプレイ時のみ
 COND_SimulatedOnlyNoReplay
Simulated のみ（リプレイ時は除く）
 COND_SimulatedOrPhysicsNoReplay
Simulated もしくは bRepPhysics のみ（リプレイ時は除く）
 COND_SkipReplay
リプレイ時以外

COND_Custom
C++
/** PreReplication で同期する条件を指定 */
void ASampleActor::PreReplication(
IRepChangedPropertyTracker& ChangedPropertyTracker)
{
Super::PreReplication(ChangedPropertyTracker);
DOREPLIFETIME_ACTIVE_OVERRIDE(
ASampleActor,
SampleProp,
bReplicateSampleProp);
}

同期処理
2. RPC (Remote Procedure Call)

Multicast (Server / 全 Client で実行)
C++
/** Multicast */
UFUNCTION(NetMulticast, unreliable)
void Multicast_SampleEvent();
void ASampleActor::Multicast_SampleEvent_Implementation()
{
}

Multicast (Server / 全 Client で実行)
Blueprint

Run on Owning Client (Actor を所有する Client で実行)
C++
/** Run on Owning Client */
UFUNCTION(Client, unreliable)
void Client_SampleEvent();
void ASampleActor::Client_SampleEvent_Implementation()
{
}

Run on Owning Client (Actor を所有する Client で実行)
Blueprint

Run on Server (Server で実行)
C++
/** Run on Server */
UFUNCTION(Server, unreliable, WithValidation)
void Server_SampleEvent();
void ASampleActor::Server_SampleEvent_Implementation()
{
}
bool ASampleActor::Server_SampleEvent_Validate()
{
return true;
}

Run on Server (Server で実行)
Blueprint

WithValidation
 RPC で呼び出される関数を実行する直前に検証用の関数を実行する
 関数名は RPCFunctionName_Validate で戻り値は boolean
 戻り値で false を返すと RPC で呼び出された関数は実行されない

Reliable
 RPC は UDP で通信する都合上、パケットの欠損や順序が不定になるといった
ことが起こるため、確実に受信されてほしい処理には向いていない
 Reliable フラグを利用することで RPC 実行時に疎通確認を行い、
通信の信頼性を向上させることができる

Reliable
C++
/** Run on Server */
UFUNCTION(Client, reliable, WithValidation)
void Server_SampleEvent();
Blueprint

Actor の所有権

ここはUE4のマルチプレイを理解する上で重要な部分です
（ハマりやすい部分です）

Actor の所有権とは
 Server / Client は Actor に対して所有権を持つ
 AActor::Owner で所有権を持つかどうかを判断できる
 ただし Pawn の場合は APawn::IsLocallyControlled で判断する
 所有権の有無によって、RPCの実行が制限されるケースが存在する

RPCの実行が制限されるケース (Server で実行した場合)
Actor 所有者 Multicast Run on Server
Run on Owning
Client
Client Server / 全 Client で実行 Server で実行所有する Client で実行
Server Server / 全 Client で実行 Server で実行 Server で実行

RPCの実行が制限されるケース (Client で実行した場合)
Actor 所有者 Multicast Run on Server
Run on Owning
Client
自 Client 自 Client で実行 Server で実行自 Client で実行
他 Client 自 Client で実行実行されない自 Client で実行
Server 自 Client で実行実行されない自 Client で実行

RPC が実行されないケース – (1)
Server
Client 1 Client 2
Server が所有する Actor
RPC 呼び出し

RPC が実行されないケース – (2)
Server
Client 1 Client 2
他 Client が所有する Actor
RPC 呼び出し

なぜ所有権は必要？
所有者以外が悪意を持って
不正に Actor を操作する事への対処

所有権によるカテゴライズ
 Actor は全ての Server / Client にレプリケートされるわけではい
 Actor がどこにレプリケートされるかというカテゴライズは、
Actor のプロパティ設定を元に行われる

Client 1 Client 2
Server Only
Server
 サーバーのみに生成されるアクター
 GameMode など

Server Only
AServerOnlyActor::AServerOnlyActor()
{
// プレイヤーが持つコントロール権
Role = ROLE_Authority;
// 他プレイヤーが持つコントロール権
RemoteRole = ROLE_None;
// 同期対象フラグ
bReplicates = false;
// 所有権を持つクライアントのみに同期するフラグ
bOnlyRelevantToOwner = false;
}

Server
 サーバーと全てのクライアントに
生成されるアクター
 GameState, PlayerState など
 ほとんどのアクターはこの設定で
サーバーが生成し、レプリケートされる
Server & Client
Client 1 Client 2

AServerClientActor::AServerClientActor()
{
RemoteRole = ROLE_SimulatedProxy;
bReplicates = true;
bOnlyRelevantToOwner = false;
}
Server & Client

Server
 サーバーと所有するクライアントのみに
生成されるアクター
 PlayerController,
Possess している Pawn など
Client 1 Client 2
Server & Client (所有者)

AServerOwningClientActor::AServerOwningClientActor()
{
RemoteRole = ROLE_SimulatedProxy;
bReplicates = true;
bOnlyRelevantToOwner = true;
}
Server & Client (所有者)

OnlineSubsystem

ゲーム
OnlineSubsystem
• ログイン
• セッション管理
• マッチング
• 実績
• ランキング
• チャット
• ストア（課金）
etc...
Steam
PS4
Oculus
Google
Amazon
Facebook
プラットフォームの
APIを抽象化
各種SDK

OnlineSubsystem の設計
 各プラットフォームは機能別に定義されたインターフェースを継承したクラスを実装する
 インターフェースは IOnline[機能名] で用意されている
– ex. IOnlineAchievements
 各プラットフォームは FOnline[機能名][プラットフォーム名] で実装する
– ex. FOnlineAchievementSteam

OnlineSubsystem で機能が足りていなかった場合は？
 必要なインターフェースを継承しつつ、足りていない機能のクラスを新規作成する
 IOnlineSubsystem を継承しながら、プラットフォーム別に
FOnlineSubsystem[プラットフォーム] が実装されているので、
各機能の実装を取得する Get[機能名]Interface で追加した機能の
リファレンスを返すようにする

ここからは開発フローについて

Release
QADevelopment
ネットワーク対応ゲームの基本的なデプロイフロー
作業PC
開発サーバー
ステージング
サーバー
公開サーバー

Release
QADevelopment
作業PC
開発サーバー
ステージング
サーバー
公開サーバー
作業PC（ローカル）

ローカルでのマルチプレイプレビュー
1. PIE 起動

PIE 起動時に自動でマッチングされた状態にする
Editor Preferences
-> Level Editor
-> Play
-> Multiplayer Options
-> Auto Connect To Server
単体のレベルでマルチプレイのデバッグを行うときに有効

Auto Connect To Server の注意点
 簡易的に Server / Client の設定だけ行ってプレビューを行っている
 つまり C/S 間で正式な手続き（Control Channel でのメッセージング）
を行っていないため、レベル移動を行ってしまうと正常な結果にならない

ローカルでのマルチプレイプレビュー
2. –game オプションで起動

UE4Editor.exe に uproject を指定して
-game オプションを付けて起動すると、
Cook 無しスタンドアロン実行が可能

@echo off
set EDITOR_PATH=..EngineBinariesWin64UE4Editor.exe
set UPROJECT_NAME=MultiplayerOnlineDD.uproject
set SERVER_MAP_NAME=/Game/DeepDive/Maps/OpenUrl/OpenUrlServer
set CLIENT_MAP_NAME=/Game/DeepDive/Maps/OpenUrl/OpenUrlClient
set LAUNCH_PARAM=-game -ResX=640 -ResY=360 -WINDOWED
start %EDITOR_PATH% %UPROJECT_NAME% %SERVER_MAP_NAME% %LAUNCH_PARAM% ^
-WinX=100 -WinY=100 -log -ConsoleX=100 -ConsoleY=500
start %EDITOR_PATH% %UPROJECT_NAME% %CLIENT_MAP_NAME% %LAUNCH_PARAM% ^
-WinX=800 -WinY=100
exit
起動バッチを作ると便利

PIE 起動でのプレビューはあくまで単一プロセスでの実行で
ダミー的に処理されている部分があるため、
デプロイ前には一度デバッグしておいた方が良い

パケットシミュレーション

ローカルプレビューではパケットの遅延等が全く発生せず、
実際にマシン間で通信する際に
意図した挙動にならないといった事が起こりえます

ローカルプレビュー時にこのような状態を再現するため、
エミュレート用の各種デバッグコマンドが用意されています

Net PktLoss=[Int]
 確率でパケットを送信しない（消失シミュレーション）
 単位は 0 – 100 %

Net PktOrder=[Boolean]
 パケットをバッファリングして送信順序をランダムにする
 単位は 0 – 1

Net PktLag=[Int]
 パケット送信時に遅延を発生させる（固定値）
 単位はミリ秒

Net PktLagVariance=[Int]
 パケット送信時に遅延を発生させる（範囲ランダム値）
 単位は ± ミリ秒

B.SendTime = FPlatformTime::Seconds() +
(double(PacketSimulationSettings.PktLag) + 2.0f *
(FMath::FRand() - 0.5f) *
double(PacketSimulationSettings.PktLagVariance))/ 1000.f;

Net PktDup=[Int]
 パケット送信時に確率で2回送信する（重複させる）
 単位は 0 – 100 %

この辺の実装は UNetConnection::FlushNet

RPC のデバッグ

net.RPC.Debug [Boolean]
RPC 実行時のログを Warning で出力する
有効にした状態で LogNet でフィルターを設定すると
Traveling や Replicate の流れがよく見える

ネットワークプロファイラ

 Replication, RPC に関するプロファイラ
 帯域のボトルネックを調査する時に有用
 Actor / Property / RPC でフィルタリングすることも可能

 netprofile enable/disable でプロファイリング状態を切り替える
 プロファイリング結果を確認するためには下記パスからツールを起動する
– /Engine/Binaries/DotNET/NetworkProfiler.exe
 プロファイリング結果は下記ディレクトリに保存されている
– /ProjectRoot/Saved/Profiling

https://docs.unrealengine.com/latest/JPN/Gameplay/Tools/NetworkProfiler/index.html

Release
QADevelopment
作業PC
開発サーバー
ステージング
サーバー
公開サーバー
開発サーバー

パッケージ生成

UE4 Solution
UE4 Project
Game Project
UE4 では同一プロジェクトから各種パッケージを生成
• Windows Client
• Windows Server
• PS4 Client
• Linux Server
etc ...

Build Configuration
ビルド名ビルド概要ビルドルールを指定するファイル
[empty] スタンドアロンゲーム実行用のビルド ProjectName.Target.cs
Editor エディタ実行用のビルド ProjectNameEditor.Target.cs
Client マルチプレイゲームにおけるクライアント用のビルド ProjectNameClient.Target.cs
Server マルチプレイゲームにおけるサーバー用のビルド ProjectNameServer.Target.cs

ビルドジョブセットからまとめて各種ビルドを実行する
Batch Builder (UnrealVS 拡張) が便利

Batch Builder はこのボタンから起動する

https://docs.unrealengine.com/latest/JPN/Programming/Development/VisualStudioSetup/UnrealVS/index.html

Client / Server ビルドで謎のコンパイルエラーが…？
Client / Server ビルドは、ランチャーからインストールしたエンジンだとビルドできない仕様
（ProjectName.sln ではなく、UE4.sln からのみビルド可能）

Cook は ProjectLauncher から行うと
複数パッケージを同時に生成できる

Linux クロスコンパイル

• Linux Server ビルド
• サーバー上でテスト
• エディタで開発
• Windows Client ビルド
• Windows Server ビルド
• ローカルテスト
Linux クロスコンパイル未使用時
Windows
開発マシン
Linux
開発サーバー
デプロイ

• サーバー上でテスト
• エディタで開発
Linux クロスコンパイル未使用時
Windows
開発マシン
Linux
開発サーバー
デプロイ
ビルドエラーで手戻りの可能性！

• サーバー上でテスト• エディタで開発
Linux クロスコンパイル使用時
Windows
開発マシン
Linux
開発サーバー
デプロイ
デプロイ先でのエラーを防ぐ

https://docs.unrealengine.com/latest/JPN/Platforms/Linux/GettingStarted/index.html

Linux クロスコンパイル時の注意点
 基本的には使用するUE4のバージョンに合わせたツールチェーンのダウンロードと、
環境変数の設定のみ
 複数のUE4プロジェクトが混在していて環境変数を汚染したくない場合、
LINUX_MULTIARCH_ROOT を検索して置き換えることで対応は可能
(DedicatedServer を選択する以上、自ずとエンジンはソースコードビルドになるので・・・)

まとめ
 MO ゲーム制作のための機能は一通り揃っている印象
 ただしブラックボックスな部分が多く、実はできるのに知られていない機能や
ini 設定、コンソールコマンドが用意されていたりする
 実際の運用時には NetworkProfiler で細かく使用帯域を見ていく必要がある

UE4 MultiPlayer Online Deep Dive 基礎編1 -Getting Started- (historia様ご講演) #UE4DD

More Related Content

What's hot (20)

Viewers also liked (13)

Similar to UE4 MultiPlayer Online Deep Dive 基礎編1 -Getting Started- (historia様ご講演) #UE4DD (20)

More from エピック・ゲームズ・ジャパン Epic Games Japan (20)

UE4 MultiPlayer Online Deep Dive 基礎編1 -Getting Started- (historia様ご講演) #UE4DD