もんりぃ is undefined.

育児ネタとか、技術ネタとか。

Unity 2019.1 で Unity Package Manager が 90% くらい民主化された件について

はじめに

日本時間の 2019/04/16 (Tue) に Unity 2019.1 がリリースされました。

で、リリースノートの中に Unity Package Manager に関して気になる記述を見つけたので、検証してみたところかなり嬉しい結果になったので、それの報告となります。

  • 2019/04/18 (Thu) 03:50 追記

Unity Package Manager (upm) とは?

ググれ

docs.unity3d.com

ざっくり言えば、Unity が提供する新しいパッケージ管理のための仕組みです。

これを用いれば Unity の UI 上で Unity 公式のパッケージを追加・更新できるようになります。

民主化

実は以前、以下の記事でも upm の民主化について触れています。

monry.hatenablog.com

この時点では、サードパーティのパッケージに依存するサードパーティのパッケージを追加出来ず「時期尚早」との結論を出していました。

しかし、今回改めて調べ直してみると、(どこのバージョンからかは分かりませんが) 自前の npm Registry を立てれば行ける ことが分かりました!

f:id:monry84:20190417015031p:plain
実際に試してみた結果

どうやるの?

ポイントは 自前の npm Registry を立てる という点にあります。

そもそも npm Registry というのは、 Node.js のモジュールである npm パッケージをホスティングするサービス のコトを指しており、 https://www.npmjs.com/ が親玉的な存在になっています。

んで、まぁ、npmjs に対してパッケージを Publish すれば npm は勿論、upm からもダウンロードが出来る *1 ようになるわけです。 が、 npmjs は本来 JavaScript のモジュールをホスティングするためのサービスであり、基本的に Unity Package Manager がアクセスする場所としては想定されていません。

「じゃあ、どうすりゃいいのよ?」というと 自前で npmjs クローンを作る という話になるわけです。

で、もちろん相当頑張れば npmjs クローンをイチから作るコトも出来るとは思いますが、そこは便利な時代になったもので Verdaccio という OSS がその役割を担ってくれるのです。

いや、だから、どうやるの?

はい。本題です。

Verdaccio のインストール・起動

公式のドキュメントにやり方は書いてありますが、私は Docker を用いました。

docker pull verdaccio/verdaccio
docker run -it --rm --name verdaccio -p 4873:4873 verdaccio/verdaccio

はい、おしまい。

これで立ち上がるプロセスが 4873 ポートで張ってくれているので http://localhost:4873 にアクセスして以下のような画面が表示されれば起動成功です。

f:id:monry84:20190417020212p:plain

Verdaccio のユーザ追加と設定

画面に書かれている

npm adduser --registry  http://localhost:4873

を打ち込むと、 * ユーザ名 * パスワード * メールアドレス の入力を求められるので、入力します。

これにより、前節で立ち上げた Verdaccio のコンテナにユーザの登録が行われて、ホスト OS 側にも認証情報が記録された形になります。

Verdaccio へのパッケージの追加・更新

パッケージとして追加したいディレクトリに例えば以下のような JSON ファイルを package.json という名前で配置します。*2

{
  "name": "dev.monry.upm.test",
  "dependencies": {
  },
  "version": "1.0.4",
  "unity": "2019.1",
  "displayName": "Monry Test",
  "description": "",
  "keywords": [
    "unity"
  ],
  "readme": "test test test"
}

そして、 package.json が配置されているディレクトリで以下のコマンドを実行します。

npm publish --registry=http://localhost:4873

するとログが少し出て、登録が完了した旨が表示されます。

f:id:monry84:20190417021851p:plain

依存パッケージの追加・設定

元々やりたかったコトとして、「サードパーティパッケージがサードパーティパッケージに依存する」という状況を作りたかったので、依存先となるパッケージも登録します。

例えば以下のような package.json のパッケージを追加します。

{
  "name": "dev.monry.upm.dependent",
  "dependencies": {
  },    
  "version": "1.1.0",
  "unity": "2019.1",
  "displayName": "Monry Dependent",
  "description": "",
  "keywords": [
    "unity"
  ],
  "readme": "dependent!"
}

