ニュース
続報：新型ゲームエンジン「Stingray」とは一体何なのか？
CEDEC2015で日本の開発者に初披露
（2015/9/2 17:53）
- 8月26日～28日開催
- 会場：パシフィコ横浜
日本オートデスクは、8月26日～28日に開催された開発者イベントCEDEC2015にて、同社の新ゲームエンジン「Stingray」に関するセッションを行なった。セッションには、立ち見がでるほど大勢の開発者が詰めかけ、筆者が予想した以上に「Stingray」に対する関心の高さをうかがわせた。
本稿では、日本オートデスクで同社のミドルウェア製品の技術サポートを担当する梅澤孝司氏によって26日に行なわれたセッションの模様と、翌27日に、米Autodeskの事業開発マネージャー、Ben Mowery氏に対する単独取材で得られた情報をお伝えする。
「Stingray」は実質月額4,000円!?
26日の「新しいゲームエンジン Autodesk Stingray の紹介」と題した梅澤氏のセッションは、国内で初めてのお披露目となった。セッションのうち「Stingray」の機能の概要は、既報のとおりで、すでにGDC Europe 2015、SIGGRAPH 2015での発表や、公式サイトで公開されている映像の内容を超えるものではなかったが、梅澤氏によって丁寧に紹介されていった。
紹介された「Stingray」の機能のなかでも、同一のStingray PBSシェーダーを割り当てさえすれば、「Maya」、「3ds MAX」、「Maya LT」でシェーダーパラメータを編集することも「Stingray」で編集することも可能で、しかも1クリックで相互に転送できるアドバンテージはやはり大きい。しかも「LT」を含む「Maya」では、Stingray tone-mapの設定を行ない、ビューポートのガンマを「Stingray」に合わせて、色空間まで同一にすることができる。また、リソースの更新があってもリビルドすることなく、すぐさまライブアップデートによりターゲットデバイスで実行確認できるのは、非常に便利な素晴らしい機能と言っていい。
その他にも、機能面において「Stingray」にはAutodeskが持つゲーム用ミドルウェア「Gameware」の機能が惜しみなく投入されている。「Navigation」によるナビゲーションメッシュを用いたパスファインディングや、UI作成環境「Scaleform Studio」の原型「Scaleform」、GIライティングの「Beast」は、すでに「Unity」や「UnrealEngine」にも組み込み可能となっているもので、実績としては十分だ。
「Flow Visual Graph」と名付けられたビジュアルスクリプティング環境も有用だ。ビジュアルスクリプトそのものは、「UnrealEngine」エンジンにも採用されていて目新しいものではないが、普段3Dモデルに対するマテリアル設定をノードベースのビジュアルエディタで行なっているアーティストにとって、テキストベースのスクリプティングより圧倒的に親しみやすいと思われる。こういったところにもアーティスト向けを標榜する「Stingray」の思想が現われている。
もう1つ本セッションの内容で特筆すべきは、梅澤氏が、すでに海外フォーラムで許容するコメントがある通り「Maya LT」の正規ライセンス契約ユーザーが現実に「Stingray」ライセンスを有効に利用できてしまうことを、日本オートデスクとしても“公式に”認める発言を行なったことだ。
8月27日現在、日本オートデスクは、日本において「Stinigray」ライセンスの単体版を月額5,000円で販売しているのみで、「Maya LT」バンドル版を販売していない。ところがこれは、実現のレトリックは異なっていても、月額4,000円の「Maya LT」に「Stingray」がバンドルされるということと実質的に等価だ。日本において「Maya LT」バンドル版「Stingray」の発売日について“近日”としかアナウンスがないが、今すぐに「Maya LT」のライセンス契約をしても、「Stingray」単体版のライセンス契約をするより月額で1,000円安く“お得に”利用できることになる。4,000円なら、現在の為替相場でアメリカの月額30ドルと比較しても、ほぼ同水準の料金設定で、日本のユーザーにとって嬉しいニュースと言えるだろう。
「Stingray」と言う名のミドルウェア群
翌27日には、前日に講演を行なった梅澤氏と共に、米Autodesk事業開発マネージャー、Ben Mowery氏を交えてのミーティングが実現した。Mowery氏は、元々Autodeskに買収されたScaleformの出身で、現在は「Stingray」を始めとするゲームウェア全般のサポートを担当している人物だ。アメリカ人でありながら中国を中心としたアジアでのビジネスに明るく、今回も上海から日本へと駆けつけてくれた。
ミーティングでは、まず梅澤氏に昨日のセッションでは時間の関係で触れられなかった「Stingray」の機能の解説をお願いした。ここで梅澤氏が解説してくれたのは大きく2項目で、どちらもグラフィックスに関する機能だ。
ひとつ目は、リアルタイムにポストプロセスエフェクトをかける機能で、反射を表現するスクリーンスペースリフレクションや、強い光を表現するグレア、やわらかい影表現のソフトシャドウ、カメラの被写界深度を表現するデプスオブフィールド、スミの光の届きにくい部分の影を引き締め光源の影響のリアリティを高めるスクリーンスペースアンビエントオクルージョン等を、実際にパラメータを変化させながら見せてくれた。これらの他、レンスの歪みやヴィグネット、レンズカラー、ブラーやブルーム、カラーグレーディングといった一通りのエフェクトが揃っており、同様にパラメータを変化させて絵作りの調整をすることができる。
もう1つは、描画パフォーマンスを稼ぐために、あらかじめライトおよびシャドウをベイク（焼き付け）する機能で、こちらは「Beast」を起動して行なう。ランタイムにおいて「Beast」によってベイクされた光と影の品質は良好で、地下鉄駅構内を模したデモを見る限りでは、特に問題なく表現できているように思えた。
デモはあくまでデモ用のデータを用いたものであるため、実際のゲームの描画品質とパフォーマンスの検証は必要であるものの、デモを見る限り、「Stingray」は、確かにAutodeskが言うとおり、軽量でありながらモダンなグラフィックス品質のゲームが開発できるゲームエンジンであると感じられた。
一方で、物足りない部分も見受けられた。ミーティングのなかで、筆者は梅澤氏に対してデモで用いられている「Stingray」上のレベルをシーンデータとして、そのまま「Maya」に転送するようリクエストしてみたのだが、それはできないのだという。「Maya」や「3ds MAX」といったDCCツールで取り扱うことができるのは、あくまでアセット単位のグラフィックスデータなのだ。複数のアセットを配置してレベルを構成するのは、あくまで「Stingray」の仕事だ。アセットの構成を保持したままレベルをまるごと転送して、レベルとアセットの関係をアーティストが意識することなくグラフィックスデータの作り込みができると思ったのだが、どうもそういうことではないらしい。Autodeskの製品同士ということで、どうやら筆者は「Stingray」に対して過度の期待をしていたようだ。ここまでの解説でようやく冷静に理解することができた。
となると、「Stingray」を用いたゲーム開発ワークフローは、競合エンジンのそれと比較して特段に違ったものになるわけではない。「Stingray」と「Maya」、「3ds MAX」との連携において、データの再現性や可搬性に優れ、パラメータ調整レベルの作業はどちらでも可能、リアルタイムのカメラ同期やアセットデータのバックグラウンド転送が可能、といったアドバンテージは大きいものの、製作のワークフローを大胆に革新するようなものではない。逆に言うと、大きな違いがないわけだから、競合エンジンを活用した既存のプロジェクトのワークフローを、そのまま置き換え可能であるということにはなるだろう。
結局のところ、現在の「Stingray」スイートは、ゲームロジックと3D描画を司るコア部分の「Stingray」に、ゲームデータを製作するために有用なツール、ミドルウェア群をバンドルしたものに過ぎない。確実な連携は期待できるものの、統合の度合いは決して高いとは言えず、つぎはぎ感が目立ってしまう。これは、Autodeskに買収された各ツールの開発チームが、今までは社外の顧客を相手にビジネスをしてきたことと、世界各地に散らばるそれぞれの拠点で、ある程度の独立性を確保したまま開発してきたことに起因していると思われる。もっとも、個別のミドルウェアとして分離されたままであるがゆえに、個々のミドルウェアが他の開発サイクルに引きずられることがなく、それぞれで新機能の実装やバグの改修が容易になるというプラスの側面もあるだろうから、必ずしもひとつに統合されていないことが悪いわけではない。ただ、「Stingray」という単一の製品名でリリースする以上、今後のアップデートでのさらなる統合の深化を望みたい。統合により開発ステップがひとつでも削減されることは、どの開発者も常に望むことであり、「Stingray」にとって競合との差別化を図る強力な武器となるはずだからだ。
将来のアップデートと課題
今後のアップデートについては、個別ミーティングでもあまり明確な情報を得られなかった。フロントエンドを「Maya」や「3ds MAX」と統合して、ビューポートを「Stingray」のものと置き換え可能にしたり、完全に「Maya」や「3ds MAX」の中から「Stngray」を触れるようにならないのか、「Scaleform Studio」で製作したUIオブジェクトに対するイベントを3Dオブジェクトに対するイベントと区別せず、一貫してビジュアルスクリプトでコーディングできるようにならないのか、といった質問とも要望ともつかない話題を振ってみたが、Mowery氏からは、「同感だ」、「良いアイディア」だ、とのコメントは得られるものの、現時点ではさらに統合を深化させるような具体的な計画を聞くことはできなかった。
唯一、Mowery氏から力強い回答が得られたのは、チーム内のコミュニケーションに関する機能で、非常に近い将来、「Stingray」環境を実行するデスクトップ間で、メッセージチャットをサポートする計画があるとのことだ。これは「Stingray」エンジンそのものの開発にも活用されている機能で、前述の通り、世界各地に分散するチームメンバー間のコミュニケーション促進や、メンバー同士がソースコードやリソースのありかの”リンク”を正確に受け渡すために有効だという。外部ツールでもできることではあるが、プロジェクトのソースコードやアセット管理と連携するものであれば、確かに便利な機能と言えるだろう。
サポートするプラットフォームの拡充についても質問をぶつけてみた。前日の梅澤氏のセッションのトーンから、対応するAndroidデバイスが「Tegra K1」採用機種、具体的にはNVIDIA「Shield Tablet」とGoogle「Nexus 9」のみにとどまっていることに対して、相応の危機感を持って重要課題として位置づけていると思ったからだ。ところが、Mowery氏のコメントは、モバイルデバイスの世代交代に応じて開発していけば時間が解決するといった趣旨のもので「Stingray」の現況を楽観的に捉えているように思えた。
確かに、3D主体のゲームでなければ「Stingray」を選択する意義に乏しく、まだまだ3Dゲームの実行に十分なハードが主流とは言えないだろうから、順次対応チップを増やしていけば解決する問題ではある。とはいえ、正式版リリースの段階で、最も普及しているQualcommのSnapdragon内蔵GPU「Adreno」をサポートしておらず、今後のAndroidプラットフォームのチップ対応予定について言及を避けたのは、なかなかに厳しい。
サポートするプラットフォーム拡充の話題の流れで、PCプラットフォームにおいて、DirectX 9をサポートしていないことから、レガシーなPCをサポートする計画がないことも聞くことができたが、Windows 10がリリースされDirectX 12サポートが関心事となっている昨今、Windows 7(DirectX 11)以降がサポートされていれば、こちらはまったく気にすることはないだろう。iOSについて、Metal、OpenGL ES 3.0をサポートするiPhone 5s/iPad Air以降の対応であることも、同様にそこまで気にすることはないと思われる。プレイステーション 4やXbox One、Oculus Rift DK2をサポートしていることは好材料だ。
買収済みの各ツール群と一応の統合を果たし、一通りの機能を満たしているからか、外部のメジャーなミドルウェアやツールとの連携にバラツキがあることも気にかかる。サウンド機能としてAudiokineticの「Wwise」のライセンスを同梱しているほか、Algorithmicの「Substance Designer」で作成したプロシージャルテクスチャを適用することができたり、「Warhammer: End Times ・ Vermintide」の採用実績から、Umbra Softwareのオクルージョンカリングを組み込むことが可能であることはわかるものの、Interactive Data Visualizationの「SpeedTree」の組み込みには対応していない。今後は、このあたりの拡充も課題となりそうだ。
このように、いくつかの決して小さくない課題があるとはいえ、今後、早いサイクルでアップデートが行なわれ、内部、外部を問わず、急速に機能を充実させる可能性はある。「Maya」や「3ds MAX」の場合、多少前後することはあるものの、ほぼ1年に1度のバージョンアップ、バージョンアップの中間期にEXTENSIONのリリースサイクルが守られている。ところが「Stingray」に関しては、今回の正式版リリースがEXTENSIONのリリース時期と重なっただけで、「Maya LT」と同じく特にバージョンアップ時期を固定しているわけではないという。後発のゲームエンジンだけに、競合に追いつけ追い越せの勢いを期待したい。
「Stingray」を採用する価値はあるのか
日本国内で、すでに「Unity」や「Unreal Engine」が先行するなかで、ゲーム開発者は、この「Stingray」をどのように考慮に入れていけば良いだろうか。「Stingray」は、時間をかけてトップ品質のゲームを追求するプロジェクトではなく、及第点のゲームを限られた時間で開発するプロジェクトにフィットする。体験版を試用したうえで、自分たちのゲームの要求仕様を「Stingray」を使って満たすことができ、しかも製作プロセスの”お作法”が肌に合うなら、有力な選択肢となり得るだろう。競合からの移行の場合でも、増加するコストと削減できるコストを勘案して、メリットがあれば移行すれば良いように思う。1カ月という評価期間が短いようなら、月額4,000円という比較的リーズナブルな料金であるわけだから、必要なだけの利用料を支払って評価期間を延長することもできるだろう。
ただし、現時点で進行中の商品化プロジェクトの“乗り換え”は、リスクが大きいように思う。パッケージゲームやダウンロード売り切り型のゲームなら問題ないかもしれないが、F2Pゲームの場合、少なくとも日本国内において、「Stingray」サポートを表明している配信、広告、課金に関するソリューションプロバイダは存在せず、商品としてリリースする道筋が今ひとつ見えないからだ。
自己のゲームが要求する仕様とゲームエンジンが提供する機能にギャップが生じた場合、ゲームそのものに関することなら、ゲーム仕様を変更するなり、あきらめて仕様をカットするなりして、何とか自分たちで解決できるだろう。ところが、ディストリビューション、マネタイズとなると話は別だ。プロバイダ側の指定する“お作法”に対応できないとあっては、商品として発売できないことになってしまう。ゲームそのものが完成したとしても、エンドユーザーに届けられなければ意味がない。資金力のある大規模スタジオならC++ソースコードライセンスの許諾を得て、自前でなんとでもできるだろうが、「Stingray」がメインターゲットだとするインディーや小規模開発チームが問題なく対応できるようになるかどうかは、現時点では不明瞭だ。
一方で、プロジェクトの目的が、必ずしも商品として販売するということをゴールに置いたものでないなら、「Stingray」を採用する意義は十分にあると考える。アーティストのみのチームがインタラクティブなデモンストレーションやプレゼンテーションを行ないたいというニーズに十分応えられるものだからだ。商品化の可能性を検討する初期段階のプロトタイピングにも役に立つだろう。
また、商品化を目的にしたプロジェクトだとしても、リリースを急がない長期的視野に立った開発を行なえるディベロッパーには是非採用していただきたい。あくまで筆者の受けた印象ではあるが、Mowery氏の話から、「Stingray」エンジンの開発は、あまり競合との相対的なポジショニングを気にしておらず、よくあるミドルウェアの事例と同じく利用者の要求に応じて駆動しているように思えた。この手の開発スタイルの場合、いち早く実際の利用者となって要求を起こしていかないと、いつまでたっても自分たちに必要な実践的な機能が実装されない可能性がある。
一方の日本オートデスクに対しても、ニワトリタマゴの話にならないように、大胆な販売施策を講じるとともに、潜在的なものも含めて日本のニーズを積極的に収集し「Stingray」開発チームにぶつける”攻め”の姿勢を望みたい。