[GCC2018] Unity 2018は「カスタマイズ」で小さく速く多機能に

[2018/04/02 17:28]

山村達彦氏

　2018年3月30日，大阪にて「ゲームクリエイターズカンファレンス'18」が開催された。
　本イベントは関西圏最大のゲーム開発者向け技術カンファレンスで，デジタルエンターテインメントクリエイター協会（DECA）によって主催・運営されている。DECAについては先日のインタビューでお伝えした通りだ。

　本イベントにて，スポンサーであるUnity Technologies Japanより，Unity 2018の進化の方向性を紹介する「ここが変わる，Unity 2018」というセッションが開かれた。登壇者は，Unityエヴァンジェリストの山村達彦氏だ。

　先日のGDCのタイミングで，Unity 2018の多くの機能が公開されていた。本講演はその要約版ともいえる内容だ。かなり多くの新情報が紹介されたので，詳細レポートをお届けする。

「バグが多くてすみません」からのLong Term Support版スタート

　山村氏は，まず前バージョンである「Unity 2017」の振り返りについて語った。
　Unityを使ったアプリは全世界で200億ダウンロードされ，VR，AR系の新興プラットフォームにも次々に対応している。その種類は山村氏でも追えないほどだ。

　その急速な進化の半面，反省点も多かった。とにかく「バグが多い」という問題だ。とくにUnity5系の初期は，山村氏をもってして「暗黒時代」と言ってしまうほど，バグが多かった。

　Unityエンジンは数多くの開発者によって作られている。便利な機能が毎年追加され，プラットフォームのサポートが拡大する半面，バグも多く出してきた。
　Unityはこの対策として「パッチリリース」の仕組みを導入し，毎週バグを修正したパッチ版をリリースするというラピッドな開発スタイルに移行した。ところが，この高速なリリースは逆に「安定して使えるUnityのバージョンはどれなんだ？」という迷いを開発者に生じさせてしまっていたそうだ。

　そこで今回，新たに登場した新たなバージョンが「Long Term Support」である。これは，あるUnityのバージョンをLTS版として制定し，機能追加をせず，バグフィックスと致命的な問題の回避のみを「2年間」継続するというものだ。

　また，LTS版から次のバージョンへの移行はなるべく「痛み」をなくすという方針もあるそうだ。具体的にはUnity 2017の最終版として「Unity 2017.4.0f1」がリリースされている。

　このLTS版の登場により，大規模な開発現場でどのバージョンを導入していいか迷ったり，リリース済みのタイトルをメンテする際にバグ関係で泣く泣くバージョンアップをする……という問題が回避しやすくなる。とくに，運営型タイトルなどは長く同じバージョンを使い続けることがほとんどなので，2年間継続サポートはありがたい施策だと言えるだろう。

2018は「よくばりな年」になる

　昨年は，「Unity 2017.1～3」を見ても分かるように，アーティストフレンドリーな機能の年だったといえる。TimelineやCinemachineなど，デザイナーやアーティストが直接触れやすくなる機能を充実させる，というコンセプトだった。

　さて，2018ではどうなるか。山村氏によると，かなり「欲張りな年」になるのだそうだ。
　すなわち，クオリティ，グラフィクス，パフォーマンス，プラットフォーム拡張，そして2017に続いてアーティスト向けの機能拡張もしていくという。

　もちろん，これらの新機能はいきなり現れたものではなく，ながい時間をかけて積み上げてきた研究が成果を結ぶのが2018年なのだそうだ。

　さて，そんな中で山村氏が新機能の中で注目しているのが「マシンラーニング」「次世代レンダリング」「パフォーマンス向上」の3点だという。

　「マシンラーニング」，すなわち機械学習は，さまざまな分野に応用が期待できるのだそうだ。例えば，レースゲームにおいて人間と同じ学習プロセスでNPCを作ったり，端末ごとの問題をAIに吸収させたり，スマホゲームの運営でプレイヤー動向のデータを食わせて課金アイテム表示タイミングの最適化をはかったり……と，広がりが見込める。

　「次世代レンダリング」については，レンダリングパスのカスタム性が関係する。実はUnity5までは，すべてのプラットフォームにおいて単一のレンダリングパイプラインを使用していた。これはハイエンドでもローエンドでも中途半端になってしまっており，しかも中身はブラックボックスだった。そこで2018からは，レンダリングパイプラインをカスタマイズできる「Scriptable Render Pipeline」という仕組みが用意される。

　これはUnityのレンダリングパイプラインを開発者がカスタマイズ可能にすることで，最先端のHDグラフィクスからモバイルまで，広い範囲に対応するというものだ。Unityからはこの仕組みの上で，二つのサンプルを用意した。それが「High Definition Render Pipeline」と，「Light Weight Render Pipeline」だ。

