UE4のNetwork Profilerさわりまで

※導入+αです

最近も4.17がリリースされのりにのってるゲームエンジン界隈もといUnrealEngineですが、ここ数ヶ月ネットワーク絡みのマルチプレイゲームを作ってるお陰もありNetwork Profiler機能を使ってみました。

docs.unrealengine.com

モチベーションはシンプルにパフォーマンス改善につながれば良いですし、自分の開発しているゲームがどれだけのネットワークIOがありそうなものか指標として知るのは大事ですねというところです。導入自体は公式ドキュメントの通りなので特になにもありません。今回は簡潔なサンプルでどういう数値が出て来るか見てみたいと思います。

準備

適当に挙動が見たいのでデフォの人型Pawnを使います。AnimStarterPackにあるUe4ASP_Characterをそのまま流用して、入力部分はキーボードで動かせるようによしなに調整。

何もない空間にAnimationStarterPackのHumanを2窓で2人出現させてみます。Replicationの設定は基本特に変更せずローカルなので特段何もなくきれいな感じです。この段階でCrouchingが同期されてないようでしたが今回はスルーです。

実践

ひとまず何も考えずプロファイリングします。公式通りに netprofile enable と netprofile disable で適当な期間実行してログファイルが生成されたらNetworkProfiler.exeで開きます。

パラメータ自体はたくさん出力されていて便利そうですが実際どのあたりを見るといいんでしょうか…ゲームのほうを変えてみます。ホストからはスポーンと同時に各クライアントでプリントするような雑なRPC呼び出しをやります。これでいくらかプロファイル内容が変わると変化が出るので嬉しいですね。

グラフの前にこれまた一例としてOutgoing Bandwidth Bytes/s、Game Socket Send Bytes/s でフィルタして、1回目と定期的にRPC呼び出しした2回目を貼ってみます。

ざっくりですが双方とも帯域幅2kくらいオーダーが上がってる感じしますかね。個々のアクターのRPC呼び出し等細かいこともできるぽいのでもっと突っ込んでいくともう少しはネットワークがボトルネックになる場合の検証ができそうです。数値を視覚化することはできますが、実際改善に結び付けるのは大変そうな感じもしました。

まとめ

UE4のネットワーク回りはより効率的なReplicationの設定やRPC呼び出しの参考設計が足りず、自分の場合どうしても力押しで完成させる部分がでてきてしまいました。リッチなエフェクトや表現が作りやすい分ゲームとしてのボトルネックはそちら側である場合が多いかもしれませんが、特にネットワーク通信がゲームの肝になる場合は今回のようにきっちりした数値をとって検証、考察していくことが大事だと感じます。

UE4は用意されてる機能が多岐にわたるため裏の動作もよくわからず行った今回の数値も信憑性は微妙かもしれません。サンプルプロジェクトのMultiplayerShootoutと同様の状態で、ホストをlisten状態にして実際に接続するような形だとまた異なる結果がでるかもしれません。ですが、試行錯誤の手段が増えるという事で効果的に利用していけるとよいかと思います。

Anker SoundCore miniが良い

Amazonタイムセールだったので衝動で購入。

Anker | SoundCore mini | Black

特に最近はSteamでゲームやるときPCに直接イヤホン繋いで音聞いてたんですが、たまにそのコードが必要以上に気になるタイミングがありました。コストはかけたくないし大層な音響システムがほしいでもない、加えてヘッドフォンで聞きたいでもないのでスピーカーだと装着しないし良いかも、が、安くてもまっとうに聞けそうな悪くない、強いて言えばオシャレなスピーカーが欲しかったのです。

届いたらまじかというくらいコンパクト。クリスタルガイザーと一緒に撮影。

小さいは正義というわけです。肝心の音はというと全く問題ないといいますか、この価格帯でそもそも音質の話をするのは違うわけです。ですがサイズoverな重量感がありなぜか良い音が聞けています。しれっとパッシブサブウーファーがついてるらしいです。

主にPCからミニジャックで繋いで流していますが、割りと頻繁にiPhoneからBluetooth接続で聞いたりもします。音の差はないのでいいように使えています。これでバッテリー駆動で持ち運べ、あわよくばFMも聞けるわけなので、君たちこういうのがあったら良いでしょという消費者に対しての目のつけどころが上手だと感じます。

