UE4 MultiPlayer Online Deep Dive: 実践編1 (Byking様ご講演) #UE4DD
•Descargar como PPTX, PDF•
22 recomendaciones•24,963 vistas
2017年7月2日に行われたライセンシー様向けMO勉強会の資料です。実践編① (登壇者: Byking 鈴木孝司さま）
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Similar a UE4 MultiPlayer Online Deep Dive: 実践編1 (Byking様ご講演) #UE4DD
Similar a UE4 MultiPlayer Online Deep Dive: 実践編1 (Byking様ご講演) #UE4DD (20)
Más de エピック・ゲームズ・ジャパン Epic Games Japan
Más de エピック・ゲームズ・ジャパン Epic Games Japan (20)
UE4 MultiPlayer Online Deep Dive: 実践編1 (Byking様ご講演) #UE4DD
- 2. バイキングとスピーカーについて • http://byking.jp/ • 対戦型のマルチプレイアクションタイプのゲームが得意 • 近年はUE4を採用することが多いです • 本日のスピーカー • 株式会社バイキング CTO 鈴木孝司 • レンダリング・ネットワーク・サーバー・ゲームプレイ・I/O・最適化・デバッ グ・・・
- 3. はじめに • サンプルプロジェクトの作成及び確認はUE4.16を用いています • DedicatedServerの運用はUE4.12.5で行っています • 大変申し訳無いのですが、スライド中の情報は不正確だったり 場合によっては誤っている事もあると思います • ツッコミがあったら共有お願いします！ • 自分が見つけていない、より良い制御方法などもあるかと思い ますが、現状鈴木が把握している内容で紹介させて頂きます • 明確なドキュメントが不足している気がします・・・
- 4. お題目 • レプリケート • 遅延 • RepNotify • RPC • ReliableとUnreliable • RPCと帯域 • 帯域幅設定 • レプリケートとRPCの使い分け • DedicatedServer • ListenServerとの違い • Cosmetic • 遷移フロー例 • 負荷軽減
- 5. Replicate
- 6. レプリケート • サーバー上にあるアクターをクライアント上で再現するための情報伝達 • サーバー上で生まれた、AActor::bReplicatesがtrueのアクターが対象 • そのアクターのうちReplicate対象と指定されているプロパティのみが対象 • UPROPERTY(Replicated) or UPROPERTY(replicatedUsing=xxx) • 送信されるのは変更された部分のみ • デフォルトで対象になっているアクター • GameState、PlayerController、PlayerState、Pawn • 逆にレプリケートされないアクター • GameMode、AIController、Hud関連、GameInstanceなど • 送信間隔は、帯域幅やAActor::NetPriority、Aactor::NetUpdateFrequencyなどの 影響を踏まえて制御される • うまく扱えば与えられたネットワーク帯域を効率よく利用したコードが書けます • 遅延することはあれど、サーバー上のプロパティはいつか必ず同期される。
- 9. プライオリティについて補足 • プライオリティ値 • おおざっぱにいって 「前回送信してからの時間」＊ 「ActorNetPriority」 • 前ページのようにそのTickで送信できなかったアクターは時間が伸びてすこしず つプライオリティが上がります。 • つまり、帯域が飽和している状態続いた場合、 NetPriorityの設定によって送信間隔がかなり変わる可能性があります • 参考ソースコード • AActor::GetNetPriority • オーバーライド可能なのでタイトルに合わせて自由に実装することも可能 • FActorPriority::FActorPriority
- 11. NetPriorityデモ • 帯域飽和状態 • NetUpdateFrequencyは100固定 • 上画面がサーバーで下画面がクライアント • 「すべてのキャラクターがNetPriority=100」と 「ステージ左側のキャラクターだけNetPriority=10000」を 切り替える
- 14. NetPriorityデモ • 同じアクターでもNetPriorityの違いによってレプリケートの挙 動に差が出る • ただし、NetPriorityの制御が行われるのは帯域が飽和している 時のみ • 帯域が十分であればすべてのアクターがレプリケートされる
- 15. レプリケートまとめ • レプリケート帯域が十分にあればNetUpdateFrequencyの頻度で、 クライアントにパラメータが送信されます • 帯域が飽和するとアクターの更新間隔が悪化していく • プロパティ量や頻度について適切にコントロールする • NetPriorityは帯域が飽和しているときだけ有効な事に注意する
- 16. RepNotify
- 17. ReplicatedUsing(RepNotify) • 「クライアント上で」レプリケーションによってパラメータが変 更された時に 指定した関数を呼び出す • 変化しなかった時は呼び出されない • クライアントと同じようにサーバーでも同じ関数が呼び出された ほうが便利 • ネイティブコードでプロパティを書き換えただけの場合サーバー上では 呼び出されない • ブループリントは「あるノード」がそれを処理している 0 1 0 1 Notify呼び出し
- 21. • 値が変化したときに呼び出し • 値はレプリケートによって書き換えられる • レプリケートの間隔は設定や帯域依存 RepNotifyの仕組み
- 22. 値を素早く切り替えると RepNotifyイベントが起きない事がある。 0 1 0 1 0 0 1 0 1 0
- 23. 連続的に変化するプロパティの RepNotify消失 0 1 2 0 1 2 0 1 2 0 2 正常 消失
- 24. 連続的に変化するプロパティの RepNotifyによるレアバグ • 消失する可能性のあるRepNotifyコールバックに、クリティカル なコード (インスタンスの生成やアセットのプリローディング) などが含まれているとバグを生む • 更新間隔が長いだけであれば、 AActor::ForceNetUpdate()を呼び 出して素早くレプリケート情報を送信することで回避・軽減で きるかも • 帯域的には無駄になるが、プロパティをレプリケートしつつ ReliableMulticastRPCでさらに値を送信することも可能
- 25. RPC
- 28. ServerRPCを呼び出せるアクター • クライアント側 • RoleがAutonomousProxy • AutonomousProxyに設定されるのは、 PlayerControllerとそこにPossessしているPawn • 加えて、上記アクターが保持しているコンポーネントでも呼び出し可能 • サーバー側 • すべてのアクターが呼び出し可能でローカルで呼び出しが完結する
- 29. ServerRPCが正しく動作しない例 • RoleがSimurateProxyに設定されているアクターが呼び出した場 合、すべてドロップ • 例 • クライアント側のGameStateに実装されたServerRPC • サーバープロセス上だけで動作するので意味がないです。 • 自分が操作していないPawnのServerRPC • 特に警告などもないので慣れない内はハマりやすい
- 31. 何に使うのか • 主な用途はServerRPCに対する返答 • クライアント「ABC弾をターゲット(x,y,z)に向かって発射！」 • サーバー「あなたは今動作出来ない状態なので弾が出せません！」 • クライアントからの要求を受けたが、ワールドに対して影響を与える必要が無く、 リクエスト送信者に対してだけなにかを返答を行いたいときに使います。
- 32. ClientRPCを呼び出せるアクター • RemoteRoleがAutonomousProxyのアクター • PlayerControllerおよび操作対象のPawn • ServerRPCに対して対になります
- 35. Reliable • 特徴 • 呼び出した回数分「必ず」送信される • パケロス時の再送制御付き • パケットのコピーが送信者のプロセス上に保 存される
- 37. Unreliable • 特徴 • マルチキャストとそれ以外で挙動がちょっと違う • ClientとServer • 呼び出し回数分リクエストが送信される • 再送制御が無いので、パケットロストした場合は失われる • Multicast • これだけ挙動が違っていて、RPCリクエストは一旦バッファに蓄積されて、 アクターのレプリケート時に一緒に送信される • つまり送信が遅延する • バッファに蓄積された「同じRPC」が一定数を超えた場合、 送信すらされずに破棄される • 送信回数はパケロスが無かったとしても、保証されません
- 38. RPCと帯域
- 46. 枠を増やすしかない！
- 47. 帯域幅設定 ***Engine.ini の ConfiguredInternetSpeed 各クライアントに対して 12345 byte/secの制限 12K * 4 client = 49KByte/sec 現在の帯域幅値表示 Displayall Player CurrentNetSpeed
- 48. ConfiguredInternetSpeed 以外の帯域幅設定方法 • void APlayerController::SetNetSpeed(int32 NewSpeed); • プレイヤーコントローラー毎に個別設定が可能 • ネイティブコードからアクセスする • Max(Internet)ClinetRateで制約される • お手軽で思い通りに操作できるのでオススメ • AGameNetworkManagerを使う • Ini設定などがあるため動きそうな気がする • 試しに設定してもデフォルトでは ゲームに影響を与えない模様。 • これもネイティブコードを触る必要がありそう • 未検証。すいません • 帯域設定は サーバーからクライアント向けの設 定のみ • クライアントからはRPC送信になるので帯域制限は ない
- 53. RPCについてまとめ • 即座送信や再送制御は便利 とても頼りがいがある • 呼び出し回数については注意が必要 UnreliableMulticastRPCは間引かれたり遅延したりする Reliableは回数保証 • 引数のデータサイズに気を付ける FHitResultとかを引数にいれてはいけません • 大量に呼び出すと 通信帯域を食いつぶしてレプリケーションが断続的に動作しなくなる事がある せっかくNetPriorityやFrequencyを設定してもすべて無意味に • ターゲットに合わせて通信帯域を設定
- 56. それぞれの特徴 • ReliableMulticastRPC • とても重要でサーバー側が呼び出した回数分処理される必要があるもの • ロストしない • 即時送信 • 大量に呼び出されるとレプリケート帯域が悪化するので注意する • 信頼性が高い • UnreliableMulticastRPC • 最悪メッセージがロストする • 遅延する • 連続送信してしまったときに間引かれれる • 大量送信に対する保険 • 帯域は消費する • UnreliableClientRPC • 即時送信＆ロストを許容 • Replicate+ClientRPCで値の変化を約束しつつ、即時性を与えるという組み合わせも考えられる • Replicate • プロパティを書き換える事が必要 • いつか必ず同期する • 遅延しても良い情報はReliableMulticastRPCではなくReplicateを使うべき • 送信間隔による変化のロストや遅延が考えられる
- 57. わかりにくいのでフローチャート化
- 60. • やはりReliableMulticastRPCは便利で使いたくなる • 帯域が逼迫していなければレプリケートはほとんど遅延しない • 帯域に余裕をもたせることがとても重要！
- 62. SpawnActorの遅延 • SpawnActorで生成されたアクターはレプリケーションでクライ アントに伝達される • 空き帯域が十分でない状態でアクタを生成すると、 リモートクライアント上でのアクターの生成が遅延する。 利用可能帯域によっては生成されないことすらある。 • クライアント上の生成位置のズレなどが生まれる • 移動の軌跡を描きたいといった場合に問題が生ずる可能性がある • 初期座標などをレプリケートしてクライアント側で対処する • アクター生成をできるだけ早く処理するトリックを紹介
- 63. 最速アクター生成デモ • ボタンに反応してプレイヤーキャラクターが2つの弾を同時に 発射する • 茶色の玉はアクターを生成しただけ • 白い玉はアクターを生成し、そのアクターに対してRPCを呼ぶ • 動画前半は帯域制限なし、動画後半は帯域制限有り • 左上がListenServerで下側の2つがClientです • 帯域制限があるときに生成される玉はクライアントごとに違う
- 65. 動画 YouTube Link
- 66. DedicatedServer
- 67. DedicatedServerについて • Listenとの違い • コスト • Cosmetic • Nativeコードでの注意 • DedicatedServerの遷移フロー • パフォーマンス制御
- 68. ListenServerとの違い • 低コスト • RPCやReplicateの仕組みを使っていればネットコード自体は基本同じ • DedicatedServerはviewportが無い • ローカルのカメラも無い • AController::IsLocalController() == true のPlayerControllerが無い • グローバルIPを割り当てることができる • NAT越え不要 • 大半のプレイヤーがトラブルなく接続できる • データセンターは基幹回線網に接続されているのでpingも良い • 自律的に動く • コンソールコマンドなどで直接操作はできない • クライアントからRPCを送信して操作する • 外部のゲームサーバー管理サーバーと通信して操作する
- 69. ハードウェア資源コスト Client DedicatedServer CPU資源 あるだけ使う (250%以上) 大量のスレッド 1コアを100%として ロビー 5% バトル中 60% MaxTickRate : 60 ※Xeon E5-2698 v3 @ 2.30GHz メモリ 4GB+ 仮想メモリ(VIRT) 1.5GB 物理メモリ(RES) 0.8GB GPU 必要 不要 安価なクラウドサーバーで動作可能 軽量なゲームであれば、1コアに2プロセス以上も可能
- 70. Cosmetic • DedicatedServer上で動くべきではないブループリントノードは Cosmetic指定が適用されている • UIやサウンドなど • これらのノードはDedicatedServerでは処理がスキップされます
- 71. NativeコードでCosmetic関数 • NativeコードにはCosmeticの様な自動的にスキップ処理をおこな うような機構は無い • それぞれ IsNetMode(NM_DedicatedServer) などを用いて適切に処理する • BPコードをNativeコードに移した時にnullアクセスバグが起こりやすい • BPはnullアクセスがあっても警告のみで継続して動作する
- 74. ServerTravel時の注意 • 移動前に必要なアセットを予め読み込んでおく • トラベル時にブロック読み込みが長時間発生するとタイムアウトが発 生する可能性があるため • ちなみに最初にクライアントがサーバーに接続する際も 最低でもタイムアウトしない程度にアセットをプリロードする必要があります。 • 接続エラーや切断 • 問題が発生した場合はGameDefaultMapへ移動する • GameDefaultMapは UGameMapsSettings::SetGameDefaultMap(FString&); でオーバーライドできる
- 76. サーバーのパフォーマンス制御
- 78. パケット数制御 • 通信負荷軽減の為にPacketの数を制御したい • Packetの送信数はサーバーのTick回数×クライアント数 • IniのNetServerMaxTickRateで最大Tick回数を制限する • NetClientTicksPerSecond • 1秒間に処理するクライアント数の制限値 • ListenServerならデフォルトで有効 • Dedicatedserverで適用したい場合は、コマンドラインオプション limitclientticks を つける • MagiciansDeadでは使っていません • あまりに低い値を設定しても効果が無い • ACKパケットだけが入ったパケットが送信されるためパケット数が余り減らない。謎
- 79. レプリケーション負荷制御 • サーバーはTick毎に、レプリケート対象のアクターのプロパティを検査して変更を検出 する • アクターやレプリケート対象のプロパティが多いと、この検査コストが処理負荷として大きな比 重を占めることがある • アクター毎に適切な NetUpdateFrequency を設定する • 重要性が低いものは更新間隔を低めにしておく • 必要あればランタイム中にNetUpdateFrequencyを手動で変更してもよい • 更新したいタイミングが明示的であれば、更新間隔自体を長めに設定しておきつつ、 値のセットと同時にAActor::ForceNetUpdate()をつかってすぐさま送信しても良い • Dormancyという機能もあるらしい • 更新間隔の自動制御 • net.UseAdaptiveNetUpdateFrequency(UE4.16ではデフォルトで有効) • 更新間隔の実績値を基準として次の更新予定を設定する • 値の範囲 • AActor::MinNetUpdateFrequency(下限) ～ AActor::NetUpdateFrequency(上限)
- 80. まとめ
- 81. まとめ • RPCの使いすぎは危ない • メリットとデメリットを把握してレプリケートで十分な所はレプリ ケートを用いる • 帯域が飽和しなければレプリケートは迅速に行われることを胸に刻む • 帯域を適切に設定して効率よく使う • NetUpdateFrequencyとNetPriorityを適切にコントロールする
- 82. 謝辞&参考資料 • イラスト屋様 • バイキングスタッフ • CedricさんのUE Network解説ドキュメント http://cedric- neukirchen.net/Downloads/Compendium/UE4_Network_Compendiu m_by_Cedric_eXi_Neukirchen.pdf • 公式ドキュメント • UE4 Auswerhub
- 83. 勤務地 東京（東新宿） 勤務時間 １０：００～１８：３０ （昼休み１３：００～１４：００） 給与 固定給制月給 ※経験・能力を考慮の上、決定。 例 プログラマー 業界歴１１年 月給４５万円 プログラマー 業界未経験 月給２２万円 休日・休暇 完全週休２日制（土・日） 祝日 年末年始 有給休暇 結婚記念日 家族の誕生日 ※選考希望の方は弊社HPまでご連絡ください。 http://byking.jp/recruit/ 開発者募集中！ 世界にどデカイ爪痕を残さないか！？
- 84. ご清聴ありがとうございました！
- 87. • P2Pであれば1HOPで通信できてお手軽 • キーデータは複数フレーム分を束ねて送る • Reliableだと再送が起きた時にブロックするのでUnreliableが良い
- 88. 3人以上のルームを作りたい場合は • サーバー経由(2HOP)のメッセージのやり取りが必要になる • メッシュ型ネットワークが構成できると良いがむずかしい • やっぱりUE4を頼らずに独自実装にならざるを得ない
Notas del editor
- 本日のお題目はこのようになっております RPCレプリケートなどについて補足後、 デディケートサーバーを扱う時のTIPSというながれで話させていただこうと思います。
- まずはこれです。
- 公式ドキュメントを開くと目につく表だと思うのですが、最初見るとよくわからないこれ RPCは赤枠で囲った所の挙動が重要です。
- まずはシンプルなものから話します。 サーバーRPCです
- Autonomous オータァナァマァス
- 次にクライアントRPCです。特定のクライアントを指定して送信します。
- リライアブル
- ちなみに Lanなんとかと書いてある設定値は –lanplay コマンドライン引数に入れた時に適用されます。
- ゲームロジックに影響を与えないコンポーネント - 例えばパーティクルのようなもの - はTick単位でDedicatedServer上で動作をカットすることができます。
- おまけ