　HD Render Pipelineは最新のグラフィクス表現が可能なパイプラインで，GPUをバリバリ活用し，PS4やXbox One，PCに向けたチューニングがされている。逆に，Light WeightはモバイルやWebGLなどの軽量な描画のために作られたものだ。

　これら二つの基本的な描画パイプラインに加えて，もちろん開発者が自由にカスタマイズ可能だ。例えば2Dのゲームであれば，スカイボックスやシャドウのレンダリングパスは不要になるのでスキップするなど，ゲームに応じて最適なレンダリングパスが組めるようになるというわけだ。

2Dゲーム用のレンダーパイプライン

　また，ノードベースでシェーダが組める「Shader Graph」も2018.1から利用できるようになった。この機能によってアーティストが作業しやすくなるのはもちろんだが，描画パイプラインがカスタマイズできるようになったことに起因するシェーダ周りの複雑化をシンプルに保つ，というモチベーションもあるのだそうだ。

　なお，Shader Graph自体もC#で組まれているので，これまた開発者がカスタマイズできるとのことだ。

抜本的に改善されるマルチスレッド対応

　Unity関連でよく聞く問題では，ゲームオブジェクトをたくさん置くと遅くなることや，メインスレッドへの依存，そもそもC#が重い，などのパフィーマンスに関するものが多かった。これらの問題をUnity 2018では，三つのアイデアで打開するという。

　一つは「データレイアウトの最適化」だ。最近のコンピュータハードウェアの特性として，「CPU性能の進化にメモリの進化が追い付いていない」という構図がある。そのため，多くの人は高速化のためにCPU側のキャッシュをなるべく活用する運用をするようになる。

　Unityにおけるコンポーネント指向はオブジェクト指向プログラミング（OOP）に則っているため，データがメモリの至るところに散らばってしまい，キャッシュ効率がものすごく悪い。このメモリレイアウトをきれいに並べることができれば，CPUが使いやすい形にメモリが整頓され，大きなパフォーマンス改善が期待できる。

　もう一つは「マルチコアへの対応」だ。昨今のハードウェア進化は，単一コアのスレッドの性能は頭打ちだが，コア数はクアッド，オクタとどんどん増えている。これを活用しない手はない。しかしながら，データレイアウトを意識した実装も，マルチスレッドプログラミングも大変難しいし，バグの温床になりやすい。

　そこでUnity 2018では，「とりあえずこの通りに組んだらパフォーマンスが出る」というフレームワークが用意された。それが「C# Job System」と「Entity Component System」だ。

　まずC# Job Systemは，並列処理を実現するためのシステムである。一つの時間のかかる処理を複数のコアで並列して実行させることができ，メインスレッドへの負荷を減らして，消費電力の低下も期待できる。

　実は，Unityの内部処理は多くを並列処理に置き換えているのだが，それが「C# Job System」で開発者も使えるようになったというわけだ。

　これと対をなすEntity Component System（ECS）は，コンポーネント指向に代わる新しいアーキテクチャパターンなのだそうだ。オブジェクト，データ，処理を分割して柔軟な表現を持たせることができるシステムで，とくにデータレイアウトが大きく改善される。単純な処理の高速化のほかにも，ゲームオブジェクトの生成や破棄がかなり速くなったのだそうだ。
　山村氏によると，手元で試してみたところ，500万個ぐらいのオブジェクトを生成したり破棄したりしてもサクサク行けるほどの改善があったとのことだ。

　ECSはC# Job Systemと簡単に連携できるようになっている。これの上で実装すればマルチコアの力も引き出しやすい。この二つに加えて，「Native Array」も加わる。
　C#はマネージコードであるため，配列にアクセスする時にパフォーマンス的なペナルティが入ってしまう。そこで，UnityはネイティブのバッファをC#側から直接アクセスできるシステムを提供し，C++ ポインタのようなスタイルでアクセスすることができるようになるそうだ。

　ECSとC# Job Systemをもう一つ上のレベルに持ち上げるのが「Burst Compiler」である。
これは，ECSなどの限られた実装条件で生成されたILを，ターゲットとするCPUに対して全力でチューニングするというアイデアのもとに作られたコンパイラである。これによって，劇的なパフォーマンス改善が期待できる。

　これにより熟練のプログラマがやるような最適化を比較的簡単に実現できるようになるのだそうだ。しかしながら，これを利用するためにはプログラマの考え方に大きな変更を要求することになる。現状のMonoBehaviourからECSに変換するには多くの変更が必要だ。

　とはいえ，こういった変更で辛い思いをするのは不本意なので，最終的には30分ぐらいでプロジェクト内のMonoBehaviourからECSに変更して，すぐにBurstの恩恵を受けられるようにしたいと考えているそうだ。
　C# Job SystemはすでにUnity 2018 のβ版に統合されており，すぐに触ることができる。ECSやBurst Compilerは，Unity公式のコミュニティで配布している段階だそうだ。