Unite2017Tokyoに参加しました

大規模で聴講メインになるカンファレンスみたいなのは、どうしても現実問題眠くなったり実地で手を動かさないおかげだったり必要に駆られて得んとする知識でなかったりと諸々によりあまり参加意義を感じてないのですが、今回はなんかUnity直近触ってないけどふらっと行きました。ので参加した一部の早送り感想と雑書き残し。

unite.unity.com

events.unity3d.jp

基調講演

何年か前からユニティ・テクノロジーズ・ジャパンの大前さん（よく出られてて有名ですね）によるキーノート。Unity5系からの機能進化等ザクッと紹介されてました。ちょっと前までUnity4か？5か？みたいな話が巷で聞こえたりしてた気がするので光陰矢のごとし。昨今のVRやNintendo Switch含めて対応プラットフォームたくさんあるのは魅力ですね。教育はじめUnityの訓練も推し進めてる感じということでこういった理念を打ち出して実行していくのは言うは易く行うは難しということで素晴らしいなと思いました。あとUnity Connectも未定だけど利用するかもしれない。

直近Unreal Engineでライティングやエフェクト等本来アートで専任の人がほしい所まで手出してることもあり、ライティングに関しての説明は身近に感じられた。Light Explorerみたいなものは実際あれば必ず開くだろうなーくらい欲しいものだしより、他ライト周りもゲームのパフォーマンスや開発効率に割りと直結してくるとこで良いなと。NavMeshも機能的に気が利くような感じになってきてるぽくて、これが実際安定動作するのならばこれまた良いなと。Unreal Engineでほぼ同様なNavMesh周りを触っていたけど、自分の環境だとどうにも動作不安定さがあるので渋い印象があるけれどもUnityならば、みたいな期待を持たざるを得ない感じに。TimeLineは社のデザイナーの人も食いついてたし確かにタイムラインで視覚的に作業をすすめる一考になるのでいいんだろうなーという印象。

しかしなんか本社から原文が送られて訳を読み上げてるような感じだった。

最適化講座

普通にC#で実装するときのtips。実際モック制作とかだとOnTransformxxxが呼ばれるコストとか気にしないわけだけど、一定規模になってくると考慮は必須だぁねと再認識できたので学習した。今後SetPositionAndRotationは正義という話になっていくのだと。GameObjectが深くネストしてるユニティちゃんでのパフォーマンステストも定量的に50%程度改善とか見えてためになった。なんていうかOptimizeGameObject必須。

IL2CPP Memory Profiler実は結構前からあるのに使えてなくて自分は一体何をやっていたんだって感じだけど、手元で試すと良いツールでした。

不要なシャドウマップ切りましょう、不要なテクスチャ解像度下げましょうといった基本だが忘れる項目で締め。

パフォーマンス向上プラクティス

英語だったのもあるけど一番よく理解できなかった気がする。IL読めという強いメッセージが発されていて、ILを読んでみるという発想がなかった自分には良い教訓になった。そして改めてスライド読むと割りと理解できるので英語力が足りない。

C#統一UniRx

実務的な視点で語られていて楽しかった。そもそもゲームクライアントからwebAPI、ソケットサーバーまですべてをC#でということでで苦労しているようだった。個人的に邪推ではあるけれども内部の方たちがC#の信念にどの程度まで賛同して業務に取り組んでるのか気になってて、割りと自分の場合で考えても興味は色んな方面に飛んでしまうほうなので、場合によっては思う所ありそうだと感じた。検証追いついてない感じのHTTP/2 & gRPCは強い気持ちを感じるけど現場は（ｒｙ UniRx、シリアライザしかりDBにしても必要で最適なソフトを開発出来るスキルを持ったCTOエンジニア実際最強という感じしかない。。。

あとスプラインが編集できるCurvyというアセットが初耳だった。

NavMeshマスター

