Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
リアルタイムリモートデバッグ環境による
ゲーム開発イテレーションの高速化
Haruto Otake
自己紹介
大竹 悠人 (Haruto Otake)
経歴
2009~2013 dwango
2013~ DeNA
主にUnity向けの内製ライブラリやSDK開発に従事
今日話すこと
Unity製のモバイルゲームを対象として
• 実機デバッグツールの必要性と実現したデバッグツール
• 実機デバッグツールを作る障壁とその解決策について
今回の発表で持ち帰って欲しいもの
DeNAが、実機デバッグという領域に対して
どのような問題を見出したのか
どのような課題を設定したのか
どのような技術選択、アーキテクチャで課題解決をしたのか
アジェンダ
実機デバッグツールで目指すゴール
実機デバッグツールの実現を阻害する要因の分析
実機デバッグツールを実現する環境の構築
汎用的なデバッグツールの実現
実機デバッグツールで
目指すゴール
何の為に、何を目指すのか
実機デバッグの必要性
Unity EditorのPreviewは高速だが、確認の精度が落ちる
パフォーマンス問題, 改行位置, シェーダ, IL2CPP, 様々な闇…
確認を怠るとダメージコントロールが難しいタイミングで
表面化、障害に繋がる
実機デバッグは情報が少なく、イテレーションが遅い
AssetBundleビルドとダウンロードが必要
プレイヤーのビルド自体に多くの時間がかかる
プレイヤーデータの状況再現も手間がかかる
Editor Previewと隔絶した速度感であることが、...
目指す世界
Editor Preview ≒ 実機
Unity Editorで編集中のSceneを実機ですぐ確認する
UnityのSceneの実機ホットリロード
専用のSceneを実機ビルドに含めて起動させておく
Unity Editorで Alt+@ を押すと実機に反映
デモ
左がUnity Editor
右が実機画面
https://youtu.be/uZYIHR6WBnM
このようなデバッグツールを積極的に作れるようにする
一つのツールで全ての問題が解決できる訳ではない
課題設定と解決の仕方を間違えると、問題解決に至らない
ツールを積極的に、容易に、誰もが作れる環境を作る
純粋に問題に向き合いやすくなる
作りやすい環境の上で具体的なデバッグツールを実装す
る
ゲーム自体に依らない、費用対効果の高いツールを実装
単体では問題を解決せず、解決の為の道具としてみる
デバッグツール実装環境のモデルケースとしての意味も
具体的な課題解決は使い手に任せる
...
Agenda
実機デバッグツールで目指すゴール
実機デバッグツールの実現を阻害する要因の分析
実機デバッグツールを実現する環境の構築
汎用的なデバッグツールの実現
実機デバッグツールの実現を
阻害する要因の分析
実機デバッグツールの問題分析と課題設定
デバッグ用の通信経路の不安定性
配信サーバーを経由すると、利便性や速度が問題
作業者ごとの環境の分離と、それに伴う接続先管理
リアルタイム性に欠け、ホップ数が多い
開発PCと実機の直接の通信経路が必要
ファイル転送に耐える通信速度と安定性
接続...
実機との通信の現実的な選択肢
有線(USBケーブル)
利用できるツールがプラットフォーム毎に異なる
ツールが実現できることなら個別の実装は不要だが、制約が多い
接続先の特定は容易
無線(TCP/IP)
TCP/IPなので幅広いツールをプラットフ...
有線接続時のデバッグ用ツール
adb
有線, TCP/IP接続したAndroidデバイス用の開発ツール
Android SDKにバンドルされている
libimobiledevice
有線接続したiOSデバイス用の開発ツール&ライブラリ
OSS
adb, libimobiledeviceで出来ること
ゲームではなく、デバイスを制御するツール
実機内のファイルシステムへのアクセス
システムログの表示
TCPポートフォワード
ゲームへの個別の介入をするツールではない
有線接続時の問題
実機OSごとにツールチェーンが異なる
やりたいことが同じでもツールを使い分ける必要がある
iOSではReverse Port Forwardが不可
出来ることの制約が強い
OSごとに実装が必要で、セキュリティ上の制約も強い
基...
無線接続でのTCP/IP利用時の問題
実機のIPアドレスを調べるのが煩雑
IPアドレスという概念を理解していない人でも使えるべき
通信品質が環境に依存する
輻輳しやすく、アクセスポイントが近くにないと使えない
VLANがあるとアクセスポイントが...
有線, 無線両方の問題全ての解決を目指す
実機OSごとにツールチェーンが異なる
出来ることの制約が強い
実機のIPアドレスを調べるのが煩雑
通信品質が環境に依存する
デバッグツール制作のハードルが高い
有線, 無線両方の問題全ての解決をするには…
実機OSに関係なく単一のツールを用いる
出来ることの制約が少ない
実機のIPアドレスを調べる必要がない
通信品質が環境に依存しない
デバッグツール制作のハードルが低い
これらの要件を達成する必要がある
Agenda
実機デバッグツールで目指すゴール
実機デバッグツールの実現を阻害する要因の分析
実機デバッグツールを実現する環境の構築
汎用的なデバッグツールの実現
実機デバッグツールを
実現する環境の構築
方針
有線接続でTCP/IPを利用する
出来ることの制約が少ない
実機のIPアドレスを調べる必要がない
通信品質が環境に依存しない
ツールのクロスプラットフォーム/ゼロコンフィギュレーション化
実機OSに関係なく単一のツールを用いる
RPCフレ...
devwire
有線接続 + TCP/IPの組み合わせの問題を解決するツールキット
リバースポートフォワードの実現
ツールの統一
ポート番号の割り振り
RPCによるデバッグツール実装の為のヘルパー
Scaffold, サービスのブートストラップ
有線接続でのTCP/IPの利用
複数のパターンに対応できる必要がある
実機がサーバーになる場合
PCがサーバーになる場合
行動する主体をサーバー、依頼する主体をクライアントにする
実体と逆転すると複雑な制御が必要になる
実機がサーバーになる場合
各OSのツールに存在するポートフォワード機能を利用
これらを呼び分けることでクロスプラットフォーム化
devwire.forward - ポートフォワードツールのWrapper
adbやlibimobiledeviceのツールを呼び分けるWrapper
個別にプロセスを立ち上げてスーパーバイザとして振る舞う
.NET Coreで実装。Win/M...
devwire.forwardによる実機側のサーバーへのアクセス
PCがサーバーになる場合
ポートフォワードでは実機からPC上のサーバーを参照できない
リバースポートフォワードが必要
最近のAndroidならadb proxyが使えるが、iOSには存在しない
独自にリバースポートフォワードを行う
ライブラリを...
devwire.gateway
クライアントが踏み台になる形のTCP over TCP Gateway
サーバー側のローカルホストへ通信を、クライアント側から接続可能な任
意のホストにトンネリング
実機をサーバーに、PC側をクライアントにする
...
devwire.gatewayを利用したTCP/IPベースのツール利用
devwire.gatewayの利点
利用範囲が広い
クライアントから届く範囲であればどこでもフォワード可能
TCPで片方向のフォワードができていれば、逆方向にできる
相手のOSやプラットフォームを選ばない
利便性が高い
フォワード先を宣言的に...
devwire.gatewayの採用技術
PoC(概念実証)をPure C#でクイックに実装
最終的なPoCの設計を下敷きに、C++17に移植
Unity以外のゲームエンジンでも利用可能
Win / Mac / Android / iOSに対応...
devwire.bootloader
devwireの利用では利用ケースが様々ある
Editor/Preview/実機, gRPC/gRPC以外
互いに同時に走ることがありうるのでポート番号を分離
ポート番号の解決とgRPCのServiceの管...
有線でのTCP/IPでの通信が可能になったら
その上で、TCP/IPベースのデバッグツール制作の敷居を下げる
TCP/IPでのデバッグツール制作の課題
TCP/IPでのデバッグツール制作を難しくしている原因
異常系を含めた扱い
プロトコル設計
クライアント・サーバー間の不整合が起こりがち
任意の処理を任意のパラメータで呼び出し結果を取得したいだけ
RP...
デバッグツールの種別ごとに必要なものが変わる
インターフェースが静的なデバッグツール
処理内容がゲームそのものに依存しないものが主
ファイル転送/ヒエラルキー操作/ログなど、ゲーム開発に共通す
る軸で開発を手助けする汎用デバッグツール
インター...
インターフェースが静的な
デバッグツール向けのRPC
インターフェースが静的なRPCへの要求
ポータビリティ
呼び出し側のツールの実装言語に制約を設けない
後方互換性があり、自由度の高い型定義
ツール間の依存性を適切に保ちつつ、複雑な構造も受け渡したい
実機をサーバーとして動作すること”も”出来る...
gRPCの選定理由
ポータビリティ
対応言語が非常に多彩で、あり得る選択肢はほぼ網羅
後方互換性があり、自由度の高い型定義
Protobufを用いたIDLがあり、後方互換性も担保できる
実機をサーバーとして動作すること”も”出来る
Unity ...
インターフェースが動的な
デバッグツール向けのRPC
インターフェースが動的なデバッグツールのRPCへの要
求
実装によってインターフェースが定まる
処理を実装するのは主にゲーム開発チームのエンジニア
処理に合わせたインターフェースを手で定義する手間をなくす
実行できるタイミングは動的に定まる
実...
gRPCは動的なデバッグツールには向かない
実装によってインターフェースが定まる
IDLを書いてコード生成を行う必要がある
実行できるタイミングは動的に定まる
実行できない処理を表明することはできない
フロントエンドは自動的に定まる
エコシステ...
ユースケース特化の動的なRPCを実装することにした
実装によってインターフェースが定まる
実行できるタイミングは動的に定まる
IDLを使わず、任意のタイミングでC#の実装を投げ込む
フロントエンドは自動的に定まる
Webの技術でデバッグメニュー...
Retweak
HTTPサーバ + JSONSchemaベースのRPC + Webフロントエンド
実装によってインターフェースが定まる
C#のdelegateからJSON Schemaを生成してインターフェースに
実行できるタイミングは動的に定...
デモ
左がWeb Browser
右が実機画面
https://youtu.be/FmNF_sow74E
スタンドアロン利用のデモ
単純なデバッグメニューとして利用可能
WebViewでSPAを表示
https://youtu.be/ji-Ga-0Wu3Y
Retweakの設計
Tweak
一つのデバッグ項目の単位
表示位置の仮想パスや、種別毎のメタ情報を保持
複数のCallableを、その名前とセットで保持
Callable
RetweakのRPCの最小単位
引数をJSONで与えると、返り値をJ...
JSON Schemaの動的生成
Callableの実行
複数のCallableの活用
UIの生成
させたい処理に応じたTweakを定義
Command
任意の処理の実行させるTweakを生成する
Inspect / Modify
任意の値を読み書きするTweakを生成する
Slider, Toggle, Image
最適化したUIを伴う任意...
単純な型から複雑な型まで幅広く取り扱える
画像やバイナリも取り扱える
スクリーンショット
端末内データのzip化
フロントエンドの構成
vue + vuex + vue-router + bootstrap-vue
エンジニアのみでもそれなりのUIを作れるので用途に合う
自然なパーマリンクとヒストリ管理も実現
json-editor
JSON Schema...
フロントエンドの構成
Google Analytics for Firebase
アクセス解析を埋め込んでデバッグメニューの使用統計を取る
FirebaseからBigQueryへExport
Google データポータルでダッシュボードを作成
HTTPサーバーのホスティング
.NET FrameworkのHttpListenerクラスが利用可能
簡易的なHTTPルーティングとリクエストハンドラ機構を実装
Tweakを扱うAPIとSPAの静的コンテンツを同じホストで提供
SPAの静的コ...
デモの実コード
Retweakによる利点
実機でもPCでも同じデバッグメニューを使える
Bootstrapによるレスポンシブデザイン
UIの実装に豊富なフロントエンド資産を活用できる
デバッグメニューを扱う際のUXを低コストで改善できる
フロントエンドを柔軟に...
ここまでで成し遂げたこと
有線接続でゲームとツールが通信を自由に行える環境
devwire.forward + devwire.gatewayの実装
共通基盤となりえる静的なデバッグツールを作る環境
gRPCの採用
デバッグメニューにあたる処理...
Agenda
実機デバッグツールで目指すゴール
実機デバッグツールの実現を阻害する要因の分析
実機デバッグツールを実現する環境の構築
汎用的なデバッグツールの実現
汎用的なデバッグツールの実
現
Vfs
仮想ファイルシステムとデバイス間ファイル転送
モバイルゲーム開発におけるファイル転送の必要性
モバイルゲームのアセットの殆どはインストール後の事後配信
毎回アセットをアップロードが必須。サイズも巨大(GB単位)
定期的なビルドでなく、手元でのトライアンドエラーには不向き
作業者ごとの環境の...
ファイル転送ソリューションとその課題
libmobiledeviceやadb cp
アクセスできるディレクトリに強い制限がある
プラットフォーム固有のツールを使い分ける必要がある
転送時に指定するパス表記が統一されていない
既存ソリューションの課題と解決のための要件
プラットフォームのツール依存と設定の煩雑さの解決
devwireを前提としたgRPCベースのツールにすることで解決
アクセスできるディレクトリの制限の撤廃
アプリのプロセス内でサービスとして動かすこと...
vfs (Virtual File System)
ファイルシステムの仮想化とネットワーク共有を実現する
vfs.core
ファイルシステムの仮想化と、パスの正規化
vfs.remoting.core
仮想化したファイルシステムをgRPC経由で...
仮想ファイルシステムの実現
Container
基準パス以下のファイルシステムを抽象化
最低限必要なファイルシステムへの操作を行える
ResourcePath
Container配下の正規化されたファイルパス
Router
Containerに...
ディレクトリのContainerとResourcePathへの抽象化
Containerは特定のディレクトリを基準パスとして持つ
インターフェース上には実際のパスそのものは現れない
ResourcePathはContainerでは相対パスとして...
ResourcePath - 環境差を吸収するため、パスを正規化
/path/to/directory/file.unity3d
/path/to/directory/
/path/to/directory
/path/to/../to/dir...
Containerの実際の基準パスを外部から隠蔽する
Containerの外部公開によるファイル共有の実現
VfsRemotingServer / VfsRemotingClient
Routerと紐づくContainerをgRPCで外部から操作できるようにする
RemoteRouter / Re...
Containerの外部公開によるファイル共有の実現
共有されるファイルの識別
VFRL (Vfs File Resource Location)
Vfsで管理されたネットワーク上の任意のファイルを示す識別子
vfs://local@localhost:1234/dir/file.unity3d
...
コマンドライン版フロントエンド
ローカルと、任意のVFRLに対してのファイル操作を行えるCLI
全てのファイル操作はContainerに対する操作として行う
ローカルファイルはその場で一時的なContainerを作成
可能な操作
ファイル/ディ...
ネイティブ版Vfsの実装
C++タイトルでvfsを使えるように、非Unity版を開発
golangで実装、cgoでC++向けのインターフェース付きでビルド
工数圧縮 & 技術実証
少なくとも、デバッグツールでの利用には耐えられる
ランタイムが大...
柔軟な実機ファイル転送機構を実現できた
一定の手順で相手を選ばずにファイル転送できる
Unity以外からでもツールチェインを利用できる
ファイル転送という手間自体をなくすことも可能
PC側のContainerを直接ゲームから使うこともできる
ゲ...
Scene Hot Reload
UnityのSceneのホットリロードの実現
Unity Editorで編集中のSceneの内容をすぐ実機で見たい
実現の仕方は数あるが、根本的な要求は似ている
ゲーム側の準備が整えば、これ自体は難しくない
ビルド済みAssetBundleの転送で実現可能
AssetBundleの導入タイ...
Sceneそのものを実機に転送する方法
1. キーボードショートカットやメニューでクリックで実行
2. Editorで編集中のSceneを一時的なAssetBundleとしてビルド
3. ビルドしたAssetBundleをgRPCで実機に送る
...
Sceneのビルド
SceneのビルドはScriptable Build Pipelineを利用
スクリプトコンパイル結果はキャッシュしてできるだけ回避
開いているSceneを全て個別のAssetBundleとしてビルド
Sceneから依存する...
ビルドしたAssetBundleを実機に送る
Editorから実機にgRPCで接続
全SceneのAssetBundleのバイナリとActiveなSceneの名前を送信
実機で受けったAssetBundleからSceneをロード
1. 読み込み前に、読み込み済みのSceneを全てアンロード
2. 受け取ったAssetBundleを全てロード
3. AssetBundleからSceneを全てロード
4. Acti...
汎用的なホットリロード環境が実現できた
汎用的だが、常に使えるものではない
Scene初期化処理の呼び出しを行う必要はある
ゲーム側のScene管理と競合する可能性はある
ゲーム側がSceneのAssetBundle化をしているのであれば不要
...
Agenda
実機デバッグツールで目指すゴール
実機デバッグツールの実現を阻害する要因の分析
実機デバッグツールを実現する環境の構築
汎用的なデバッグツールの実現
最後に
この発表の振り返りと、これからの展望
実機デバッグのイテレーション高速化の道具は十分整った
デバッグツールの実装環境の実現
有線接続でゲームとツールが通信を自由に行える
共通/ゲーム特化なデバッグツールを気軽に作れる
汎用的なデバッグツールの実現
柔軟なファイル共有手段という問題解...
これからの展望
具体的な利用実績の積み上げ
潜在的な需要をもっと吸い上げる
汎用的なデバッグツールの拡充
タイトルチームがやるべきことだけにより向かえるように
Blazor WebAssembly, Serverの活用
ゲームコードとデバッグツ...
Thank you for listening!
Appendix
RetweakのC#動的コード実行環境
SlowSharpを用いてC#コードの動的実行を実現
Roslynで解析した構文木を動的に実行するC#インタプリタ
HTTP経由で渡されたC#コードを実行し、返り値はJSON化
Debug.Logによるロ...
リアルタイムリモートデバッグ環境によるゲーム開発イテレーションの高速化【DeNA TechCon 2020 ライブ配信】
リアルタイムリモートデバッグ環境によるゲーム開発イテレーションの高速化【DeNA TechCon 2020 ライブ配信】
リアルタイムリモートデバッグ環境によるゲーム開発イテレーションの高速化【DeNA TechCon 2020 ライブ配信】
Upcoming SlideShare
Loading in …5
×

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