これを npm publish --registry=http://localhost:4873

で、これを参照するために、元々作っていた dev.monry.upm.test というパッケージの package.json を以下のように変更します。

  {
    "name": "dev.monry.upm.test",
    "dependencies": {
+     "dev.monry.upm.dependent": "1.0.1"
    },
-   "version": "1.0.3",
+   "version": "1.0.4",
    "unity": "2019.3",
    "displayName": "Monry Test",
    "description": "",
    "keywords": [
      "unity"
    ],
    "readme": "test test test"
  }

こっちも新しいバージョンである v1.0.4 を Verdaccio に登録するために npm publish --registry=http://localhost:4873

これで準備完了です。

Unity Package Manager に Registry を追加

標準の Unity Package Manager では、Unity 公式の Registry しか参照できません。 そこで、今回作成したオレオレ Registry を Unity Package Manager に認識させる必要があります。

やり方としては、オレオレ Registry のパッケージを利用したい Unity プロジェクトの Packages/manifest.jsonscopedRegistries ノードを追加するだけです。

{
  "scopedRegistries": [
    {
      "name": "monry.dev",
      "url": "http://localhost:4873",
      "scopes": [
        "dev.monry"
      ]
    }
  ],
  "dependencies": {
    "com.unity.ads": "2.0.8",
    …中略
    "com.unity.modules.xr": "1.0.0"
  }
}

各ノードの意味はザックリと以下のような感じです。

  • name: 何でも良いが、分かりやすいものがヨサソウ
  • url: Registry の URL
  • scopes: 逆ドメイン記法のパッケージ名プレフィックスを指定
    • 複数指定可能
    • 詳細度順に最も先にマッチしたモノが採用される

詳しいコトはマニュアルをご参照ください。

パッケージをプロジェクトにインストール

ここまでの手順で、Unity Package Manager の UI 上に Verdaccio に登録したパッケージが表示されるようになっています。

f:id:monry84:20190417023213p:plain

あとはインストールしたいパッケージを選択して Install ボタンを押下すれば依存パッケージも含めてプロジェクトへのインストールが完了します!

f:id:monry84:20190417023437p:plain

OSS 的な公開

今回の手順だと、完全に localhost で閉じた話になってしまっています。 しかし、例えば AWS などのパブリッククラウド上にインスタンス立てて Verdaccio をインストールして適切にネットワークなどの設定を施せば外部からアクセス可能な Registry として利用することができます。 今回はその辺のアーキテクチャとかについては言及しませんが、インフラにたしなみがある人であればそんなに難しくないんじゃないかと思います。

追記: 実際にやってみた

upm-registry.dev

Verdaccio を GCP 上に立ててみました。 あくまで実験用ですが、需要が高ければ本気で運用考えます。

f:id:monry84:20190418040711p:plain

なお、認証関連の仕組みとして 特定の GitHub Organizations の Member 以外は、ダウンロードはできるけど publish ができないようになっています。

原因は定かではありませんが、パッケージ一覧の取得に失敗するコトがあるようで、 Packages/manifest.json に個別にパッケージを記載しないと駄目かも?

まとめ

  • Verdaccio を立ててパッケージを登録する
  • Packages/manifest.jsonscopedRegistries を追加すればオレオレパッケージが管理可能
  • 頑張れば一般配布用に公開もできる

………90%?

ところで、この記事のタイトルは「Unity Package Manager が90%くらい民主化された件について」です。

まぁ、100%って言っちゃっても良かったんですが、 Unity さんがサードパーティのパッケージを登録するための Registry を解放 してくれて初めて 真の民主化 と言えるかな、というコトで辛口の採点にしていますw

Asset Store の Asset なんかも upm に統合していくという噂もあるので、今後の展開も楽しみですね!

*1:ちょっと設定必要ですが

*2:バージョン名とか名前はテキトーです。

Unity 2019.1 個人的に気になるポイント

はじめに

blogs.unity3d.com

日本時間 2019/04/16 (Tue) に Unity 2019.1 が正式リリースされました!

ってことで、いつもの 個人的に気になるポイント をまとめます。

  • 2019/04/16 (Tue) 23:37 Package Manager に関して追記

