ニュース

【特別企画】モバイルゲームエンジンの覇者「Unity」はどこへ行ってしまうのか!?

新機能満載の「Unity 5」のリリースを受けてデベロッパーが想うこと

4月13日~14日開催



会場:ホテル日航東京

 ユニティ・テクノロジーズ・ジャパンは、恒例の「UNITE 2015 TOKYO」を、4月13日、14日の両日、東京台場のホテル日航東京で開催した。今回の『UNITE 2015」は、3Dゲームエンジン「Unity」が3月にバージョン5になって日も浅いうちのイベントということもあって、有料のイベントにもかかわらず、ざっと1,000人は開発者が詰めかけており、「Unity」を利用する開発者の裾野の広さをうかがわせた。

 今回筆者は、「Unity」の伝道師、ユニティ・テクノロジーズ・ジャパンのエバンジェリスト高橋啓次郎氏のセッションとワークショップに加え、「MEVIUS FINAL FANTASY」(スクウェア・エニックス)のリードプログラマ浜口直樹氏のゲーム開発事例、同じく実例として「白猫プロジェクト」(コロプラ)のクライアントサイドプログラマ池田洋一氏およびサーバーサイドプログラマ廣本洋一氏のセッションなどを聴講した。いずれのセッションからも、登壇者それぞれのプロジェクト内の役割や所属する会社での立ち位置からみた、それぞれの「Unity」に対するスタンスが感じられ、非常に興味深いものであった。

 本稿の前半では、「Unity」がバージョン5になったことで追加されたグラフィックスの新機能を高橋氏のセッションを通じて紹介する。後半では、ゲーム実例やその他技術的な内容のセッションを受講したことを踏まえて、新ためて筆者が感じた「Unity」に対するインプレッションと、来場者の聴講の様子や会場の雰囲気から感じられた温度感を、率直にまとめていきたい。

【登壇者】
ユニティ・テクノロジーズ・ジャパンのエバンジェリスト高橋啓次郎氏
スクウェア・エニックス「MEVIUS FINAL FANTASY」リードプログラマ浜口直樹氏
コロプラ「白猫プロジェクト」クライアントサイドプログラマ池田洋一氏
コロプラ「白猫プロジェクト」サーバサイドプログラマ廣本洋一氏

 「Unity5グラフィックス機能使いこなしガイド」と題した最初の講演で、高橋氏はライティングの追加機能と新規実装のグローバルイルミネーション(以下、GI)の大きく2点に絞って非常にわかりやすく伝道していた。限られた時間にもかかわらず実演を交えて行われた講演内容は、駆け足ではあるものの密度の高いものであった。

 まず、ライティングについては、「Unity5」では環境光表現として、従来からある単一カラーのアンビエントライトに加え、スカイボックス、グラディエントと合計3つのオプションから選択できるようになった。選択肢が3つになったこと自体は、それほど大騒ぎするような目玉機能ではなく、むしろもっと前からあっても良さそうな小技の機能だ。通常、敢えて空の色と違和感のある光源色を指定する必要はないだろうから、デフォルトでスカイボックスから自然な光源色が得られるのは、地味に便利になったと言える。

 グラディエントは、使い勝手の良さそうな設定で、例えば、足元がうっすらと青や紫がかった幻想的な雰囲気を醸し出したり、薄暗い空間で足元だけが真っ赤に光っているような不気味な味付けをしたい場合、空間の上部、地表面付近、下部に任意のカラーが設定できるグラディエントが役に立つだろう。デフォルメを効かせた絵作りで、リアリティをさほど重視せず、落ち影も丸影で十分だとすれば、グラディエントを指定したアンビエントライトだけでも、まずまず十分に演出できる。後述するGIのように、本格的なライティングはレンダリング負荷が大きいのに対し、アンビエントは負荷が非常に小さい。これは制約の厳しいスマートフォンやWebゲーム向けの改良と言っていいだろう。

