リアルタイムリモートデバッグ環境によるゲーム開発イテレーションの高速化【DeNA TechCon 2020 ライブ配信】

Editor's Notes

• #2: こんにちは。本セッションでは、リアルタイムリモートデバッグ環境によるゲーム開発イテレーションの高速化、という題で発表させていただきます。よろしくお願いします。
• #3: スピーカーの自己紹介です。大竹悠人といいます。2013年からDeNAでゲームクライアントの基盤開発をメインに、横断的な仕事をしています。
• #4: 今回は、Unityのモバイルゲームを対象として、ゲーム開発における実機デバッグツールの必要性と、実現したデバッグツールについてお話するのですが、特に、デバッグツールを作るための障壁とその解決策についてを重点的に話させていただきます。
• #5: スライドは速やかに公開する予定になっています。詳細についてはそちらでじっくりご確認いただけますので、この時間ではDeNAが実機デバッグツールという領域に対して、どのような問題を見いだし、どのような課題を設定し、どのような技術選択・アーキテクチャでそれを解決したのか、という方法論の部分を持ち帰って頂ければと思っています。
• #6: こちらがアジェンダになります。背景として、まず実機デバッグツールによって目指すゴールについて話していきます。
• #8: 実機デバッグの前にそもそもUnityにはEditorでのプレビュー機能があります。確認の速さで言えばこれが最速ですが、実機でしか確認できないことも多いです。これらは日頃から十分に確認できていないと、大抵の場合つらいタイミングで表面化したり、そのまま見過ごされて障害につながっていきます。
• #9: ですが、実機での確認は辛いです。アセット一つ変えるにもAssetBundleのビルドを待って、さらにダウンロードも行わなければなりませんし、プレイヤービルドも遅いです。望む状況のプレイヤーデータを作るだけでも、煩雑な操作を迫られます。自由が効くEditorでのプレビューとは、かなり隔絶した速度感での開発をいつも強いられることになります。このような環境下で確認を頻繁に行うのは、かなり辛いものがあります。
• #10: ですので、Editor Previewで出来るような速度感の確認を、実機でも出来るような環境を、ゴールとして目指す必要があります。いきなりですが、先に具体的なデバッグツールのデモからお見せしようかと思います。
• #11: お見せするのは、Unity Editorで編集中のSceneを実機でほぼリアルタイムに確認するツールのデモです。いわゆるSceneのホットリロードです。専用のSceneを実機ビルドに含めて起動しておくことで、UnityEditor上でショートカットを実行するだけでその場で実機に反映されます。
• #12: 左がUnity Editorの画面、右が実機の画面になります。まずEditorでPlaneを作って、カメラに床として映るように配置します。配置したところでUnity Editorからホットリロードを行うと、実機側にも同様に床が写ります。次に、UnityちゃんのPrefabを床に乗るようにシーンに配置します。ここでまたホットリロードを行うと、Unityちゃんが実機にも表示されます。このUnityちゃんには操作用のコンポーネントがついているので、実機ですぐに操作することができます。
• #13: いきなりデモをお見せしたわけですが、今回話していくのはこのようなデバッグツールを積極的に作れる環境作りに関してが主になります。全ての問題を解決できる都合のよいツールはありません。解決の仕方を間違えると、異なる形で問題を再生産するだけになりがちです。ツールを積極的に、容易に、誰もが作れる環境を作ることで、純粋に問題に向き合いやすい状況にしていく必要があります。
• #14: ただ、全てを解決できなくても、問題解決の手段となるツールを実装しておくことで、各々の課題解決を楽にすることができます。これには実装環境自体のモデルケースとしての意味もあります。
• #15: ここまでで、実機デバッグの重要性について、背景を話してきました。では、実機デバッグツールの実現を具体的に阻害している要因は何なのでしょうか。次に、その要因を分析していきます
• #16: この章では、実機デバッグツールにまつわる周辺環境から問題を分析し、解決するべき課題を設定するまでを説明します。
• #17: まず第一に、デバッグ用の通信経路の不安定性が挙げられます。サーバーを用意するようなフローでは、個人ごとの環境の分離や接続先管理の煩雑さが課題になります。できれば、開発用PCと実機の間に直接な通信経路を用意できると、速度の面でも利便性の面でも非常に都合が良いです。
• #18: 実機との通信経路を確保しようとすると、現実的な選択肢として、USBでの接続と, WiFiでの無線を経由したTCP/IPでの接続の2パターンがあります。有線は利便性は高いのですが、制約が多く、プラットフォーム依存も激しいです。無線では制約やプラットフォーム依存が少ない一方、実装も煩雑で利便性も低いです。
• #19: 有線接続時の接続時に使えるツールとしては、Android用のadbとiOS用のlibimobiledeviceがあります。
• #20: これらを使うと、ファイルシステムへのアクセスやシステムログの表示、TCPポートフォワードが可能になりますが、これらは直接ゲームに介入するようなツールではありません。
• #21: また、問題として実機のOS毎にツールを呼び分けるのは面倒ですし、出来ることに差異や制約が多いです。
• #22: 無線でTCP/IPを用いる場合には、IPアドレスを調べないと使えなかったり、通信環境への依存が激しかったり、そもそもTCP/IPを喋るツールを万人が書くのはコストがかかりすぎるという問題があります。
• #23: このように、双方様々な問題がありますが、全て解決していいとこ取りが出来る環境を今回は目指しました。
• #24: ですので、問題をひっくり返したこれらが今回実現する環境の要件になります。
• #25: 次に、この要件を具体的に実現する環境について順番に説明していきます
• #27: 実機デバッグツールの実現を容易にする環境を作るための方針として、3つの決定をしました。まず、経路としては物理的接続の安定性と論理的接続のポータビリティを両立させるために、有線接続でTCP/IPを利用すること。次に、ツールをクロスプラットフォームで、おまけにゼロコンフィギュレーション運用できる形で提供すること。最後に、デバッグツール製作のコスト削減の為にRPCフレームワークを整備することです。
• #28: 実機デバッグツールを実現する環境の構築のために、devwireという名前のプロダクトを作りました。主な役割は有線接続時とTCP/IPを組み合わせた際に生じる問題を解決することにあります。また、RPCによるデバッグツール実装の為のヘルパーの役割も持っています。
• #29: 有線接続でTCPを使う場合、実機がサーバーになる場合とPCがサーバーになる場合の二通りがあります。基本的になにかアクションを行う主体がサーバーになり、依頼する側がクライアントにならないと、ツールの構造は非常に煩雑になってしまうので、これらを適切に使い分けられる必要があります。
• #30: 実機がサーバーになる場合は、各OSのデファクトのツールが利用できます。これらを呼び分けるだけでクロスプラットフォーム化は果たす事ができます。
• #31: これを実現するプロダクトとして、devwire.forwardを作りました。具体的な処理は各ツールに移譲していて、スーパーバイザとして振る舞う単純なものですが、devwireが規定するポートを利用する上であれば、単に起動するだけで利用できるようになっています。
• #32: これを利用した時の通信はこのようになります。実機側でListenしているポートをPC側のポートにフォワードして、そこを接続先とすることで実機上のデバッグツールのサーバーに対してPCから通信を行えます
• #33: PCがサーバーになる場合はどうでしょう。この場合は、少々問題があります。Androidであれば問題ないのですが、iOSでは実機側からPC側でlistenしているポートにフォワードすることができません。このため、プラットフォームに依らずにリバースポートフォワードを行うライブラリを実装することにしました。
• #34: これを行うのが、devwire.gatewayです。devwire.gatewayはサーバーとクライアントの2つで構成され、クライアントが踏み台になり、サーバーがその利用側になるという形のTCP over TCP Gatewayになっています。これを利用して、実機をサーバーに、PC側をクライアントにすることで、実機側からPC側への通信が可能になります。このdevwire.gateway自体の通信はdevwire.forwardでポートフォワードをする前提にしています。ポートの組み合わせは複数登録でき、コネクションも複数張れるので、gRPCに限らずTCPであれば何でも利用できます。
• #35: これを利用したときの通信はこのようになります。実機で実行するサーバーでは、予めローカルのポートと、フォワード先のホストとポートの3つをセットにして登録します。サーバー側にクライアントから接続されると、予めサーバー側で宣言したPort Z, YのListenが開始されます。このポートに接続があると、サーバーはクライアントに対してフォワード先の設定に従って接続を行うように要求します。クライアントはこの接続先に対して接続し、内部的なコネクションIDを発行します。以後、クライアントとサーバーは端末側のPort Z, Yがそれぞれのフォワード先のポートと同様に振る舞うようにデータを全て中継します。
• #36: devwire.gatewayの利点は、まず利用範囲の広さがあります。フォワード先のホストがVMやdockerであってもフォワードすることも可能で、片方向のポートフォワードができる状況下であれば両方向のポートフォワードを実現できます。また、Unity以外での利用も視野に入れて作っているので、動作するOSやプラットフォームを選びません。利便性の面でも、実機側でフォワード先を指定しておくことができるので、PC側で都度接続先の指定が必要ありません。また、ソフトウェア実装なので、ポートフォワードが成立している状態なのかをゲーム側からAPI確認することができます。
• #37: devwire.gatewayはまずPure C#で概念実証版をクイックに実装してから、C++17に移植する形をとりました。C++17で本実装したのは、Unity以外のゲームエンジンでも利用できるようにするためです。一見二度手間ですが、C++で実装した後の手戻りをかなり下げることが出来ました。本実装版は、C++17でコアを実装した上で、FFI層を作ってネイティブプラグイン化して、実機用のライブラリとPC用のコマンドラインツールのフロントエンドをC#で実装するという形をとっています。コア部分はlibuvを使ったシングルスレッドモデルで、flatbuffersをバイナリプロトコルとして利用しています。
• #38: ここまでで、有線でTCP/IPを使うための下地は整いました。しかし、devwireの利用シチュエーションを考えると、どの場合でもポート番号が被らないように運用す必要があります。このため、ポート番号の解決やgRPCサービスの管理をライブラリ化し、サーバーの種別や実行環境,独自採番の番号を与えるとポート番号を解決できるようにして、利用者やツール実装者がポート番号を直接意識しないで済むようにしています。
• #39: 有線でのTCP/IPの利用自体に問題がなくなっても、デバッグツール製作の敷居の高さの問題は残っています。あとはこれを解決する必要があります。
• #40: TCP/IPでのデバッグツール製作が難しいのは、異常系の扱いやプロトコル設計が煩雑で、プロトコルの不整合による問題も起こりがちでかつ原因究明のコストが高いことにあります。デバッグツール用途であれば、任意の処理をリモートで呼び出せれば事足りるので、RPCフレームワークの導入が解決になります。
• #41: ですが、デバッグツールにはインターフェースが静的なデバッグツールと、動的なデバッグツールの2つに分けることができると思います。前者はゲームそのものに依存しないデバッグツールが主で、例としては、ファイル転送を始めとした、ゲーム開発に共通する軸で開発を手助けするものが上げられます。後者はゲームそのものに依存するデバッグツールが主で、例としては、デバッグメニューから呼び出すような処理が挙げられます。これらの2つの種類のデバッグツールに、それぞれ適切なRPCフレームワークを用意する必要があります。
• #42: まず、インターフェースが静的なデバッグツール向けのRPCについてです。
• #43: 要求としては、3点あります。まず、呼び出し側の実装言語に制約を設けないポータビリティがあること。これはゲームに依存しない汎用デバッグツールは、呼び出し元が人間ではなく、別のツールであることも多いからです。次に後方互換性のあり、自由度の高い型定義が可能なこと。後方互換性が担保されていないと、ツール間の依存が激しくなってしまいますし、複雑な構造を受け渡せないとRPCのための実装コストがかさんでしまいます。最後に、実機をサーバーとして動作すること”も”できること。これは、処理を行ったり、情報を送る主体がサーバーにならないと、その制御が非常に複雑になり、実装コストとなってしまうためです。
• #44: これらを満たす選択肢として、gRPCを選定しました。
• #45: gRPCはRPCフレームワークとしては業界標準ですし、今回求めていた要求もこのようにすべてクリアしていました。
• #46: 次に、インターフェースが動的なデバッグツール向けのRPCはどうでしょうか。
• #47: 要求は以下の3点です。実装によってインターフェースが定まること。これは処理を記述するのがゲーム開発チーム側のエンジニアになるので、実行させたい処理以外に考えるべきことは極力少なくなっている必要があります。次に、実行できるタイミングが動的に定まること。これは、それぞれの処理を受け付けられる画面が限定的であることが多いためです。最後に、フロントエンドは自動的に定まること。フロントエンドをゲーム開発チームのエンジニアに処理ごとに書かせるわけにはいきません。なので、これも実装から定まる必要があります。
• #48: これらの要求に対して、gRPCでは答えることができません。先程は利点であったことが、逆に働いてしまいます。
• #49: ですので、この領域に対しては、これらを満たすRPC機構を独自に作ることにしました。IDLを使わず、本質的に動的にメソッド定義のできるRPC機構を作り、Webの技術でデバッグメニューとしての汎用フロントエンドを作ることで、実機内でもPCでも閲覧可能なデバッグメニューを実現する、というのを目標としました。
• #50: このために作ったのが、Retweakです。RPCはHTTPサーバー機能とJSON SchemaベースのRPCによって実現しています。引数や戻り値の型情報から、JSON Schemaを自動生成しています。フロントエンドはvue.jsを使ったSingle page applicationとして実装しています。RPCから得られたJSON Schemaを元にUIを自動生成することで、個別のフロントエンド実装を不要にしています。
• #51: Retweakのデモをお見せします。左がWebブラウザの画面で、右が実機の画面です。実機とはdevwire.forwardを使って接続しています寿司増加というメニューを開いてスライドバーをいじると、実機上の寿司のパーティクルの量が増えていきます。寿司回転をいじると、寿司が回転していきます。このように、ブラウザをデバッグメニューとして使うことができます。
• #52: WebView上でもこのデバッグメニューは表示可能です。単に、WebViewで同じURLを開くだけで実現できます。
• #53: Retweakは、TweakとCallableという２つの大きな概念を軸に設計しています。Tweakは1つのデバッグ項目を構成する単位で、表示に使われる仮想パスやメタ情報と、Callabeというものをその名前とセットで複数保持します。CallableはRetweakにおけるRPCの最小単位です。引数をJSONで与えると、返り値をJSONを返す関数のように振る舞います。引数や戻り値のJSON Schemaと、元の関数に対応するシリアライザ、そして元の関数の実体で構成されます。
• #54: Callableに使うJSON Schemaは関数の実体からリフレクションでMethodInfoを得て、仮引数名と型情報から動的に生成されます。シリアライザやデシリアライザも同様に動的に生成されます。
• #55: 作られたCallableを呼び出す際には、引数をデシリアライズして、関数を呼びだし、返り値をシリアライズするという処理が内部で透過的に行われます。
• #56: Tweakは複数のCallableを保持できますが、主だったところでは値を扱うTweakの実現に利用されています。WebUIからgetterのCallabeを呼び出して初期値を取得してUIに反映し、UI上で操作した結果をsetterを呼び出すことでゲームに反映しています。
• #57: UIはJSON Schemaから生成されます。TweakがもつCallableから引数のJSON Schemaを取得し、その内容を元にフォームを自動生成しています。
• #58: Tweakにはいくつか種類があります。Commandは任意の処理を呼び出したいだけの場合に、InspectやModifyは値を読み書きしたい場合に、SliderやToggleやImageは、それぞれ最適化された汎用UIを伴う値を扱い場合に利用します。Tweakの定義は、新規に追加することも容易にできるようになっています。
• #59: 生成されるUIの一例です。単純な型から、Dictionaryなどを含む複雑な型まで幅広く扱えます。
• #60: 画像やバイナリも扱えるので、端末のスクリーンショットをとって保存することもできます。
• #61: フロントエンドはこのような構成で、タイトル側で拡張することも可能にするべく、エンジニアのみでもそれなりのUIを作れるようにしました。JSON Schemaからのフォームの自動生成はjson-editorというライブラリを用いています。かなり多彩な構造を扱うことができます。
• #62: また、フロントエンドではFirebaseも利用しています。現状ではアクセス解析を埋め込んで、デバッグメニューの使用率統計を算出できるようにしています。
• #63: HTTPサーバーのホスティングは、.NET FrameworkのHttpListenerクラスを利用しています。これだけではAPIを伴うSPAを構築するには不十分なので、簡易的なルーティングとリクエストハンドラ機構を実装しています。設定の流しこみなどもAPI経由で行い、SPAの静的コンテンツは扱いやすいように1つのzipファイルの中身を直接HTTP上にマウントできるようにしています。
• #64: デモを実現している実コードも掲載したので、気になる方は資料を後ほどご確認ください。
• #65: Retweakに利用によって、様々なメリットが得られます。まず、PCからも実機からも同じデバッグメニューを活用でき、同時にそれぞれの利点を活かすことができます。UIの実装にuGUIでなくWebのフロントエンド資産を活用できるため、UXの向上が非常に低コストで出来るようになりますし、フロントエンドのカスタマイズも柔軟に行えます。
• #66: ここまでで、有線接続でゲームとツールが自由に通信に行える環境をdevwire.forwardとdevwire.gatewayで構築し、静的なデバッグツールの構築手段としてgRPCを、動的なデバッグツールの構築手段としてRetweakを用意しました。
• #67: これにより、実機デバッグツールを実現する環境を構築することができました。続けて、汎用的に使えるデバッグツールを、少し具体的な問題に切り込んで実装していきます。
• #69: まず、仮想ファイルシステムとデバイス間ファイル転送についてです。
• #70: 実機でのイテレーションを高めようと思った時に大きな課題になるのは、モバイルゲームのダウンロードコンテンツの多さです巨大なファイルを毎回アップロードするのも手間ですし、作業者ごとの環境の分離も煩雑です。これは、実機にアセットをファイルとして直接転送できれば、非常に汎化した解決が可能になります。
• #71: 既存システムでファイル転送を行おうとすると、adbなどを使って転送することになります。この場合、アクセスできるディレクトリが限られたり、プラットフォーム毎のツールや指定するパスの使い分けが非常に煩雑になります。
• #72: これらの課題は、もちろんdevwireの利用を前提とした上で、アクセス範囲の制限回避をアプリと同じプロセス内のサービスとすることで回避し、パス表記の問題はベースディレクトリを独自に抽象化して、仮想ファイルシステム化することで解決することにしました。
• #73: そうして作ったのが、vfsです。vfsはファイルシステムの仮想化を実現し、それを生かしてファイルシステムのネットワーク共有を可能にします。ネットワーク共有を可能にした上で、それを生かしてファイル転送を実現しています。
• #74: 仮想ファイルシステムは、大きく分けてContainer、ResourcePath, Routerの3つで実現しています。Containerはあるベースディレクトリ以下のファイルシステムを抽象化し、ResourcePathがContainer以下のファイルのパスを具体的に示します。ContainerはRouterに登録されることでシステムに認識され、ゲーム側は名前に応じたContainerをRouterから利用します。
• #75: Containerは特定のディレクトリパスを基準パスとして持ちますが、実際のパスはインターフェースには現れません。vfsの中では、全てResourcePathを使って解決します。
• #76: ResourcePathはこのように、決定性の高い形で正規化されます。パスの扱いというのはOSによって大小さまざまな差があります。必ず正規化するようにすることで、この差による実装の複雑化や問題を最小化することができます。
• #77: これを活かすことで、コンテナの実際の基準パスを外部から隠蔽することができます。assetsとbannerのコンテナは全く違うベースパスを持っていますし、プラットフォーム毎にパスは異なりますが、外部からはContainer名とResourcePathだけでファイルを特定することができます。
• #78: この仮想化されたファイルシステムであるContainerをgRPC経由で公開することで、ファイル共有を可能にします。仮想化されたファイルシステムを生かして、ネットワークの向こう側のRouterやContainerを透過的に扱えるインターフェースを用意しています。これによって、リモートのファイルシステムのマウントを可能にしています
• #79: 実際の利用はこのようなイメージです。これはPC上のファイルシステムを端末にマウントする例になります。ゲーム側はRemoteContainerを経由してファイルアクセスを行いますが、RemoteContainerはgRPCを経由して、PC側で公開されているContainerからファイルをオンデマンドに取得して、端末内にそのContainerがあるかのように振る舞います。端末側のローカルファイルシステムのコンテナをPC側に公開することで、PCからのファイル転送を行うことも出来ます。
• #80: ネットワーク上で共有されるファイルには、URIにあたるものとしてVFRLというフォーマットを定義しています。これによって、任意のホストの任意のコンテナの任意のファイルを識別することができます。
• #81: VFSではファイル転送に用いるコマンドライン版のフロントエンドを用意していて、その中でもVFRLは利用されています。転送先や転送元のパスとして、VFRLを指定することができます。全てはコンテナ間の操作として実現しているので、異なる端末間でのファイルコピーなども可能です。また、コマンドラインからVFSサーバーを立ち上げることもできるようになっています。
• #82: VFSの開発にあたって、非Unityのタイトルでも要望があったため、ネイティブ版のvfsも別途実装しました。こちらは工数圧縮と技術検証を兼ねて、golangで実装を行い、cgoでC++向けのインターフェースを定義してモバイルOS向けにクロスコンパイルしました。結果としては、デバッグツール実装目的なら少なくとも十分利用可能でした。grpc-goはpure goで実装されているため、Android, iOSでも全く問題なく動作します。既存のゲーム側の依存関係に影響されずにgRPCベースのツールを導入できる、というメリットもありました。
• #83: このように、VFSによって、相手を選ばす、マウントも転送も可能で柔軟な実機ファイル転送機構を実現できました。
• #84: 次に、UnityでのScene Hot Reload機構の事例について話します。
• #85: Unity Editorで編集中のSceneを実機ですぐに確認したい、根源的な欲求です。AssetBundle化してあればファイル転送によって比較的楽に実現できますが、そうでない状況下でも概ね使えるソリューションを用意したい、という動機で実装しました。
• #86: Sceneの実機への汎用的な転送は、その場で一時的なAssetBundleを作って送り込めば実現できます。Editor側でのアクションに応じてそれを行い、実機側のホットリロードサーバーにAssetBundleを送り込むという形でこれを実現しました。
• #87: Sceneのビルドは、SBPを使っています。コードの変更はどのみちSceneの転送では反映できないので、スクリプトコンパイルの回避によってかなりの高速化が可能になります。1つのAssetBundleに入れられるSceneは1つだけなので、開いているSceneを全て個別にビルドします。Sceneから依存しているアセットも全てそれらのAssetBundleに含ませています。
• #88: 転送はdevwireを前提として、gRPCで行います。全てのバイナリと、ActiveなSceneの名前を送ります。
• #89: あとは、実機は受け取ったAssetBundleを使って、適宜Sceneを読み替えてホットリロードを行うだけで完了です。
• #90: これにより、汎用的なホットリロード環境を実現できました。Sceneの初期化処理を個別に考慮しているわけではないので、その辺の考慮は必要ですし、AssetBundle化が進んだ後は確認の精度ももちろん下がります。ですが、これらを行っている場合は単にファイル転送で同じことが可能になるので、あくまで少ない準備で、表面的な動きだけでも気軽に実機の挙動を確認できる手段として対象を絞っています。
• #91: これで汎用的なデバッグツールの実現について、一通りの説明を終えました。
• #92: 最後に、今回の発表をまとめます。
• #93: 今回達成したことで、課題解決の道具は十分に整えることができたと言えます。デバッグツールの実装環境を整え、汎用的に使えるデバッグツールを実現してその利用の実例も示すことができました。Editor Previewと同等とまでは行きませんが、その距離を近づけることには成功したかと思っています。
• #94: これからの展望としては、まだ採用タイトルは少ないので、実タイトルでの利用実績をより積み上げて需要をもっと吸い上げていきます。その上で汎用的なデバッグツールも適宜拡充して、タイトルチームがやるべきことにより向かえる環境を作り上げていきます。技術的なところでは、Blazorの活用がインハウスツールやデバッグツールの実現手段としてメリットがありそうなので、検討を進めていきます。
• #95: 以上で終わります。ご清聴、ありがとうございました。