気になるポイント

LWRP 正式版

Unity 2018.x の間はずっと Preview でしたが、ようやく Preview が外れて安心して利用できるようになりました。

既存のプロジェクトのマイグレートは大変ですが、Shader Graph のコトなどを考えれば対応を前向きに考えたいところです。

モバイル向けのパッチビルド

どこまで行けるかは分かりませんが、パッチビルド的なことができるようになるのかな?

IL2CPP ビルドがクソ重い問題とかの光明になれば嬉しい。

Mobile Adaptive Performance (Preview)

モバイル向けのパフォーマンスレポートなどが進化している感じですかね?

DOTS (Data-Oriented Technology Stack)

Burst Compiler を使ったマルチスレッド処理をハイパフォーマンスに捌くための仕組みって理解で良いのかな?

キッズスターのプロダクト的にお世話になる可能性は少なそうだけど、一部界隈は一層盛り上がりそう。

Shortcut Manager

キーボードショートカットをカスタムできます。 いや、元々頑張ればできたんだけど、公式にサポートしてくれましたね。

Android SDK / NDK

Unity Hub 経由でインストールできるようになりました。

これでビルド環境作るのが少し楽になりますね!

Incremental Garbage Collection

賢い GC

スパイクを分散できるとかだったかな?

まぁ、そもそも無駄に GCAlloc しないようにしましょうねーって話だとは思いますが。

Timeline Signals / Markers

個人的には一番嬉しい。

色々と面倒ごとの多かった Timeline に絡んだイベント処理を簡単に実装できるようになります。

UIElements

Editor 拡張に於ける UI の革命。 HTML/CSS ライクな構文で Editor UI を構築できちゃいます。

Package Manager

改良されて GitHub から取得ができるようになったとかなんとか。 元々 git 使って取得はできてたんだけど、依存解決とかもできるようになったのかな? 急いで試してみないと!

2019/04/16 (Tue) 23:37 追記

Correct. As you have found out, packages cannot themselves declare a dependency on anything other than an officially published version. We don't have any plans to allow dependencies on unofficial sources for the time being but this design might be revisited at a later date. Please note that I cannot confirm we'll do it, nor (obviously) provide an ETA.

公式フォーラムでの中の人の発言 的に、「自作パッケージが依存するパッケージは公式パッケージのみ」とのことで、完全民主化は当分無さそうな気配でした。

Assembly Definition Files / Versioning

マジかよ!今まさに待ち望んでた機能やないか! どうやるのかは分からんが、asmdef にバージョン情報持たせられるっぽい。

IL2CPP ビルド高速化

コード生成が20%速くなったとか。

Quick Search

Asset の検索が楽になるパッケージ。 使い心地試してみよう。

まとめ

今回もグラフィック周りは気になる機能が目白押しですね!

個人的には、DevOps 的な方面にも手が入ってくれているのが嬉しいです。

頑張って移行を進めないと!

技術書典6にサークル参加します!

f:id:monry84:20190411150022p:plain
キッズスター技術書典部

2019/04/14 (Sun) に池袋サンシャインシティにて 技術書典6 が開催されます。

その技術書典6において け54 というブースで「キッズスター技術書典部」というサークルとして参加いたします。

f:id:monry84:20190411145933p:plain
サークル配置

今回はソレの宣伝記事となります!

技術書典って?

公式ページ によると、

新しい技術に出会えるお祭りです。
技術書典は、いろんな技術の普及を手伝いたいとの想いではじまりました。
技術書を中心として出展者はノウハウを詰め込み、来場者はこの場にしかないおもしろい技術書をさがし求める、技術に関わる人のための場として『技術書典』を開催します。

とのコトで、平たく言うと「技術書オンリー同人誌即売会」です。

第6回目となる今回は463のサークル *1 が参加しており、1万人以上の来場者が見込まれるイベントとなっております。

キッズスター技術書典部って?

株式会社キッズスターの社員や関わってくださっているフリーランスの方々により構成される社内部活的なモノになります。

現在のところ部員数 *2 としては 9名 となっております。

何頒布するの?

f:id:monry84:20190411144342p:plain
キッズスター学習帳