アンビエントライトにグラディエントを指定した状態。上部はに赤、地平に緑、下部に青のカラーを与えている
剣、盾、斧、石板などが空間内の3Dオブジェクト。背景はスカイボックスに貼り付けたHDR画像。ちょっとわかりにくいがイメージのカラーから光源の影響を受けている

 アンビエントカラーのソースとして利用できるようになったスカイボックスについては、スカイボックス自体をパラメータからプロシージャルに生成する機能と、スカイボックスにHDRパノラマ写真をテクスチャとして貼り付けて、そのイメージから適切なライティングを施してくれるイメージベースドライティングの機能が加わった。いずれも作業コストが安く、手軽に一定のクオリティに引き上げられるのが特徴だ。

 ディレクショナルライトが作り出す影生成条件のオプションや影品質の改善にも手が入っている。とりわけ影落としを行なう条件のオプションのうち「Shadow Only」が最もゲームらしい活用法が考えられる。例えば、キャラクターが自分の身体を完全に透明化する能力を持っているとして、その能力を使用して透明人間になっているけれども、なぜか影だけは地面に落ちてしまうといった設定の表現や、実体は人間の姿をしているが、影を見ればその正体は世にも恐ろしい悪魔……といった表現に活用できそうだ。

 影品質を向上させるため、キャラクター等のダイナミックオブジェクトには5×5フィルタリングのPCFソフトシャドウ、背景等のスタティックオブジェクトには光源からの入射角の範囲を指定する機能と、双方に異なったアプローチのソフトシャドウを実装して影のキワの柔らかさを表現している。その他、影の計算精度に起因するモアレノイズを低減するために、オブジェクトを縮小するようにバイアスをかける「Normal Bias」が併用できるようになっていたり、シーンビューでどのオブジェクトの影がどのシャドウマップのカスケードを使用しているかを視覚的に確認できるようになっている。

ダイナミックオブジェクトに対するPCFソフトシャドウ。改良前が左、改良後が右側
スタティックオブジェクトに対するベイクドソフトシャドウ。入射角の設定によってキワをぼかす量を変更できる

 続いては、「Unity5」の目玉機能のひとつ、リアルタイムGIについて。GIとは、ざっくり言うと間接光表現のことで、より現実に近いリアルな絵作りをするために、直接光が物体に当たったときの光の照り返りをもシーンに反映させることである。「Unity5」でGIを効かせるには、移動しないスタティックなオブジェクトが対象の場合、オブジェクトにスタティックであるという属性を与えるだけで良い。ラジオシティ技法のひとつであるGeomericsのEnlightenテクノロジで、「間接光のもと」があらかじめ計算されデータとして格納される。

 一方で、移動するダイナミックなオブジェクトに対しては、何もしないとGIは有効にならず薄暗く表示されてしまう。それでは困るので、ダイナミックオブジェクトに対してGIを効かせるためには、ライトプローブを空間に置く必要がある。このライトプローブは、実際のゲーム画面には表示されないもので、スタティックオブジェクト同様に「間接光のもと」を、あらかじめ計算しデータとして格納するために用いられる。ダイナミックオブジェクトは、このライトプローブの計算結果を拝借して、自己の間接光影響を決定している。こういった要領で、リアルタイムと言っても、複雑な計算はあらかじめ行なっておき、ゲーム中は実際にライトが当たった際に「間接光のもと」を間接光として目に見える状態にしてやるということに限ることで、処理負荷を軽減している。

グローバルイルミネーションを効かせたシーンにたたずむユニティおじさん
GIを効かせるためにエディタ上でライトプローブを配置する。黄色や水色の球体がライトプローブ

