概要
知り合いの知り合いに相談された気がするので備忘録的にメモを書いてみる、ほぼ個人の見解
テーマは「Unity as a Library（以下、UaaL）をあなたのプロジェクトにおいて採用すべきか」
What's Unity?
一般的にはゲームゲンジン、あるいはゲーム開発ツールである。最近のスマホゲーム（特に3D）はUnityかUE4のいずれかで作られるものがほとんどである（たぶん）。
What's UaaL?
Unity as a Library is intended for specialist users who use native platform technologies such as Java/Android, Objective C/iOS, or Windows Win32/UWP, and want to include Unity-powered features in their games or applications.
そもそもUnity製のiOSアプリは、Unityによって作られる1枚のUIViewによって成り立つsingle view appplicatoinである（Androidの場合はsurface view）。これを普通のiOSアプリにおいて、ただの1枚のviewとして組み込む（embed）のがUaaLである。
要するに、 UaaLとは ネイティブアプリとUnityのいいとこ取り といえる。マジョリティではないが、プロダクトとして運用されている実績もある。
Unityの特徴
UaaLの前にUnityの特徴を考える。
まず Unity という単語を使った場合、これは次の3つの側面がある。
- Unity Engine: アプリに組み込まれるミドルウェア
- Unity Editor: 開発・制作ツール
- Unity Services: 統合開発プラットフォーム
この中で特に重要なのは2のツールとしての側面で、UnityとUE4以外のゲームエンジンが淘汰された理由はほぼこれである（と思う）。独自ゲームエンジンを使ってゲームを作ったことのある人ならわかるとおり、ゲームエンジンの性能不足に悩むよりもゲームアセットを制作するツールの貧弱さに悩むことの方が多い。Unityエディタはこのあたりをまるっとやってくれる。例えば、シーン再生中のオブジェクト生成、コンポーネントアタッチ、変数変更は極めて強力で開発効率を（それができない場合と比べて）1000倍引き上げてくれる。
雑っぽくUnityの特徴をいくつか挙げてみる。
- 動作環境をカスタムしやすい。特にマルチプラットフォーム対応やデバイス対応をしやすい、UaaLもこれの一種といえる。
- レンダリング周辺をカスタムしやすい。かなり柔軟に組める、というかやろうと思えばなんでもできるので、純粋なレンダリングエンジンとして使い映像作品を作ることもできる。
- コミュニティが強い。初心者がとっかかりやすく、気軽にアプリを作ることができる。OSSを含め、コミュニティは活発。
- XRとの相性が良い。ゲームエンジンとして3Dアセットを扱うのが容易、デバイス対応のカスタムのしやすさ、レンダリングのカスタムのしやすさとか。
技術としてUnityを選択するときはだいたいこのあたりが理由になる。
Unityとネイティブアプリ
ネイティブアプリとUnityを比較してみよう。
Unityを用いない普通のネイティブアプリは 普通の アプリをサクッとつくりやすい。ここでネイティブアプリと言っているものはSwift/Kotlinを想像しているが、Flutter/React Native/Xamaine等も基本的には同様である。普通ってなんだよ、という感はあるが ゲーム以外の と言い換えても良い。
これに対して、Unityは ゲームの アプリを（比較的サクッと）つくりやすい。そもそもゲームアプリは次のような特徴がある（ここではデザイン的な面に特に触れている）
- 素材が一点物になりやすくコンポーネントの共通化がしづらい傾向
- レスポンシブデザインにしない
- アニメーションが多用される
- エフェクトが多用される
- パフォーマンス（CPU/GPU/メモリ）がシビアである
- シーンの状態が動的である（＝状態管理が極めて複雑）
ネイティブアプリの開発でOSSに頼らず複雑なアニメーションを実装しようとしたことがあるだろうか？まあ、たぶんきれいとは言えないコードになったと推察するが、ゲーム開発ではそれが至るところに出てくる（かつそれが複雑な条件で起動して、さらに別のイベントを引き起こし、これがUXの肝である）。例えば、Swiftでflappybirdを 楽しいと思えるUXを実現する程度 の完成度で実装するのにどれくらいかかるだろうか？Unityなら1時間くらいあれば（素材があれば）実装できる（たぶん）。
また、Unityには3Dの取り扱いが容易である、という特徴がある。Metalで3Dのモデルの表示をするのは？これはできる。アニメーションさせるのは？これもできる。では、最新のゲームみたいなライティングを実現できる？これはきつい。。Animator Controller並みに複雑なアニメーションをさせられる？これはきつい。。さらにこれらのアートをつくるのはデザイナーだから彼らが最大限パフォームできるツールも用意しなければならなし、複雑な依存関係のアセットを管理する仕組みも必要になる。
一方、Unityで 普通の アプリを作ろうした場合、例えば次のようなことが起きる。
- ネイティブ開発だったら秒で終わる仕事に時間がかかる
- 例えばUIを作るのに時間がかかる。ネイティブアプリでUIを実装するより3倍くらい時間がかかる（体感）。例えば、UIKitのUITableViewとuGUIのScrollViewを比べるとわかりやすい。後者は ゲーム的なUIだったら 使い勝手は悪くないが、逆にレスポンシブ対応をしろと言われたらこれはきつい。それが簡単にできるように作られてはいない。
- 起動が遅い。
- Unityアプリはアプリ起動時にUnityエンジンを起動し、シーンを読み込む。そもそもゲームエンジンは大量のアセットを読み込む前提で作られているのでサクッと起動、サクッと動作という目的を達成するのに向いていない。
- バックエンド再生や他アプリのオーディオ再生との相性が悪い
- 普通ゲームは「フォアグラウンド」で「他のアプリをバックエンドで動かさずに」遊ぶことが多い、このあたりでエンジン側の微妙な不具合が出やすい
要するに一長一短ある。
UaaL vs Unity/ネイティブアプリ
UaaLはネイティブアプリとUnityの良い部分をいいとこ取りと言ってみたが、本当にそうだろうか。当然、そんなことはない。
UaaLで開発する場合、ネイティブ側に寄せるかUnity側によせるかで話が変わるが、ここではネイティブ側に寄せた場合を想定する（最悪Unityがなくてもアプリが成立する状況を想像する）。
UaaLはUnityの苦しい部分をそのまま引き継ぐ
- ネイティブ開発だったら秒で終わる仕事に時間がかかる
- 起動が遅い。
- バックエンド再生や他アプリのオーディオ再生との相性が悪い
UaaL特有の苦しみもある
- そもそもサポートが微妙であり細かい不具合が出やすい。例えばネイティブアプリがもつイベントループとUnityのイベントループは同期していない、そして同期する手段も限られている。
- ビルド時間が長くなりがち。そもそもビルドパイプラインを自分で整備（＝自作）しなければならない、面倒くささでいうとアセットバンドルのビルドフローを整備するのと同じかそれより面倒くさい
- アプリ全体の技術スタックが広がり「サクッと開発」のしづらさが上がる。Unityが関わる機能はネイティブ側とUnity側の両方の開発が必要である。
さらに、開発チームの面での苦しみもある
- チームが大きくなりがち。PdM・UIデザイナー・iOSエンジニア・Androidエンジニア・サーバエンジニアの5人のfeature teamがあったとしよう。ここにUaaLを導入したら？PdM・UIデザイナー・3Dデザイナー・iOSエンジニア・Androidエンジニア・サーバエンジニア・Unityエンジニアの7人チームになるかもしれない（これで済めばよいが・・）。
- アプリエンジニアとUnityエンジニアでスキルギャップがある。クライアントという点では同じなのだが、前述したとおりアプリ特性に結構な差があり、片手間で両方やるというのがそれほど簡単ではない。
このようにアプリだけなら考慮する必要がなかった問題とUnityだけなら考慮する必要がなかった問題がでてくる。
つまり・・？
技術選定という論点だと、 アプリ全体としてはネイティブアプリとして作ったほうが良く かつ 3D周辺機能をリッチにすることがそのサービスのコアバリューになる のであればUaaLを採用して良いのではないか、と思う。
例えば、ゲーム以外のエンタメ系のアプリであれば考える余地はあるのではないか、と思う（そういうサービスでよく採用されているよね、という事実から天下り的に導き出している節はないわけではない）。
逆にtoB的なサービスで安易に採用するのは現時点においてはあまり勧めない（たぶん）。あくまで現時点、なのでUnity側がそこのところいい感じにしてくれないかとは期待している。
Discussion