NavMeshの新しめ機能網羅とdemoでこちらも直近UnrealEngineで消耗してたのでもし安定動作してゲーム仕様に沿うようならそれだけでも乗り換え考慮したい機能。シーンに紐付いたデータとして事前計算前提だったものがランタイムで色々触れる用になったのはとても機能進化と言わざるをえない。

シェーダ入門

入門内容を解説してた。公式や3rdパーティサンプルを弄るのが一番近道であることも同時に理解した気がする。他にも前から気になってる 実践シェーダプログラミングとかは買って読みたい。

Unity 5 実践シェーダプログラミング入門 [改訂第一版]

スマホ3Dゲームぐりぐり

サンプルプロジェクトがgithubに上がってるので昨年に引き続き激しく参考になりました。水面の反射実地でどうやるか考える機会がないな…

PSVRコンテンツ制作事例

非公開セッションに参加する方が徳がありそうということで言ってきました。が、もう少し現地でしか見れない情報がが出てくると嬉しいのですがそうでもなかったのでやや残念。

シャドウバースの開発事例

こういった実際現場で行われてる技術の紹介が一番求めてるので良かった。個人的には特にブラウザ携帯ゲーからネイティブスマホゲーに展開して行く段階で一番解がわからないのがグラフィックで、表現の幅が大きく増える割にそこをうまく広げていけるのは実際コンシューマ畑の人しかいないので、そういう人たちをうまく採用できてる会社はコンテンツの深掘りがよく出来る印象。web上がりでunityかじった人と家庭用ゲーム開発を深掘りしてきた人の語るシェーダーは違うというかそういう感想がある。
発表だけ聞くとコンテンツのために各分野研究してる感じがすごくてすごい。

NVIDIA Gameworks

anselの超高解像度キャプチャや360°シーンキャプチャは場合によっては需要がありそうだったけど一定のゲームで実際に動きますよという話ぽかったので開発においてどうこうではないのかな…
VRWorksは主にヘッドマウントへの描画の仕組みをよりVR向け改良してる感じで今後はスタンダードになっていくのかなという気が強そう。Unityはdllで組み込みの過程が紹介されてたけど、UnrealEngineにおいてはnvidia側で組み込んでビルドしたバージョンを勝手に使ってくださいって感じなのかなと思ったけど、その辺のエコシステムはまだまだ途上中ということぽい。Unityの方も確かデモが本番で問題おきてた気がする。

developer.nvidia.com

アセットバンドル

スマホネイティブ開発にUnityクライアントで関わったことないので実感はないけれども、アセットバンドル周りの紹介されてる作りは確かにざっくりという印象が前からあった。と思ったら内部でも問題視はされてるらしく改善チームが立ち上がったとのことなので今後Unity2017においてはどんどん改善していく模様。
セッションで紹介してたAsset Bundle BrowserとAsset Bundle Graph Toolは使ったことなかったのでおさえておきたい。

見える開発ららマジ

見える化大事という話だった。ステートマシンの話もそうだけど、最適ではなかろうかという実装が各社別個に実践されているというのがよくわかった気がする。現場でないと分からない苦労話とかを聞きたかったけど特になかった。
ビジュアルプログラミングに関しては確かにコードに触らないでよくなっている分エンジニア以外の人間でも触れれるようになってないと、辛さが増えそうという感想。これはUE4でブループリント前提で全て作ろうとしてる経験からすると、恐らくコードの読み書きに抵抗ない所謂エンジニアにとっては、ビジュアル化していくよりも可読性の高い実装に拘るほうが遥かに健全でいられる気がしてる。コードと見合うことで目的達成出来なくなってしまう非エンジニアがしっかり当該ビジュアル化の恩恵を預かっているなら良し、そうでなければ慣れ親しんだコードベースを離れるコストも考える方が良いのでないかというのが自分の意見。ま何事も情報はオープンにしているべきというのはある

まとめ

2日間朝一セッションから聴講したため大変疲れたけれども、Unityで物づくりしているいろんな現場や環境が垣間見えてモチベーションになった。ほとんど動画とスライドが後日公開されるということで特に参加しなくても講演が見れるようになるわけだけど、独特の雰囲気というかイベント感を楽しんで自分のやる気に変える意味では今回参加してよかったかなーと思う。