基本的なGIの概念図。光源からの直接光が反射して関節腔となりオブジェクトに伝播していく

 ただ、「Unity5」が採用するGIの方式にはいくつかの弱点が存在する。1つ目は、「Unity5」の方法論だけでは、スペキュラ、つまり反射面が正しくレンダリングされず、真っ黒になってしまうことだ。そこでスペキュラ表現のために、空間中にリフレクションプローブを配置する必要がある。リフレクションプローブを配置すると、スペキュラを効かせた部分に光沢が乗るだけでなく、自動的に反射面に写り込む環境用のキューブマップを生成してくれる。この機能は手軽で便利だが、リフレクションプローブの設置が必須なら、新規シーンを作成した際にデフォルトでシーンの中心に1個生成してくれるくらい気を利かせてくれても良さそうに思える。

 2つ目の弱点は、標準の「Non Directional」モードでは、物体表面の凹凸を表現するノーマルマップが無視されてしまうことだ。ノーマルマップは、特定の一方向から光が照射されていることを前提にしているため、シーンのライティング設定に「Directional」の属性を与え、もっとも強く影響を与えている直接光に代表させ、間接光を無視するようにしなければならない。さらに、スペキュラを使用する場合には、「Directional Specular」を設定して、代表させる直接光と代表させる間接光それぞれ1つずつを与える必要がある。この「Directional Specular」が「Unity5」のシェーダー性能を最大限に引き出すモードとなる。

 ただし、「Directional Specular」モードは万能ではない。最もデータサイズが大きく、最も処理負荷の大きいモードであるばかりか、あくまで特定の方向からの光を直接光と間接光として代表させるため、シーンの状況によっては、必ずしも適切ではないレンダリング結果となってしまうこともある。先述したリフレクションプローブを設置すれば、「Directional Specular」モードを使わなくても、スペキュラは適切にレンダリングされるため、このモードへの過信は望ましくないと高橋氏はコメントしていた。要するに、ノーマルマップが存在しないなら「Non Directional」、存在するなら「Directional」モードというのが最適なのだろうが、それならプロジェクトに取り込んだモデルリソースからノーマルマップの適用状態を調べて、スマートに判定してあげても良さそうだが、こちらも幾分気が利いていない。

 最後に高橋氏は、リフレクションプローブをシーン内に複数設置した際に関心を払うべき事項を4つ付け加えた。1つ目は、リフレクションプローブとリフレクションプローブの中間を物体が通過する際の切り替わりブレンド、2つ目は、鏡面同士の合わせ鏡のような状況の問題を回避するための反射回数の設定、3つ目は、ランタイムで動的に更新する場合の環境用のキューブマップの更新頻度、4つ目は、ボックスプロジェクションの有効活用の検討だ。

 いずれも細かいことだが、きっちりやっておかないとパフォーマンスや見た目に影響する項目で、個々のゲームが重視するポイントやシチュエーションによって、どの設定値にするか一概に決められないのは理解できるが、もう少し現実的なデフォルト値にするとか、いっそのこと開発ユーザーは容易に変更できないものとして、ターゲットプラットフォームの振り分けの段で決め打ちにしてしまっても良いように感じられた。実際のところ、「Unity」には最適解をアプリケーション側に求める設定値が意外と多い。新機能が実装され高級なことができるようになったのは喜ばしいが、大まかには自動でよろしくやってくれるものの、肝心のかゆいところは自分でかいてください、といった事項が増えている。

左の写真の樽にはセカンダリマップがなく、右の写真の樽にはセカンダリマップが貼られている。ディティールが異なることがわかる

 「Unity5グラフィックス機能使いこなしガイド実践編」のワークショップは、大部分がバージョン4から存在したものの活用テクニックの解説や細かい改善点であったため、ここでは「Unity5」からの新実装であるスタンダードシェーダーについてだけ触れておきたい。

 スタンダードシェーダーは、ほとんどの質感を統一的に取り扱うことができるというまさに標準のシェーダーで、流行りのPBRつまり物理ベースのレンダリングを行なう。品質向上に有用なのはセカンダリマップの設定で、物体の全体にマッピングしたテクスチャに加え、カメラが寄った時のディティールをマルチテクスチャとして重ね合わせ、リアリティを向上させる。

 モバイルのためにスタンダードシェーダーは内部で3つの動作モードに振り分ける処理を行なっており、具体的にはDesktop、OpenGL ES3.0,Metal、OpenGL ES 2.0の3つのAPIから搭載するGPUによって適切なものに自動的に切り替える。振り分けをすることで、非力なGPUを搭載するデバイスでも、さほどレンダリング品質を落とさずに処理負荷を軽減しながら実行することができる。機種依存性をエンジン側が吸収し、一部の例外的な質感表現以外は、ゲーム側で特段に意識することなく取り扱うことができるのは、良い方向と言えるだろう。