913 views

Published on

本セッションでは、Unityを使った開発のイテレーション高速化を目的として、有線接続したモバイル実機のゲームに対して開発用PCからリアルタイムに介入できるツールを高い柔軟性で容易に開発できる基盤をgRPC等と独自TCPリレーサーバーを組み合わせて構築した事例と、その上に実現したファイル転送システムをはじめとした、具体的に構築した
デバッグツールの事例をご紹介します。

Published in: Technology
  • Be the first to comment

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

  1. 1. リアルタイムリモートデバッグ環境による ゲーム開発イテレーションの高速化 Haruto Otake
  2. 2. 自己紹介 大竹 悠人 (Haruto Otake) 経歴 2009~2013 dwango 2013~ DeNA 主にUnity向けの内製ライブラリやSDK開発に従事
  3. 3. 今日話すこと Unity製のモバイルゲームを対象として • 実機デバッグツールの必要性と実現したデバッグツール • 実機デバッグツールを作る障壁とその解決策について
  4. 4. 今回の発表で持ち帰って欲しいもの DeNAが、実機デバッグという領域に対して どのような問題を見出したのか どのような課題を設定したのか どのような技術選択、アーキテクチャで課題解決をしたのか
  5. 5. アジェンダ 実機デバッグツールで目指すゴール 実機デバッグツールの実現を阻害する要因の分析 実機デバッグツールを実現する環境の構築 汎用的なデバッグツールの実現
  6. 6. 実機デバッグツールで 目指すゴール 何の為に、何を目指すのか
  7. 7. 実機デバッグの必要性 Unity EditorのPreviewは高速だが、確認の精度が落ちる パフォーマンス問題, 改行位置, シェーダ, IL2CPP, 様々な闇… 確認を怠るとダメージコントロールが難しいタイミングで 表面化、障害に繋がる
  8. 8. 実機デバッグは情報が少なく、イテレーションが遅い AssetBundleビルドとダウンロードが必要 プレイヤーのビルド自体に多くの時間がかかる プレイヤーデータの状況再現も手間がかかる Editor Previewと隔絶した速度感であることが、 実機確認の精度の低下につながる
  9. 9. 目指す世界 Editor Preview ≒ 実機
  10. 10. Unity Editorで編集中のSceneを実機ですぐ確認する UnityのSceneの実機ホットリロード 専用のSceneを実機ビルドに含めて起動させておく Unity Editorで Alt+@ を押すと実機に反映
  11. 11. デモ 左がUnity Editor 右が実機画面 https://youtu.be/uZYIHR6WBnM
  12. 12. このようなデバッグツールを積極的に作れるようにする 一つのツールで全ての問題が解決できる訳ではない 課題設定と解決の仕方を間違えると、問題解決に至らない ツールを積極的に、容易に、誰もが作れる環境を作る 純粋に問題に向き合いやすくなる
  13. 13. 作りやすい環境の上で具体的なデバッグツールを実装す る ゲーム自体に依らない、費用対効果の高いツールを実装 単体では問題を解決せず、解決の為の道具としてみる デバッグツール実装環境のモデルケースとしての意味も 具体的な課題解決は使い手に任せる 大枠なユースケースは想定する
  14. 14. Agenda 実機デバッグツールで目指すゴール 実機デバッグツールの実現を阻害する要因の分析 実機デバッグツールを実現する環境の構築 汎用的なデバッグツールの実現
  15. 15. 実機デバッグツールの実現を 阻害する要因の分析 実機デバッグツールの問題分析と課題設定
  16. 16. デバッグ用の通信経路の不安定性 配信サーバーを経由すると、利便性や速度が問題 作業者ごとの環境の分離と、それに伴う接続先管理 リアルタイム性に欠け、ホップ数が多い 開発PCと実機の直接の通信経路が必要 ファイル転送に耐える通信速度と安定性 接続先という概念を考えないでも使いたい
  17. 17. 実機との通信の現実的な選択肢 有線(USBケーブル) 利用できるツールがプラットフォーム毎に異なる ツールが実現できることなら個別の実装は不要だが、制約が多い 接続先の特定は容易 無線(TCP/IP) TCP/IPなので幅広いツールをプラットフォームを区別せず使える 目的ごとに個別の実装が必要だが、制約が少ない 接続先IP,ポートの特定が煩雑
  18. 18. 有線接続時のデバッグ用ツール adb 有線, TCP/IP接続したAndroidデバイス用の開発ツール Android SDKにバンドルされている libimobiledevice 有線接続したiOSデバイス用の開発ツール&ライブラリ OSS
  19. 19. adb, libimobiledeviceで出来ること ゲームではなく、デバイスを制御するツール 実機内のファイルシステムへのアクセス システムログの表示 TCPポートフォワード ゲームへの個別の介入をするツールではない
  20. 20. 有線接続時の問題 実機OSごとにツールチェーンが異なる やりたいことが同じでもツールを使い分ける必要がある iOSではReverse Port Forwardが不可 出来ることの制約が強い OSごとに実装が必要で、セキュリティ上の制約も強い 基本的にはあるものを使うのが現実的
  21. 21. 無線接続でのTCP/IP利用時の問題 実機のIPアドレスを調べるのが煩雑 IPアドレスという概念を理解していない人でも使えるべき 通信品質が環境に依存する 輻輳しやすく、アクセスポイントが近くにないと使えない VLANがあるとアクセスポイントが同じでも疎通しない可能性 デバッグツール制作のハードルが高い 1からTCP/IPのハンドリングをするのは危険だし、見合わない程の実 装コストがかかる
  22. 22. 有線, 無線両方の問題全ての解決を目指す 実機OSごとにツールチェーンが異なる 出来ることの制約が強い 実機のIPアドレスを調べるのが煩雑 通信品質が環境に依存する デバッグツール制作のハードルが高い
  23. 23. 有線, 無線両方の問題全ての解決をするには… 実機OSに関係なく単一のツールを用いる 出来ることの制約が少ない 実機のIPアドレスを調べる必要がない 通信品質が環境に依存しない デバッグツール制作のハードルが低い これらの要件を達成する必要がある
  24. 24. Agenda 実機デバッグツールで目指すゴール 実機デバッグツールの実現を阻害する要因の分析 実機デバッグツールを実現する環境の構築 汎用的なデバッグツールの実現
  25. 25. 実機デバッグツールを 実現する環境の構築
  26. 26. 方針 有線接続でTCP/IPを利用する 出来ることの制約が少ない 実機のIPアドレスを調べる必要がない 通信品質が環境に依存しない ツールのクロスプラットフォーム/ゼロコンフィギュレーション化 実機OSに関係なく単一のツールを用いる RPCフレームワークの整備 デバッグツール制作のハードルが低い
  27. 27. devwire 有線接続 + TCP/IPの組み合わせの問題を解決するツールキット リバースポートフォワードの実現 ツールの統一 ポート番号の割り振り RPCによるデバッグツール実装の為のヘルパー Scaffold, サービスのブートストラップ
  28. 28. 有線接続でのTCP/IPの利用 複数のパターンに対応できる必要がある 実機がサーバーになる場合 PCがサーバーになる場合 行動する主体をサーバー、依頼する主体をクライアントにする 実体と逆転すると複雑な制御が必要になる
  29. 29. 実機がサーバーになる場合 各OSのツールに存在するポートフォワード機能を利用 これらを呼び分けることでクロスプラットフォーム化
  30. 30. devwire.forward - ポートフォワードツールのWrapper adbやlibimobiledeviceのツールを呼び分けるWrapper 個別にプロセスを立ち上げてスーパーバイザとして振る舞う .NET Coreで実装。Win/Mac用のバイナリを抱え込む 何も指定しなくても、起動するだけで利用可能 既定値で必要なポートが全てフォワードされる 接続しているデバイスのOSを自動的に検知
  31. 31. devwire.forwardによる実機側のサーバーへのアクセス
  32. 32. PCがサーバーになる場合 ポートフォワードでは実機からPC上のサーバーを参照できない リバースポートフォワードが必要 最近のAndroidならadb proxyが使えるが、iOSには存在しない 独自にリバースポートフォワードを行う ライブラリを実装する
  33. 33. devwire.gateway クライアントが踏み台になる形のTCP over TCP Gateway サーバー側のローカルホストへ通信を、クライアント側から接続可能な任 意のホストにトンネリング 実機をサーバーに、PC側をクライアントにする 実機側からPC側への通信が可能に クライアントからサーバーへの接続にはdevwire.forwardを利用 サーバー側でフォワード設定を宣言できる gRPCに限らず、TCPであればプロトコルを問わず中継可能
  34. 34. devwire.gatewayを利用したTCP/IPベースのツール利用
  35. 35. devwire.gatewayの利点 利用範囲が広い クライアントから届く範囲であればどこでもフォワード可能 TCPで片方向のフォワードができていれば、逆方向にできる 相手のOSやプラットフォームを選ばない 利便性が高い フォワード先を宣言的に定義できるのでPC側の指定が不要 ポートフォワードの成立状態をゲーム側が知ることが出来る
  36. 36. devwire.gatewayの採用技術 PoC(概念実証)をPure C#でクイックに実装 最終的なPoCの設計を下敷きに、C++17に移植 Unity以外のゲームエンジンでも利用可能 Win / Mac / Android / iOSに対応。bazelでビルド C++のコア層に対してFFI層を用意してネイティブプラグイン化 Unity用ライブラリ/PC用CLIツールのフロントエンドをC#で実装 バイナリプロトコルはflatbuffers。libuv(uvw)でイベントループ化
  37. 37. devwire.bootloader devwireの利用では利用ケースが様々ある Editor/Preview/実機, gRPC/gRPC以外 互いに同時に走ることがありうるのでポート番号を分離 ポート番号の解決とgRPCのServiceの管理をライブラリ化 サーバーの種別, 実行環境, 独自採番の番号から判断 利用側はポート番号を直接指定する必要が一切ないように
  38. 38. 有線でのTCP/IPでの通信が可能になったら その上で、TCP/IPベースのデバッグツール制作の敷居を下げる
  39. 39. TCP/IPでのデバッグツール制作の課題 TCP/IPでのデバッグツール制作を難しくしている原因 異常系を含めた扱い プロトコル設計 クライアント・サーバー間の不整合が起こりがち 任意の処理を任意のパラメータで呼び出し結果を取得したいだけ RPCフレームワークの導入が解決になる
  40. 40. デバッグツールの種別ごとに必要なものが変わる インターフェースが静的なデバッグツール 処理内容がゲームそのものに依存しないものが主 ファイル転送/ヒエラルキー操作/ログなど、ゲーム開発に共通す る軸で開発を手助けする汎用デバッグツール インターフェースが動的なデバッグツール 処理内容がゲームそのものに依存するものが主 ゲームのパラメータを可変させるデバッグメニューなど
  41. 41. インターフェースが静的な デバッグツール向けのRPC
  42. 42. インターフェースが静的なRPCへの要求 ポータビリティ 呼び出し側のツールの実装言語に制約を設けない 後方互換性があり、自由度の高い型定義 ツール間の依存性を適切に保ちつつ、複雑な構造も受け渡したい 実機をサーバーとして動作すること”も”出来る 処理を行う, 情報を送る主体がサーバーにならないと制御が難しい
  43. 43. gRPCの選定理由 ポータビリティ 対応言語が非常に多彩で、あり得る選択肢はほぼ網羅 後方互換性があり、自由度の高い型定義 Protobufを用いたIDLがあり、後方互換性も担保できる 実機をサーバーとして動作すること”も”出来る Unity IL2CPPでgRPCサーバーとして動作させることが可能 ストリーミングもあるので、高度な制御も低コストで可能
  44. 44. インターフェースが動的な デバッグツール向けのRPC
  45. 45. インターフェースが動的なデバッグツールのRPCへの要 求 実装によってインターフェースが定まる 処理を実装するのは主にゲーム開発チームのエンジニア 処理に合わせたインターフェースを手で定義する手間をなくす 実行できるタイミングは動的に定まる 実行できるタイミングが限られる処理も多数ある フロントエンドは自動的に定まる 実装からフロントエンドは自動的に生成されるべき
  46. 46. gRPCは動的なデバッグツールには向かない 実装によってインターフェースが定まる IDLを書いてコード生成を行う必要がある 実行できるタイミングは動的に定まる 実行できない処理を表明することはできない フロントエンドは自動的に定まる エコシステムを活かせば一部可能だが、エンジニア向け
  47. 47. ユースケース特化の動的なRPCを実装することにした 実装によってインターフェースが定まる 実行できるタイミングは動的に定まる IDLを使わず、任意のタイミングでC#の実装を投げ込む フロントエンドは自動的に定まる Webの技術でデバッグメニューの汎用フロントエンドを生成 実機でもPCでも閲覧可能なデバッグメニューの実現
  48. 48. Retweak HTTPサーバ + JSONSchemaベースのRPC + Webフロントエンド 実装によってインターフェースが定まる C#のdelegateからJSON Schemaを生成してインターフェースに 実行できるタイミングは動的に定まる デバッグコマンド毎に動的に付け外しが可能 フロントエンドは自動的に定まる VueによるSPAとして汎用フロントエンドを実装 JSON SchemaからWeb UIを自動生成
  49. 49. デモ 左がWeb Browser 右が実機画面 https://youtu.be/FmNF_sow74E
  50. 50. スタンドアロン利用のデモ 単純なデバッグメニューとして利用可能 WebViewでSPAを表示 https://youtu.be/ji-Ga-0Wu3Y
  51. 51. Retweakの設計 Tweak 一つのデバッグ項目の単位 表示位置の仮想パスや、種別毎のメタ情報を保持 複数のCallableを、その名前とセットで保持 Callable RetweakのRPCの最小単位 引数をJSONで与えると、返り値をJSONで受け取れる関数 引数と戻り値のJSON Schemaとシリアライザと実際の実体
  52. 52. JSON Schemaの動的生成
  53. 53. Callableの実行
  54. 54. 複数のCallableの活用
  55. 55. UIの生成
  56. 56. させたい処理に応じたTweakを定義 Command 任意の処理の実行させるTweakを生成する Inspect / Modify 任意の値を読み書きするTweakを生成する Slider, Toggle, Image 最適化したUIを伴う任意の値を読み書きするTweakを生成する
  57. 57. 単純な型から複雑な型まで幅広く取り扱える
  58. 58. 画像やバイナリも取り扱える スクリーンショット 端末内データのzip化
  59. 59. フロントエンドの構成 vue + vuex + vue-router + bootstrap-vue エンジニアのみでもそれなりのUIを作れるので用途に合う 自然なパーマリンクとヒストリ管理も実現 json-editor JSON Schemaからフォームを自動生成するコンポーネント Objectや配列でも自在に表現できる
  60. 60. フロントエンドの構成 Google Analytics for Firebase アクセス解析を埋め込んでデバッグメニューの使用統計を取る FirebaseからBigQueryへExport Google データポータルでダッシュボードを作成
  61. 61. HTTPサーバーのホスティング .NET FrameworkのHttpListenerクラスが利用可能 簡易的なHTTPルーティングとリクエストハンドラ機構を実装 Tweakを扱うAPIとSPAの静的コンテンツを同じホストで提供 SPAの静的コンテンツはzipにして扱う StreamingAssetsに1ファイルを置くだけで使えるように Firebaseなどの設定をAPI経由でSPA側に流し込む
  62. 62. デモの実コード
  63. 63. Retweakによる利点 実機でもPCでも同じデバッグメニューを使える Bootstrapによるレスポンシブデザイン UIの実装に豊富なフロントエンド資産を活用できる デバッグメニューを扱う際のUXを低コストで改善できる フロントエンドを柔軟にカスタマイズできる
  64. 64. ここまでで成し遂げたこと 有線接続でゲームとツールが通信を自由に行える環境 devwire.forward + devwire.gatewayの実装 共通基盤となりえる静的なデバッグツールを作る環境 gRPCの採用 デバッグメニューにあたる処理をリモートで呼び出す環境 Retweakの実装
  65. 65. Agenda 実機デバッグツールで目指すゴール 実機デバッグツールの実現を阻害する要因の分析 実機デバッグツールを実現する環境の構築 汎用的なデバッグツールの実現
  66. 66. 汎用的なデバッグツールの実 現
  67. 67. Vfs 仮想ファイルシステムとデバイス間ファイル転送
  68. 68. モバイルゲーム開発におけるファイル転送の必要性 モバイルゲームのアセットの殆どはインストール後の事後配信 毎回アセットをアップロードが必須。サイズも巨大(GB単位) 定期的なビルドでなく、手元でのトライアンドエラーには不向き 作業者ごとの環境の分離も煩雑 実機にアセットを直接転送することで解決できる
  69. 69. ファイル転送ソリューションとその課題 libmobiledeviceやadb cp アクセスできるディレクトリに強い制限がある プラットフォーム固有のツールを使い分ける必要がある 転送時に指定するパス表記が統一されていない
  70. 70. 既存ソリューションの課題と解決のための要件 プラットフォームのツール依存と設定の煩雑さの解決 devwireを前提としたgRPCベースのツールにすることで解決 アクセスできるディレクトリの制限の撤廃 アプリのプロセス内でサービスとして動かすことで解決 転送時に指定するパス表記の統一 ファイルシステムを仮想化することで解決
  71. 71. vfs (Virtual File System) ファイルシステムの仮想化とネットワーク共有を実現する vfs.core ファイルシステムの仮想化と、パスの正規化 vfs.remoting.core 仮想化したファイルシステムをgRPC経由でマウント/公開 vfs.cli vfs同士のファイルコピーを行うCLIツール
  72. 72. 仮想ファイルシステムの実現 Container 基準パス以下のファイルシステムを抽象化 最低限必要なファイルシステムへの操作を行える ResourcePath Container配下の正規化されたファイルパス Router Containerに名前を付けて保持できるコレクション ゲームからContainerの実体を隠す
  73. 73. ディレクトリのContainerとResourcePathへの抽象化 Containerは特定のディレクトリを基準パスとして持つ インターフェース上には実際のパスそのものは現れない ResourcePathはContainerでは相対パスとして解決される
  74. 74. ResourcePath - 環境差を吸収するため、パスを正規化 /path/to/directory/file.unity3d /path/to/directory/ /path/to/directory /path/to/../to/directorY/ .や..によるパス内での相対パス表記は利用できない Case-Sensitive ディレクトリの区切りと終端必ず/で 必ず/で始まる
  75. 75. Containerの実際の基準パスを外部から隠蔽する
  76. 76. Containerの外部公開によるファイル共有の実現 VfsRemotingServer / VfsRemotingClient Routerと紐づくContainerをgRPCで外部から操作できるようにする RemoteRouter / RemoteContainer gRPC経由での操作を既存の実装と同じI/Fで扱えるWrapper NFSのようにネットワークごしにファイルシステムをマウント可能
  77. 77. Containerの外部公開によるファイル共有の実現
  78. 78. 共有されるファイルの識別 VFRL (Vfs File Resource Location) Vfsで管理されたネットワーク上の任意のファイルを示す識別子 vfs://local@localhost:1234/dir/file.unity3d スキーマ名 コンテナ名 ホスト名 + ポート番号 対象のコンテナ下のResourcePath
  79. 79. コマンドライン版フロントエンド ローカルと、任意のVFRLに対してのファイル操作を行えるCLI 全てのファイル操作はContainerに対する操作として行う ローカルファイルはその場で一時的なContainerを作成 可能な操作 ファイル/ディレクトリのmv, cp, ls, catなどの基本操作 特定ディレクトリを公開するサーバーの起動
  80. 80. ネイティブ版Vfsの実装 C++タイトルでvfsを使えるように、非Unity版を開発 golangで実装、cgoでC++向けのインターフェース付きでビルド 工数圧縮 & 技術実証 少なくとも、デバッグツールでの利用には耐えられる ランタイムが大きいが、デバッグ用途なら問題にはならない grpc-goはpure goなので、Android, iOSでも動作する gomobileはAndroid版がJavaのI/Fなのでゲームでは使いづらい
  81. 81. 柔軟な実機ファイル転送機構を実現できた 一定の手順で相手を選ばずにファイル転送できる Unity以外からでもツールチェインを利用できる ファイル転送という手間自体をなくすことも可能 PC側のContainerを直接ゲームから使うこともできる ゲーム側で高度なインテグレーションも可能
  82. 82. Scene Hot Reload UnityのSceneのホットリロードの実現
  83. 83. Unity Editorで編集中のSceneの内容をすぐ実機で見たい 実現の仕方は数あるが、根本的な要求は似ている ゲーム側の準備が整えば、これ自体は難しくない ビルド済みAssetBundleの転送で実現可能 AssetBundleの導入タイミングは開発中期以降が多い 準備が整ってなくても実現できる方法を用意する
  84. 84. Sceneそのものを実機に転送する方法 1. キーボードショートカットやメニューでクリックで実行 2. Editorで編集中のSceneを一時的なAssetBundleとしてビルド 3. ビルドしたAssetBundleをgRPCで実機に送る 4. 実機で受け取ったAssetBundleからSceneをロード 実機にHot Reload Serverが動くSceneを含めるだけで実現可能
  85. 85. Sceneのビルド SceneのビルドはScriptable Build Pipelineを利用 スクリプトコンパイル結果はキャッシュしてできるだけ回避 開いているSceneを全て個別のAssetBundleとしてビルド Sceneから依存するアセットも全てAssetBundleに含める
  86. 86. ビルドしたAssetBundleを実機に送る Editorから実機にgRPCで接続 全SceneのAssetBundleのバイナリとActiveなSceneの名前を送信
  87. 87. 実機で受けったAssetBundleからSceneをロード 1. 読み込み前に、読み込み済みのSceneを全てアンロード 2. 受け取ったAssetBundleを全てロード 3. AssetBundleからSceneを全てロード 4. ActiveなSceneを切り替え
  88. 88. 汎用的なホットリロード環境が実現できた 汎用的だが、常に使えるものではない Scene初期化処理の呼び出しを行う必要はある ゲーム側のScene管理と競合する可能性はある ゲーム側がSceneのAssetBundle化をしているのであれば不要 開発の初期に少ない準備で気軽に使える手段
  89. 89. Agenda 実機デバッグツールで目指すゴール 実機デバッグツールの実現を阻害する要因の分析 実機デバッグツールを実現する環境の構築 汎用的なデバッグツールの実現
  90. 90. 最後に この発表の振り返りと、これからの展望
  91. 91. 実機デバッグのイテレーション高速化の道具は十分整った デバッグツールの実装環境の実現 有線接続でゲームとツールが通信を自由に行える 共通/ゲーム特化なデバッグツールを気軽に作れる 汎用的なデバッグツールの実現 柔軟なファイル共有手段という問題解決の武器を提供 カジュアルなホットリロード機構の実現
  92. 92. これからの展望 具体的な利用実績の積み上げ 潜在的な需要をもっと吸い上げる 汎用的なデバッグツールの拡充 タイトルチームがやるべきことだけにより向かえるように Blazor WebAssembly, Serverの活用 ゲームコードとデバッグツール間のコード共有 Electronと併せてインハウスツールの製作手段として検討
  93. 93. Thank you for listening!
  94. 94. Appendix
  95. 95. RetweakのC#動的コード実行環境 SlowSharpを用いてC#コードの動的実行を実現 Roslynで解析した構文木を動的に実行するC#インタプリタ HTTP経由で渡されたC#コードを実行し、返り値はJSON化 Debug.LogによるログをServer-Sent EventでSPA側に通知 SPA側の編集UIにはMonaco Editorを採用 C#のシンタックスハイライトが多少効く コードを実行するキーボードショートカットも登録

×