「キッズスター学習帳」を頒布します。

「キッズスター学習帳」ってどんな本?

概要

Key Value
総ページ数 約120P
価格 ¥1,000-
執筆者 6名
表紙デザイン ムッシュ永田 *3

  1. ごっこランドを支える技術 〜AssetBundle 編〜
  2. 明色化粧品パビリオンの開発裏話
  3. トロントのなんたらかんたら
  4. 勉強会開催のすヽめ
  5. Android で自動でテストプレイする
  6. Unity でベクターグラフィック

詳細

Unity のお話しから海外生活の話まで様々な内容を取りそろえております。

自分は第1章の ごっこランドを支える技術 〜AssetBundle 編〜 を上梓しました。

AssetBundle の基礎的な話にはじまり、キッズスターでの運用事例を可能な範囲で紹介した章となっておりますので、「これから AssetBundle 触らなきゃ行けないんだけど…。」という方や「AssetBundle の運用について悩んでる!」という方に是非ともお読み頂きたく存じます。

当日は?

当日は、自分と id:lycoris102 がブース内に立って売り子をやる予定 *4 となっております。

一先ず紙媒体の本のみを販売しますが、後日電子版を BOOTH にて販売する予定です。*5

まとめ

サンシャインシティでぼくとあくしゅ!」

*1:公式の発表が見つけられなかったので、サークルリストページを $('event-circle-list ul').childElementCount; で数えました。

*2:Slack の当該チャンネルにジョインしている人数

*3:キッズスターのデザイナー

*4:自分は所用につき昼過ぎくらいまで

*5:多分在庫余るのでそれも BOOTH で売ると思う

EdTech LT Night & Meetup Tokyo に参加しました

はじめに

2019/03/25 (Mon) に AWS Loft で開催された EdTech LT Night & Meetup Tokyo に参加してきました。

それの感想など。

(スライドの公開とかあるのかなぁ…?🤔)

Keynote

  • AWS の方による EdTech 方面の取り組みに関する基調講演がありました。
  • 私の英語力の低さにより、仰っているコトの半分も理解できませんでしたが、スライドの手助けもありなんとか方向性とかは理解できました。
  • NDA とか分からんので、仔細は割愛。
  • キッズスターは、ガチの EdTech とは趣を異にするので、直接的な恩恵は受けられないかもだけど、良い流れを感じました。

Lightning Talk

Classi / 本間さん

  • ガチの公教育に対する EdTech 事業の取り組みについて。
  • かなりシブい話が多かったが、その分真剣味を感じました。
  • 公教育に於ける事業の実態をかなり詳細にご説明いただけて、めちゃめちゃ学びが多かったです。

公教育に於けるソフトウェアのアップデート状況は?

  • 渋谷区が配る Windows タブレットで Scratch が動かない問題に絡めて質問させていただきました。
  • 回答としては「シブい。かなりシブい。」という感じ。
    • 💭 まぁ、そうですよねぇ…。

「上は使えと言うが、現場が使わないというケースはあるか?」

  • 「ある。」
    • 地道な草の根活動が大切とのこと。

Life is Tech / 奥苑さん

  • Disney テクノロジア魔法学校の話など。
  • 労働集約的(とは言ってなかったけど)な業務を如何に IT 化するかが肝という感じ。

「ユーザ獲得のトリガーは親?子ども?」

  • 「リピートは子どもトリガー」とのこと。
    • 💭 新規獲得はどうなんだろうなぁ?懇親会で聞けば良かった。

Benesse i-Career / 長根さん

  • doda キャンパスのお話。
  • 技術寄りのお話がメイン。
  • Claudia.js を使っているらしい。
  • AWS SAM 使ってる。
    • 興味はあるけど、使ったことないので素振りしてみたいかも。
  • 「ワーッ!」と作ったので DevOps 周りはこれから。
    • 💭 割と DevOps しやすそうな環境っぽいのでコンテナ化しやすそう。