Desktop、OpenGL ES3.0,Metal、OpenGL ES 2.0それぞれのレンダリング結果。低スペックでもパフォーマンスを維持するために計算精度を落としているとのことだが、ほどんど違いがわからない

 「Unity5」に実装されているモダンなフィーチャーの数々を見るに、ついに「Unity」もここまで来たかといった感がある。筆者が「Unity」を初めて知った約6年前には、「Unity」はモバイルプラットフォームをサポートしておらず、ブラウザゲーム用の3Dエンジンとしてのものだった。経産省主導のコンテンツビジネスマッチングイベントで「Unity」売り込みのプレゼンテーションを受け、自分のデスクトップPCでサンプルファイルを実行して数日断続的に評価はしてみたものの、「Unity面白いことになるかもな」と思っても積極的に取り組むことはなかった。今思えば、なんと先見の明のないことか。

 「Unity」では、ゲームをプレイするために専用の「Unity」プレーヤーのインストーラーをダウンロードしてインストールしなければならない。FlashプレーヤーがOS同梱ブラウザにバンドル配布されていたことと比較して、お世辞にもエンドユーザーがプレイ環境を導入しやすいものではなかった。そのことを大きな問題点として、評価させてもらったお礼の言葉と共にフィードバックしたように思う。当時はブラウザゲーム用のプラットフォームとしてFlashベースのものが大多数を占めており、また、いくつかのブラウザ向け3Dエンジンのように「Unity」がFlash内で動作しなかったのも弱点に思えた。

 ところが、その後、「Unity」は、瞬く間にサポートするプラットフォームを増やし、Facebookと連携し、ついには急速に普及したスマートフォンのスタンダードなゲームエンジンとなった。PC用のGPUに特化した高機能で高品質なハイエンドエンジンと比べると機能不足は否めないが、軽快でゲームが作りやすいことが幸いした結果だ。安価に開発環境一式を買いきりで導入できるというビジネスモデルも追い風となった。機能制限がかなりあったものの、無料版の開発環境を用意したのも大きいだろう。わずか数年で開発事例は膨大な数に達し、ヒット作が続々と生まれた。「Unity」は、面白いゲームをプレイするためにエンドユーザーはインストールの手間など厭わないということを証明してみせた。筆者が実際に「Unity」を開発に使用するころには、スマートフォン開発といえば「Unity」前提が常識といった状況にまでなっていた。

 その一方で、本稿の前半で紹介した新機能のほとんどは、すでに競合するゲームエンジンがサポートしている内容であり、特に目立った新規性はない。むしろ数年、いや十数年前から新しいハイエンドGPUがリリースされる度にハードウェアの新機能として取りざたされてきた機能を「Unity」がようやくサポートしただけの話だ。ハイエンド側からローエンド側へとサポートするハードウェアを広げてきた競合エンジンや、有力デベロッパーがインハウスで使用している内製エンジンの方が「Unity5」の実装アルゴリズムよりモダンなものも多い。

 モバイルプラットフォームでのビジュアルクオリティ向上の期待感は確かにあるが、現時点ではGIの各要素について、モバイルでサポートされない新機能が多いのが気にかかる。やれるところからやっているだけのことなのだろうが、まさに今、最も支持を集めているプラットフォームを優先しないでどうするんだと思ってしまう。「Unity5」がキーフィーチャーとして喧伝している方向性は、PS4やPCネイティブプラットフォームにおいて、なんとか競合に見劣りしないように頑張ってます、というポーズに感じられて仕方がない。

