［GDC 2016］Autodeskのゲームエンジン「Stingray」開発者が語る，その設計思想とは

　北米時間2016年3月17日，Autodeskは，「GDC 2016」にて，同社が提供しているゲームエンジン「Stingray」に関する講演「Technical Introduction to the Autodesk Stingray Game Engine」を行った。本稿ではStingrayの開発者が説明した設計思想などを紹介したい。

Niklas Frykholm氏（System Architect，Autodesk）

　Stingrayは元々，本講演の登壇者であるNiklas Frykholm氏と，Tobias Persson氏が2009年に開発したゲームエンジン「Bitsquid」をベースにしている。
　Bitsquidは，Windows PC以外に，PlayStation 4やXbox One，iOSにAndroidなど，マルチプラットフォームに対応しており，特定のジャンル用ではない汎用のゲームエンジンとなっていた。その開発会社がAutodeskに買収されたことで，Autodesk製品との親和性を高めつつ，全体的にブラッシュアップされたゲームエンジンに生まれ変わったのがStingrayというわけだ。

　その特徴というか，設計思想として追求されているのは，

• データ駆動型であること
• 軽量であること
• 迅速な反復開発に向いていること
• そして高性能であること

である。ゲームエンジンはかくあれかしというこだわりの部分だ。

　まず，データ駆動型とはどういうことかというと，データの種類によって処理が変わるということだ。「エンジンの機能というのは，固定して記述するべきではない」とFrykholm氏は語っている。データの種類によって処理を切り替えるようにしておくべきというのだ。
　なぜそのようにするかというと，ひとつには柔軟性が高くなるとかいろいろ理由は挙げられているのだが，「ゲームエンジンの機能を特定の使い方に固定すべきではない」という，Stingrayにおけるポリシーのようなもののほうが，大きく作用しているようにも思われる。


　そのための方策として，いくつかの事項が挙げられているのだが，筆頭にきているのがデータフォーマットだ。マージを簡単にするために，JSON（JavaScript Object Notation）型のテキストファイルにするとある。ちなみに，XMLではダメなのだそうだ。
　実は，同じGDC 2016で解説セッションがあったKingのゲームエンジン「Defold」でも，まったく同じ話があった。目指しているエンジンの方向性も似ているのだが，データはすべて可読性の高いテキストフォーマットにして，マージを簡単にするといった方針は，両者に共通しているものである。

　また，「特定ゲームのためのシステムは作らない」という方針も明らかにされた。たとえば，武器システムやキャラクター管理，インベントリなど，専用機能が最初からあると便利そうな要素はあるのだが，それらはエンジンが提供すべきものではない，というのがFrykholm氏の考え方である。
　歩くと足音がする動作を実現するときに，歩く動作のところで再生音を一緒に指定するような仕様にするのではなくて，歩く動作をトリガーとして，ほかの処理を起動できるようにするといった実装が，Stingrayの基本方針とのことだ。

　データストリーミング機能を実装する場合も，例として挙げられた。オープンワールド型のゲームでは，2次元の座標で新しいエリアの情報を動的に読み込むような仕様が必要とされるが，レースゲームになると，1次元で前方のデータを逐次先読みしていくようなものが要求される。また，RPGならば，クエスト進行中に次のクエストを読み込むような仕様が要求されるといった具合だ。
　それぞれのゲームによって，異なるデータストリーミングの実装が求められるので，それらのどれか，あるいはすべてに個別対応するのではなく，すべてに対応できる基本的な仕組みを提供して，あとは開発者に任せるべきであるというのが，Frykholm氏らがStingrayで選択した手法である。


　Stingrayの特徴の1つでもある，ビジュアルスクリプト言語「Flow」の説明も行われた。Flowとは，プログラマ以外の人でも簡単な処理を記述できるようにと作成された言語であり，データ駆動型なのは当然として，C言語やLUAによって拡張可能な仕様に作られている（※LUAによる拡張は，3月15日掲載のイベントレポート記事を参照してほしい）。

　用途を特定しないという方針は，「ゲームエンジン」という立ち位置にも影響を与えている。すでにStingrayは，建築分野で使用されているほか，今後もさまざまな用途で使われていくことが予想されているそうだ。

建築分野におけるStingrayの使用例

　2番めの設計思想である軽量性については，「エンジンのコードは少なければ少ないほど，シンプルであればあるほどよい」という開発者の理念に基づくものだ。少ないほうが読みやすく，改造しやすく，拡張しやすいとFrykholm氏は語る。

「コードは素材じゃなくて借金みたいなものだ。少ないほうがいい」とFrykholm氏。深い……

　コードを減らし，システムをシンプルに保つためのキーとなるのが，プラグインシステムだ。C言語のアプリケーションバイナリインタフェース（Application Binary Interface）を採用しており，Autodeskの各種ミドルウェアをすでに利用可能であるほか，さまざまな言語で開発が可能だ。
　ただ，「小さくするだけではなく，シンプルに保つことが重要なのだ」と，Frykholm氏は指摘している。


　ただ，シンプルにするほどよいとはいうものの，「概念上のシンプルさは必要ない」（Frykholm氏）とも語っている。たとえば，テンプレートライブラリを使って全体をシンプルな構成にすることはできるかもしれないが，実体はまったくシンプルではない。
　逆に，コアになるデータ構造や概念は場合によっては導入する価値があるとのこと。もちろん，必要以上に複雑なものは不要であるとのことだが。


　Stingrayが採用しているコレクション系のデータ構造は，配列，ベクトル，ハッシュセット，ハッシュマップ，双方向キューの5種類だけである。文字列すらないわけだが，文字列は常にchar型へのポインタで扱われるとのこと。

　3番めの設計思想である迅速な反復開発については，「ソースコードやデータに加えた変更は，即座に実機上でも確認できるべきだ」という考え方によるものである。
　Stingrayは，複数の機種で同時に検証できたりなど，実機での動作検証についてのサポートがとくに厚い。それもこういった理念に基づくものであるのは自明だろう。


　修正から確認までの時間が短縮されれば，単位時間でより多くの修正を加えることができ，結果的に製品のクオリティを高めることができる。また，実機上で動くものを簡単に確認できるなら，プロジェクトの進行度などについても理解が深まるとしている。


　Stingrayで開発効率を挙げる手法としては，「インクリメンタルコンパイル」が採用されている。最初の1回は全体をコンパイルするものの，そのあとは修正部分だけのコンパイルで動作を確認できるため，ほとんどの場合はコンパイルが0.1秒以内に完了するという。
　また，対象となるデバイス実機とのリンク機能により，すぐに実機上での動作が確認できるほか，最初に挙げたデータ駆動型とあいまって，より迅速な開発サイクルが確立されているとのことだった。

　最後の設計思想となる高性能の追求だが，これは「エンジンは性能について妥協すべきではない」という考えに基づくものである。なぜなら，「ゲームエンジンの技術というのは，性能についてのものだから」（Frykholm氏）と明快だ。

性能改善について，キャッシュやスレッドを使えはともかく，ハードウェアを抽象化するなとか，割と力技系のテクニックという気もする

　さて，このような思想で作成されたStingrayだが，今回挙げられていないAutodesk製品とのリンクも考慮すると，ゲームの開発効率を大きく上げてくれそうな期待を抱かせてくれる存在ではある。今後のゲームエンジン業界でどのような立ち位置を確立するのかに注目したいところだ。

Stingray 公式Webページ（英語）

4Gamer GDC 2016関連記事一覧