花まるラボ / 北畑さん

  • 今日の登壇者・参加者の中で、プロダクトが一番近い会社さん。
    • コンセプトは違うけど、ターゲットとか技術スタックとかはほぼ同じ。
    • なんなら創業時期もほぼ同じ。
  • 毎週子どもテスト的なことをしているらしい。
    • 💭 純粋にすごい!めっちゃ大変そう!
    • 「エンジニアも参加する。子どもからのストレートな意見に打ちのめされるw」→(💭 それな!)
  • 非言語系に振っているので、海外に出やすい。
    • 💭 ウチ以上に言葉を使わないので、出やすそう。

「プロトタイピングのクオリティは?」

  • 先ずは絵すら当てないプロトで大人が判断する。
  • 子どもテストは絵を当ててから。

Meetup

  • インドから日本に来てプログラミング教室的な事業をやられている方とお話しました。
    • Microsoft MVP Global Summit から戻って日が浅かったお陰で、英語モードが残ってて、どうにか会話できました。
  • 花まるラボの方々ともお話して、Unity エンジニア採用の話とか、K-12 App の生の現場の話なんかもできました。

所感

  • 事業ドメインで切りつつ、Tech な集まりというコトで、かなり濃いコミュニケーションができました。
  • 今後も開催されるようであれば、積極的に顔を出したいなぁと思います!
    • なんなら登壇機会とかも頂戴できたりしたら嬉しいです😁
  • AWS Loft で開催される勉強会は初参加でしたが、広々としたオシャレスペースで会話できるのが👍でした。

「Unity AssetBundle 完全に理解した」で主催 && 登壇してきました

はじめに

2019/03/24 (Sun) に開催された Unity AssetBundle 完全に理解した 勉強会の主催と登壇をしてきました。

感想などとともに、Twitter で寄せられた質問等にアンサーしていきたいと思います。

内容

AssetBundle とその周辺技術に関する基本的な部分の説明と、株式会社キッズスターでの運用ノウハウなどをシェアしました。

AssetBundle を取り巻くキーワードについて、個別に掘り下げましたので、これから AssetBundle を完全に理解した い方に向けたセッションとなっているかと存じます。

後日 Unity Learning Materials にも掲載予定となっておりますので、公開されたあかつきにはご覧いただけると嬉しいです。

Twitter での反応に対するアンサー

Android も 150MB になるのでは?

Android Developers Blog: Google Mobile Developer Day at Game Developers Conference 2019

To better support high quality game experiences and reflect improved devices, we've also increased the size limit for APKs generated from app bundles to 150MB and raised the threshold for large download user warnings on the Google Play Store to 150MB, from 100MB.

とのコトなので、確かに制限が緩和されるもようですね!知りませんでした…。

先週行われた GDC で発表されたもようです。

Streamed Scene AssetBundle の利用用途は?

C# スクリプトは更新不可なので、お察しの通り Player ビルドに含まれるコンポーネントの範囲で更新できる内容に留まります。

工夫次第で色々なことができますが、例えば GameObject の配置を修正したり、アタッチするテクスチャを変更するなどがユースケースとして想定できますね。

SingleManifest では?

正式に Single Manifest と呼称している資料を見つけられなかったので、今回のスライドでは AssetBundle Manifest と呼んでいます。

キッズスター社内では普通に Single Manifest と呼んでいたりしますw

Unload せずに Load するとエラーになるよね

なりますねー!

Unload 絡みの LT が控えていたこともあり、セッションでは触れませんでしたが、 AssetBundle.Unload() をせずに同じ AssetBundle を Load するとエラーが置きます。

運用ルールの選定方法

これは本当に難しい問題だと思います。

個人的には、利用している Unity バージョンで利用できる AssetBundle 周辺の機能を理解したうえで、開発オペレーションを阻害しない方法を探すのが良いと考えています。

ただ、一度運用ルールを設定してしまうと変更が簡単ではないため、「えいやー」で設定せずにシッカリ熟慮することを強くオススメいたします。

ごっこランドの秘伝のタレ

確かに秘伝のタレは少なくないかもです。

極力公式が提供する機能のみで完結するように努力していますが、まぁ抽象化は無理だよねって状態になっています。

ビルドサーバ周りの情報

ですです。既に古くなっている情報も多少ありますが、是非ご覧ください〜!

所感

個人

全体的に「初心者に分かりやすい」的な感想を多く頂戴できたのが、心より嬉しいです!