2010年5月のニュースレター。共同創業者で当時のCEO、David Helgasonがまだ自分でメール原稿を書いている。登録ユーザーは13万人でバージョン3のプレオーダーや実装中のプラットフォームの話題が中心

 それでもなお、強いて“高級化”に意義を見出すとすれば、現在スマートフォンをターゲットに「Unity」を用いている開発者が、「Unity」の進化に歩調を合わせ、常にエンジンを限界まで目一杯使い倒し、慣れ親しんだ統合環境を駆使しつつも、機種依存を排した美しいコードを内に秘め、完全に同一のビジュアル、完全に同一のゲームデザインを引っさげて、新規参入障壁の高いコンソールゲームに殴り込みをかける姿が見られるかもしれないということだろうか。

 これはこれで理想的だと思うし、是非そうしたタイトルが現われて欲しいと思う。結局のところ「Unity」はゲームエンジンであり、ハードウェアでもローレベルなAPIでもない。ハードウェアベンダーはハードウェアベンダーの商業的成功のために、販売価格との兼ね合いで多様なチップの仕様を策定する。全体的にチップ性能が向上する方向にシフトしていくとしても、ハイエンドからローエンドまでのラインナップが縮まる訳はなく、ましてや無くなる訳はない。「Unity」の内部で処理を振り分け、多様なハードウェアでなんとか動作するようにフォールバックしていても、ハードウェアやAPIの性能差を均一にしてくれる魔法の箱ではないのだ。

 ハードウェアが競合との差別化を図り続ける限り、また「Unity」がそうした幅広いプラットフォームをサポートし続ける限り、比較的性能の低いハードウェアでトップクラスであったとしても、そのままではハイパフォーマンスなハードウェアでトップクラスのポジションに収まることはない。また、セールスマーケティング的な観点からも、クロスプラットフォーム展開する際には、エクスクルーシブな要素を入れない訳にもいかないと思われる。技術系開発者の理想とは裏腹に、プラットフォームの盟主から販売面での手厚い支援と優先的な待遇を受けるために、そうした条件はむしろ自分たちの方から積極的に提示することになるのではないか。そういった状況下で、現在のトップ開発者は得をするのだろうか。

 個人的には、こと「Unity」に関しては、垂直方向の進化、つまり高品位なビジュアルに追いつけ追い越せ方向の進化は、ほどほどで良いのではないかと思う。現状であれば、「Unity」の枠の中で高品質なゲームを目指したとしても、開発環境として取っ付きのいい部分があるおかげで、インディシーンを含め、平均的な開発者なら頑張ってついていけるレベルであると思われる。エントリーレベルの開発者にとっては、細かいことは知らなくても簡単にゲーム開発を始められるエンジンであり続ける。こなれたデベロッパーにとっては、期待通りに次々と品質を向上させる機能追加のリクエストに応える。「Unity」としては、いずれも等しく最大限やる、選ぶのはあなたたち、ということなのだろう。ところが、できることの幅が広がることで、せっかく獲得した幅広い層の開発者達がついていけなくなり、結果的にふるいにかけることになりはしないだろうか。「Unity」ユーザーは減っていってしまうのではないか。そうなってしまったら、Unity Technologiesは得をするのだろうか。

 リリースに向けた開発中のフェイズにおいては、たとえ開発人員や予算の規模が違っていても、競合する類似ゲームでやっていることを、自分たちのゲームでも何とか工夫して実現しないと負けてしまうような強迫観念に囚われてしまう。また、純粋に可能な限り性能の限界まで挑戦したくなるのが開発者の性というものだ。これらの心理が働いてしまった結果、自分たちの能力を見誤ってしまい、志半ばで轟沈してしまうプロジェクトが増えてしまうのではないだろうか。過去の例を振り返っても、できることが少ないうちは圧倒的な質と量でエンドユーザーを圧倒するようなゲームでなくてもヒットする可能性は少なくない。ところが、ひとたびプラットフォームが高性能を追求し始めると、見た目の優劣がつきやすくなり、見劣りするゲームは大きく減ってしまう。仮にリリースされたとしても、相場を下回るそれらのゲームはヒットしなくなる傾向にあるように思う。プレイすれば面白いものだったとしてもだ。そうなってしまったら、現在、そして将来のフォロワー開発者は得をするのだろうか。

 筆者が「Unity」に求めたいことはシンプルだ。原点に立ち返って、今「Unity」を支持している450万人の開発者を大切にして欲しい。モバイルゲームのうち中国で75%、日本で70%、韓国で60%、米国で50%のシェアを占めているという数字が意味するところを常に考えて欲しい。有力開発社の実例セッションに、多種多様な「Unity」開発者が立ち見がでるくらいに詰めかけ、おのおの熱心にメモを取っていたことに注目して欲しい。独自拡張による問題解決には、有力開発社だからできることもあり、多数の開発者がそれぞれ悩み、日々つまずきながら開発に取り組んでいること忘れないで欲しい。ユーザー開発社の登壇者から発せられた問題点とその対策は、詰めかけた多くの開発者にとっては、そのまま不満として自分で消化できないものであったように思われてならない。

 日本において、3Dのみならず、2Dゲームのプラットフォームとしても大きなシェアを握っている「Unity」に最も望まれていることは、より開発しやすい気の利いた環境、ローエンドなデバイスでも軽快に動作するエンジンであり続けることではないだろうか。ワンソースでWindows、MACから3DSやOculus Riftまで、22ものプラットフォームをサポートしうるゲームエンジンは他にはないだけに、他のゲームエンジンと同じ土俵でぶつかる必要はない。

「MEVIUS FINAL FANTASY」がぶつかった問題点と最適化のポイント
「白猫プロジェクト」がぶつかった問題点と最適化のポイント
「白猫プロジェクト」開発者が掲げる次回作でクリアしたい課題。実にあっさり書かれているが、普通の開発者が容易に手を出せるような項目ではない

(谷川ハジメ)