UE5.2でLyraをDedicatedServer(Linux) on WSLで動作確認する
要約
おおまかに以下の手順について記載しています。
- 前準備
UE5.2のソースをダウンロード、各種セットアップ(初期設定,Lyra自体のダウンロード,クロスコンパイル系 etc) - ビルド、クック
VisualStudio2022を使用して「Lyra Sample Game」をLinux版のDedicatedServerとしてビルドしてクック、Windowsのクライアントもビルドしてクック - 動作確認
WSL2でDedicatedServerのバイナリを実行して、Windowsのクライアントから接続確認する
基本的には公式ドキュメントの手順に従っていくだけで、記事タイトル通りの目的が達成できます。
しかし、一部Linuxビルド時の追加手順が必要だったり、WSL固有の事情等を考慮する必要があるのでそれらを補完していきます。
前準備
UE5.2のソースをダウンロード
まずはエンジンのソースコードをダウンロードする所から始めます。
以下のページの手順に従って、5.2のリリース ブランチを指定してダウンロードします。
Epic Games Launcher経由でLyraをダウンロードする
Epic Games Launcherがインストールされていない場合、まずはそちらをインストールします。
インストールが完了したら、ログイン処理(サインイン)等を行い
「マーケットプレイス」で「Lyra Starter Game」を検索し、ダウンロードします。
VisualStudioのセットアップ
「Visual Studio 2022」を利用してビルドを行う為、インストールします。
個人利用なので、Community版をインストールしていますが
既にProfessionalやEnterpriseのライセンスを所有している方は、そちらを選択してください。
インストールするワークロードや個別のコンポーネントは下記のページに記載があります。
今回はVS2022経由でLinuxのビルド(DedicatedServer)を利用したいので、これらに加えて
ワークロード「C++を使用したLinux及び埋め込み開発」も追加でインストールします。
以下が参考になります。
クロスコンパイルツールチェインをインストールする
Linuxで稼働するDedicatedServerのバイナリをビルドする為に、Clangなどのツールが含まれるツールチェインを以下URLからインストールします。
今回はUE5.2がターゲットなので「クロスコンパイル ツールチェーン」の
-v21 clang-15.0.1-basedをインストールします。
インストーラーが起動するので、インストール作業を進めます。
インストールが完了したら、確認作業の為新たにコマンドプロンプトを立ち上げて以下コマンドを実行します。
set LINUX_MULTIARCH_ROOT
結果が以下のようになっていれば、インストールが正しく完了しています。
インストールパスを変更した場合は、パスに関しては適正読み替えて下さい。
LINUX_MULTIARCH_ROOT=C:\UnrealToolchains\v21_clang-15.0.1-centos7\
WSL環境の準備
ビルドしたDedicatedServerを実行する環境となる,WSL環境を構築します。
今回は、新たに「Ubuntu-22.04」のLinuxディストリビューション環境を構築して、使用する事を前提とします。
また、バージョンに関してはWSL2を利用します。
WSL自体のインストールは、以下の手順を実行する事で可能です。
インストールが完了したらコマンドプロンプトを起動し、以下の各種手順を進めていきます。
以下コマンドでインストールできるディストリビューションを確認し、Ubuntu 22.04 LTSが存在する事を確認します。
wsl --list --online
インストールできる有効なディストリビューションの一覧を次に示します。
'wsl --install -d <Distro>' を使用してインストールします。
NAME FRIENDLY NAME
～～～～～
Ubuntu-22.04 Ubuntu 22.04 LTS
～～～～～
続いて、以下のコマンドを実行して、Ubuntu-22.04をインストールします。
wsl --install -d Ubuntu-22.04
初回インストール作業実行後、ユーザー名、パスワードを入力する必要がある為、それぞれ任意の文字列を入力して設定します。
ログインまで完了すれば、WSLの準備は完了です。
ビルド,クック
ここからVisualStudioでのビルド、エディタでの設定変更及び各種クック作業に進んでいきます。
VisualStudioでの各種構成のビルド
コマンドプロンプトでインストールしたエンジンのルートフォルダに移動し、以下の手順を実行します。
-
Setup.batを実行します。 -
GenerateProjectFiles.bat -2022を実行します - エンジンルートフォルダに
UE5.slnが作成されるので、そちらからVisualStudioを起動します。
以降はVisualStudio上の操作となります。
- まずエンジン自体をビルドする為に、以下の操作でビルドを実行します
- 構成「Development Editor」
- プラットフォーム「Win64」
- ソリューションエクスプローラーから「Engine」フォルダ以下の
UE5を選択し、右クリックでビルドを開始
- 次にエディタ起動の為に、以下の操作でビルドを実行します。
- 構成「Development Editor」
- プラットフォーム「Win64」
- ソリューションエクスプローラーから「Games」フォルダ以下の
LyraStarterGameを選択し、右クリックでビルドを開始
- クライアントをビルドする為に、以下の操作でビルドを実行します。
- 構成「Development Client」
- プラットフォーム「Win64」
- ソリューションエクスプローラーから「Games」フォルダ以下の
LyraStarterGameを選択し、右クリックでビルドを開始
- 最後にサーバーをビルドする為に、以下の操作でビルドを実行します。
- 構成「Development Server」
- プラットフォーム「Linux」
- ソリューションエクスプローラーから「Games」フォルダ以下の
LyraStarterGameを選択し、右クリックでビルドを開始
1.エンジンビルド
2.エディタビルド
3.クライアントビルド
4.サーバビルド
エディタ上での設定変更、クック
LyraStarterGameをエディタ起動する為に、VisualStudio上で以下の操作を実行します。
- 構成「Development Editor」
- プラットフォーム「Win64」
- ソリューションエクスプローラーから「Games」フォルダ以下の
LyraStarterGameを選択し、右クリックで「スタートアッププロジェクトに設定」を選択
この状態でツールバーの「ローカルWindowsデバッガー」を押下します。(ショートカットキーCtrl+F5でも起動可能です)
エディタが起動できたら、以下ページのLyra を設定するの項目に記載されている各種設定変更を行います。
Lyra を設定する
サーバーのデフォルト マップを設定する
ボット数を変更する
の作業を行ってください。
今回の手順の場合は、項目ビルドのサーバーとクライアントにあたる手順は既に、上記記載の手順で実行しているのでスキップします。
次に行うのは、クックの項目の作業になります。
今回の例では、サーバはLinuxのプラットフォームを選択しなければならない点にご注意ください
- クライアントのクック
- コンテンツ/SDK/デバイス管理「Windows」
- バイナリコンフィギュレーション「開発」
- ビルドターゲット「LyraClient」
- コンテンツ管理「コンテンツをクック処理する」を押下する
- サーバのクック
- コンテンツ/SDK/デバイス管理「Linux」
- バイナリコンフィギュレーション「開発」
- ビルドターゲット「LyraServer」
- コンテンツ管理「コンテンツをクック処理する」を押下する
クライアントのクック
サーバのクック
クック処理が完了したら、動作確認に進みます。
動作確認
最後にWSLでDedicatedServerのバイナリを起動し、そこへWindowsのクライアントから接続する事で動作確認を行います。
サーバ起動
まずサーバを起動します。
コマンドプロンプトを起動し、以下のコマンドで今回作ったwsl環境にログインします。
wsl -s Ubuntu-22.04
wsl
WSLは/mnt/(Windowsのドライブレター)というパスで、Windows側のファイルに直接アクセスできます。
以下ページを参考に、Windows側でのエンジンをインストールしたフォルダにあたるディレクトリに移動します。
該当のエンジンルートのディレクトリで、以下のコマンドを実行する事でサーバを起動します
./LyraStarterGame/Binaries/Linux/LyraServer -log
ドキュメント記載の通り、デフォルト設定ではポート「7777」で待ち受けているので、ここにWindowsのクライアントから接続にいきます。
クライアント起動、接続
Windowsのクライアントから接続にいく際、WSL側のIPアドレスを指定する必要があるので、コマンドプロンプトで以下のコマンドを実行し,IPアドレスを取得します。
wsl -- ip addr show eth0 | grep "scope global eth0" | awk '{print $2}' | awk -F '/' '{print $1}'
172.24.70.82
(環境によってIPアドレスは異なります)
上記のIPアドレスがWSLのIPアドレスになるため、クライアントの接続先IPに指定して、クライアントを起動します。
コマンドプロンプトを起動しエンジンのルートフォルダに移動し、今回の例でいうと以下のコマンドで接続できます。
LyraStarterGame\Binaries\Win64\LyraClient.exe 172.24.70.82:7777 -WINDOWED -ResX=800 -ResY=450 -WinX=100 -WinY=100
ログインが成功すると、先に起動しているサーバ側のログに以下のようなメッセージが出力されます。
[2023.05.28-04.05.19:828][607]LogNet: Join request: /ShooterMaps/Maps/L_Expanse?Name=*****-FCD*****************?SplitscreenCount=1
[2023.05.28-04.05.19:994][607]LogNet: Join succeeded: ***********
接続が確認できたら、このまま以下ページにも記載あるように2つ目のクライアントを立ち上げると、そのまま2クライアントでの動作確認が可能です。
クライアントのクック
🎉🎉🎉🎉🎉
お疲れさまでした。これで晴れて,DedicatedServerの動作確認ができました。
各種補足
以降の項目はおまけなので、興味のある方向けのものです。
補足1:ビルドに時間かかりすぎなので早くしたい!
BuildConfigurationでParallelExecutorの項目のProcessorCountMultiplierという設定値を2.0に設定すると、お使いのCPUやメモリの空き状況によってはビルド時間が早くなる可能性があります。
ParallelExecutor
～～～
ProcessorCountMultiplier
ローカル実行用のプロセッサ カウント乗数です。「1」より小さい値を指定すると、他のタスク用に CPU を予約できます。ローカル エグゼキューター (XGE 以外) を使用する場合は、各 CPU コアで単一のアクションを実行します。この値を大きくすると、多くの場合ビルド時間が少し速くなりますが、コンパイル中のコンピュータの応答性が大幅に低下する可能性があります。CPU でハイパースレッドがサポートされていない場合は、この値が無視されます。
自分の環境の例では
- [USER]/AppData/Roaming/Unreal Engine/UnrealBuildTool/BuildConfiguration.xml
の設定を以下のように設定して、ビルドを実行していました。
<?xml version="1.0" encoding="utf-8" ?>
<Configuration xmlns="https://www.unrealengine.com/BuildConfiguration">
<ParallelExecutor>
<ProcessorCountMultiplier>2.0</ProcessorCountMultiplier>
</ParallelExecutor>
</Configuration>
詳細
ビルド,クックの手順では、エンジンのビルドやクライアント、サーバのビルド処理に
大量のビルド作業が必要なので、多くの時間を有しますが
UEはビルドの処理の際に、UnrealBuildToolがビルド処理時に使用するCPUのコアの数をデフォルトで物理CPUコア数と同じ数に制限しています。
もし使用しているPCのCPUがハイパースレッディングに対応している場合は、物理コアの２倍の論理コアを使用できます。
以下のコマンドをPowerShellで実行する事で、有効になっているかどうか確認する事ができます。
#物理コアの数
Get-CimInstance -ClassName Win32_Processor | Select-Object NumberOfCores
NumberOfCores
-------------
8
#論理コアの数
Get-CimInstance -ClassName Win32_Processor | Select-Object NumberOfLogicalProcessors
NumberOfLogicalProcessors
-------------------------
16
この例だと論理コアが物理コアの２倍あるので、ハイパースレッディングが有効という事になります。
この条件かつ、十分な空きメモリ領域がまだ存在する場合は
上記のProcessorCountMultiplierを2.0に設定することで、余っている論理コアも総動員してビルドを実行する事ができるという形になります。
ただし、CPUの遊びを無くして完全にフルパワーでビルドを実行するので、当然CPUは100%に張り付き、冷却ファンは轟音をあげる事になります。
そのような状態になっても、特に問題ない状況でのみ上記の設定でビルドしてみて下さい。
会社のビルドマシンなんかは、この設定を有効にしてビルドしたほうが良いケースが多いかなと思います。
UE4向けの記事ですが、以下も参考になります。
せっかく、エンジンのソースコードを落としてきているので、実際のエンジンのソースコードの上記挙動の大まかな実装部分をちらっと覗いてみると、以下のような事が分かります。
- Engine\Source\Programs\UnrealBuildTool\Configuration\BuildConfiguration.cs
- 「MaxParallelActions」の設定値がデフォルトで0(コアとメモリをデフォルト設定で使用)
- Engine\Source\Programs\UnrealBuildTool\System\ActionGraph.cs
- メソッド「SelectExecutor」を見ると、デフォルト設定だと「ParallelExecutor」が選択される
- Engine\Source\Programs\UnrealBuildTool\Executors\ParallelExecutor.cs
- 「MemoryPerActionBytes」を見ると、デフォルト設定だと1アクション(1コア)あたり、1.5GBのメモリ容量を割り当てようとする
- 8コアなら,大体12GB, 16コアなら大体24GB程のメモリが必要になる
ビルド時にVisualStudio上の「出力:ビルド」で実際にビルド中にコアをどれだけ使っているか確認できます。
また、前回ビルド時のログが以下の箇所に出力されているかと思うので、そちらからも確認が可能です。
Engine\Programs\UnrealBuildTool\Log.txt
自分の環境で、以下の要件で双方のケースのビルド時間を比較すると、以下のようになりました。
| CPU | Intel(R) Core(TM) i7-10700K CPU @ 3.80GHz |
| RAM | 64.0 GB |
8>Determining max actions to execute in parallel (8 physical cores, 16 logical cores)
8> Executing up to 8 processes, one per physical core
8>Building 690 actions with 8 processes...
～～～(省略)
8>[690/690] WriteMetadata LyraClient.target
8>Total time in Parallel executor: 1193.15 seconds
8>Total execution time: 1422.33 seconds
========== ビルド: 成功 8、失敗 0、最新の状態 0、スキップ 0 ==========
========== ビルド は 3:19 PM に開始され、23:50.226 分 かかりました ==========
8>Determining max actions to execute in parallel (8 physical cores, 16 logical cores)
8> Requested 2 process count multiplier: limiting max parallel actions to 16
8>Building 690 actions with 16 processes..
～～～(省略)
8>[690/690] WriteMetadata LyraClient.target
8>Total time in Parallel executor: 1087.12 seconds
8>Total execution time: 1097.21 seconds
========== ビルド: 成功 8、失敗 0、最新の状態 0、スキップ 0 ==========
========== ビルド は 3:46 PM に開始され、18:24.254 分 かかりました ==========
大体1.3倍程度は早くなるかなという感じでした。
補足2:何故WSLに「localhost」で接続しないのか?
Windows10, Windows11の複数のバージョンで
WindowshoホストからWSLに対して「localhost(127.0.0.1)」に対して通信する場合に、正しくパケットが送信できていないという現象が発生している為です。
以下のGithubのissueを確認して頂くと、関連している問題が確認できるかなと思います。
今回の例だと で記載してくれているように、eth0のIPアドレスを取得してそのアドレス経由で通信する事で疎通することができたので、こちらの一時回避策を使わせて頂く形にしました。
自分の環境だと以下の構成でしたが、該当の現象が発生していました。
| エディション | Windows 10 Pro |
| バージョン | 22H2 |
| OSビルド番号 | 19045.2965 |
調べる際に、自分の環境でもテストでncコマンド(リッスンモード)を使用して、WSL内でUDPを待ち受けてWindowsからncコマンドで接続するテストを行いましたが、localhost(127.0.0.1)の時のみ接続できずという結果でした。
#WSL側
nc -u -l 8888 -v
#Windows側
#これらのケースはパケット送信してもWSL側に到達せず
nc -u -v localhost 8888
nc -u -v -n 127.0.0.1 8888
#以下は到達する(このIPアドレスは環境によって異なります)
nc -u -v -n 172.22.23.191 8888
また、同様のテストをTCPモード(-uオプションなし)で行うと
こちらはlocalhost(127.0.0.1)でも、Windows側から疎通できるという結果でした。
補足3:毎回コマンド打ってIPアドレスを確認してから、クライアントやサーバー起動するのが面倒くさい!
自分の場合は、以下のような形式のbatファイルをエンジンのルートフォルダに設置して、サーバーとクライアント2つを起動して動作確認していました。
@echo off
rem cd Engine root
pushd %~dp0
rem run server
for /f "usebackq" %%i in (`"echo %~dp0"`) do set CUR_PATH=%%i
echo CUR_PATH:%CUR_PATH%
for /f "usebackq" %%i in (`"wsl -- wslpath -u '%CUR_PATH%'"`) do set WSL_CUR_PATH=%%i
echo WSL_CUR_PATH:%WSL_CUR_PATH%
start wsl -- %WSL_CUR_PATH%/LyraStarterGame/Binaries/Linux/LyraServer -log
timeout /t 15
rem run clients
for /f "usebackq" %%i in (`"wsl -- ip addr show eth0 | grep 'scope global eth0' | awk '{print $2}' | awk -F '/' '{print $1}'"`) do set WSL_IP=%%i
echo WSL_IP:%WSL_IP%
start LyraStarterGame\Binaries\Win64\LyraClient.exe %WSL_IP%:7777 -WINDOWED -ResX=800 -ResY=450 -WinX=100 -WinY=100
start LyraStarterGame\Binaries\Win64\LyraClient.exe %WSL_IP%:7777 -WINDOWED -ResX=800 -ResY=450 -WinX=100 -WinY=550
popd
pause
参照させて頂いたURL,記事,動画
- 公式ドキュメント
- WSL関連ドキュメント
- Visual Studio IDE ドキュメント
- UE5プロジェクトをLinux向けにPackageする方法
- [UE5] Lyra のバックエンドにEOS を使ってみる + OnlineServices (Experimental) を使ってみる
- Build Unreal Engine 5 Linux Dedicated Server (or UE4) | Quick Reference
- UE4 UnrealBuildTool の設定 BuildConfiguration.xml
所感
公式ドキュメントには、元々DedicatedServerをWindowsのバイナリとして動作する方法が記載されています。
個人的にはLinuxでもDedicatedServer動かせた方が、動作させられる環境の選択肢が増えてありがたいと考えているので今回の手順を記事に残しました。
Discussion