個人的なテーマとしてもそこら辺をとても意識しているので、狙いがハマってニヤニヤしながら TL 眺めてましたw

今後も「初心者・初学者に寄り添う もんりぃ先生」で在り続けたいと思っています!

全体

休日の開催にも関わらず、速報ベースで85%近い方のご参加をいただき、皆さんの関心の高さを実感いたしました。

私が主催する回としては、初めての休日開催だったので、色々と不安なこともありましたが、 mixi さんや id:lycoris102 のお陰で滞りなく進行できたので、改めて御礼を申し上げます!

Unity Android ビルドの Minify オプションの罠

はじめに

前回のポストから2ヶ月くらい空いてしまいました。

生きてます。ありがたいことに忙しいです。

さて、今回は 含まれているはずの Native Plugin のクラスが AndroidJavaClass で参照出来ない という問題に遭遇したので、備忘録として記します。

現象

Unity 2018.3 でビルドした Android Player が AndroidJavaClassAndroidJavaObject を利用する箇所で ClassNotFoundException *1 を吐く

java.lang.ClassNotFoundException: android.support.v4.content.ContextCompat

前提

  • Unity 2018.3.6f1
  • Build Type: Gradle
    • 今回 Unity 2018.3 対応する際に Internal から切り替えました
  • AndroidJavaClass が参照する Java クラスは .aar ファイルにて提供される
    • 利用したいクラスは android.support.v4.content.ContextCompat

調査

最初は「Firebase SDK に同梱される Play Service Resolver によって提供される .jar ファイルや .aar ファイルが古い…?」とか「Gradle に切り替えた *2 コトにより、ライブラリが競合した…?」などの可能性を模索して mainTemplate.gradle をプロジェクト内に置くなどして頑張ってもダメで、途方に暮れていました。

が、ふと「ビルドまでは存在しているクラスが消える」という現象から「あれ?Code Strip 的な動きじゃね?」と思い至り、そっちの方面から調査を再開しました。

んで、調べていると Android Project として Export した際に吐き出される build.gradle 内に以下のような記述を発見しました。

android {
    buildTypes {
        debug {
            minifyEnabled false
            useProguard false
        }
        release {
            minifyEnabled true
            useProguard true
        }
    }
}

*3

で、「Proguard の難読化によってクラス名変わった!?」と思い、オプション変えるもダメ。

「何でだよー!」と思い、ダメ元で「 minifyEnabledfalse に変える」と「ウゴイタァァァ!!!

原因

ProGuard を用いた Minify 処理により、 AndroidJavaClassAndroidJavaObject からしか参照されていないクラスが落とされていた。

AndroidJavaClassAndroidJavaObject はリフレクション(厳密には違うと思うけど)的な処理であり、コンパイラ的には参照を解決できないために Minify 時に落とされてしまうワケですね。

対策

雑に対応

PlayerSettings の Minify > Release を ProGuard から None に変更する。

f:id:monry84:20190312155758p:plain

カチッと対応

PlayerSettings の Minify > Release は ProGuard のままにし、 User Proguard File を有効にする。

f:id:monry84:20190312160404p:plain

(まだファイルが無ければ)自動生成される proguard-user.txt の内容を以下のようにする。(もっと詳細に指定しても良いかも知れません。)

-keep class android.support.v4.content.** {
    *;
}

所感

実は、デバッグビルドだと問題なく動いていたようで、その確認を怠ったために切り分けが長引いてしまいました。

ビルド周りは、出力先プラットフォームが利用する技術への理解が必要になるので、なかなか大変です…。

*1:C# ではなく Java の Exception です。

*2:これまでは Internal を利用していました。

*3:関係無い行は消しています。

ZenjectSceneLoader が便利です

はじめに

新年あけましておめでとうございます。本年も何卒よろしくお願い申し上げます。

さて、最近 Zenject と仲良くなれてきている気がする id:monry です。

github.com

Zenject は Unity *1 における DI *2 フレームワークです。

で、その Zenject でマルチシーンを取り扱う際に ZenjectSceneLoader というクラスがとても便利だったので紹介します。

ZenjectSceneLoader とは