コアサイズが72KBに？　別バージョン「Tiny Unity」の登場

　開発でよく問題になるのは，ビルド時のUnityエンジン自体のサイズだ。たくさんの機能を持っているので，その分コアランタイムのサイズはそれなりの大きさになる。PCやモバイルではそれほど問題ではないが，もっと下の環境を見ると，まだまだサイズは大きい。例えばスマートウォッチ，IoT，WebGLなどに対してはコアランタイムのサイズは大きすぎる。

　そのため，Unityをもっと軽く，速く，小さく動作するような超軽量Unityを開発中なのだそうだ。Tiny Unityというコードネームで呼ばれるそれは，さまざまな抜本的改修の結果，平均的なコアランタイムサイズを72KBまで落とすことができたという。

　これに伴って，ゲームの起動も端末負荷もかなり抑えられている。ランタイムを小さくするだけではなく，アセットパイプラインの見直しによるアセットの最適化も行っているのだそうだ

　この超軽量Unityの用途は，例えばゲーム内広告のお試しゲームや，最近中国ではやっているらしい，メッセンジャーアプリ内でのミニゲーム配布，そしてWeb広告など，ゲームインストールすることなくちょっとプレイするスタイルに活用できると踏んでいるそうだ。Tiny Unityは2018年に届ける予定で開発しているそうなので，期待したい。

Asset Bundleも抜本的改革へ

　アセット管理システムも大幅に更新される。これまでUnityではアセット同士の依存やビルド時のアセットの解決などを自動で処理しており，アセットの依存などを自動で計算してAsset Bundleファイルを生成していた。しかし，この仕組みはややおおざっぱだったといえる。Asset Bundleは，Prefabを指定するだけで関係するマテリアルやテクスチャを自動的に含めてくれるが，逆に，うっかり余計なデータが含まれてしまうケースが多々あるからだ。また，アセットを利用すること考えたとき，Asset Bundleは読み込みのレイヤーが低レベルすぎる問題もある。

　そこでUnity 2018では，もっと細かくアセットのビルドができ，利用側も簡単に管理できる仕組みを用意する予定なのだそうだ。それが，「Scriptable Build Pipeline」「Resource Manager」「Addressable」の三つだ。まず「Scriptable Build Pipeline」は，アセットのビルドに利用するAPIを公開し，開発者側である程度コントロール可能にする仕組みのことだ。

　いままで自動的にさせるしかなかったアセットのビルドが，開発者側でビルド内に何を含めるか決めることができようになるという。
　もう一つが「Resource Manager」と「Addressable」である。これは，アセットの取得・管理を行うための機能だ。簡単に言えば，Resourcesフォルダに対するアクセスのような使い勝手をそのままに，Asset Buntleを扱えるようになることを目指している。

　これにより，アセットに対してAddressableというユニークなIDを割り振って管理し，バーチャルファイルシステムを介して，外部ファイルかどうかを気にすることなくアクセス可能になるそうだ。新しい仕組みであるが，これらの実装はオープンソースで提供されるとのことである。

　さて，これら三つのシステムを組み合わせて実現される新たな開発アプローチが「Dataless Player」と「Hot Reload」である。

　通常のビルドは，アセットが一緒にビルドされる。コードと実行ファイルに含まれるアセットが一体になっている形だ。そのままでは素材の差し替えなどが発生した場合にビルドをし直す必要が出るため，多くのゲームではAsset Bundleの仕組みを使って外部ファイルとしてアセットを分けている……というのが現状の構成だ。

　今後登場する「Dataless Player」は，Unityのコア部分とアセットを分けた状態でビルドされるようになる。これによって，ビルド後にアセットを変更して，端末上でゲームを動作させながらテクスチャを入れ替えたりできるHot Reloadの仕組みが可能になる。

現在のビルドとアセットの関係

Dataless Playerの仕組み

　つまり，アセット差し替えのたびに毎回ビルドすることや，Asset Bundleのビルドを行う必要がなくなり，実機で見た目や負荷を確認しながら開発ができるようになるそうだ。この仕組みが実現されたら，開発現場の負荷はかなり抑えられるはずだ。

まだまだ多数の機能を追加予定

　ほかにもUnity 2018には多くの機能が追加される。アセットインポートのデフォルト値を変更できるPreset機能，2Dアニメーションや，ピクセルパーフェクトカメラなどの2Dの表現を改善や，GDCのキーノートでは，Nested Prefab（階層化されたプレハブ機能）がUnity 2018.3から使えるようになる，という告知が大きく話題を呼んでいた。そしてもちろん，C#がC#6.0 /.NET 4.6の環境に正式対応したことも大きなポイントだ。