一言で言えば UnityEngine.SceneManagement.SceneManager の Zenject 版 で、マニュアルにシレッと書いてある 機能だったりします。

何かと面倒になりがちな Zenject におけるマルチシーン の補助的なライブラリクラスだと思ってもらえると理解が早いかも知れません。

ZenjectSceneLoader の使い方

とても簡単なので、サンプルコードをご覧いただければ理解できるかと思います。

class LoadButton : MonoBehaviour
{
    private ZenjectSceneLoader zenjctSceneLoader;

    [Inject]
    private void Construct(ZenjectSceneLoader sceneLoader)
    {
        this.zenjectSceneLoader = zenjectSceneLoader;
    }

    public void OnClick()
    {
        zenjectSceneLoader.LoadScene("Foo", LoadSceneMode.Additive);
    }
}
  1. Scene 読み込みを実行したいクラスに対して ZenjectSceneLoader を Inject します。
    • サンプルコードでは Method Injection を用いていますが、Field/Property Injection とかでも良いと思います。
  2. 読み込みたいタイミングで LoadScene を用いて読み込みます。
    • 非同期呼び出し用の LoadSceneAsync メソッドも用意されていたりします。
    • LoadSceneAsync の場合 AsyncOperation が返されるので、 UniRx.Async と組み合わせて await させるコトで可読性の高い書き方が出来るようになるかと。
    • LoadSceneMode.Single, LoadSceneMode.Additive の何れも対応しています。

ZenjectSceneLoader の特長

これだけだと便利さは伝わらないと思うので、便利な特長を紹介します。

読み込み時の追加 Binding 可能

LoadSceneAsync()Scene が読み込まれる時に、読み込み先の SceneContext に対して追加の Binding を設定 するための delegate を第3引数に受け取るオーバーロードが提供されています。

zenjectSceneLoader.LoadSceneAsync(
    "Bar",
    LoadSceneMode.Additive,
    (DiContainer container) =>
    {
        // 何か色々 Bind したりとか
        container.Bind<IHoge>().To<Fuga>().AsCached();
    }
);

例えば、共通ダイアログ的な Scene を読み込む際に中身のテキストを追加 Bind するなどの使い方が考えられそうです。

他にも、押したボタンの内容に応じて、LoadSceneMode.Single で読み込みつつ次画面のモードを切り替える などの使い方もできるかもしれません。*3

読み込む Scene の関係性を定義できる

LoadSceneAsync() の第4引数に LoadSceneRelationship という列挙値を渡すことで、 読み込み元の SceneContext から見た読み込み先の SceneContext の関係性 を定義できます。

zenjectSceneLoader.LoadSceneAsync(
    "Baz",
    LoadSceneMode.Additive,
    (container) => { /* 何か Bind */ },
    LoadSceneRelationship.Child // 子 Context として読み込む
);

これにより、元 Context に Bind 済の値を用いつつ、閉じた Context として読み込むことができるようになります。*4

例えば、ダイアログのボタン押下時の処理をダイアログ呼び出し元の Scene 側で Bind して、ダイアログ内のボタンに Inject するような実装が考えられます。

他にも、読み込む毎に処理を Stack していき IEnumerable<AnyDelegate> に Inject して子 Scene 側で纏めて発火させる、といった実装ができるかもしれません。

全ての Context に Bind されている

ここまでの説明から分かるように、特別に Bind を行わずとも Inject が行えるのも特長の一つです。

具体的にどこの Context に Bind されているのかまでは調べておりませんが、恐らく ProjectContext 的なモノに Bind されているんじゃないかと思われます。

まとめ

ZenjectSceneLoader が便利なので、マルチシーン対応する場合の選択肢として利用してみては如何でしょう?

Zenject はドキュメントがとても長いので、なかなか全部の機能を理解することが難しいですが、便利機能がてんこ盛りなのでじっくりドキュメントを読む時間を確保したいものです…。

*1:以外でも使えると思うけど。

*2:Dependency Injection

*3:Single で読み込む場合は後述の LoadSceneRelationship を定義できない( None 限定)ので注意が必要です。

*4:簡易的な Scene Parenting だと思ってヨサソウ?