【CEDEC 2015】インハウスのゲームエンジンでスマホアプリを作ってみた~ガンバリオンの挑戦  | GameBusiness.jp

【CEDEC 2015】インハウスのゲームエンジンでスマホアプリを作ってみた~ガンバリオンの挑戦 

ゲーム開発 ゲームエンジン

【CEDEC 2015】インハウスのゲームエンジンでスマホアプリを作ってみた~ガンバリオンの挑戦 
  • 【CEDEC 2015】インハウスのゲームエンジンでスマホアプリを作ってみた~ガンバリオンの挑戦 
  • 【CEDEC 2015】インハウスのゲームエンジンでスマホアプリを作ってみた~ガンバリオンの挑戦 
  • 【CEDEC 2015】インハウスのゲームエンジンでスマホアプリを作ってみた~ガンバリオンの挑戦 
  • 【CEDEC 2015】インハウスのゲームエンジンでスマホアプリを作ってみた~ガンバリオンの挑戦 
  • 【CEDEC 2015】インハウスのゲームエンジンでスマホアプリを作ってみた~ガンバリオンの挑戦 
  • 【CEDEC 2015】インハウスのゲームエンジンでスマホアプリを作ってみた~ガンバリオンの挑戦 
  • 【CEDEC 2015】インハウスのゲームエンジンでスマホアプリを作ってみた~ガンバリオンの挑戦 
  • 【CEDEC 2015】インハウスのゲームエンジンでスマホアプリを作ってみた~ガンバリオンの挑戦 
2010年代はUnityやUnreal Engineといった商用ゲームエンジンの時代だと言えるかもしれません。その一方でインハウスのゲームエンジンにもメリットがあり、多くの会社で使われています。福岡に本社を置くガンバリオンもその一つで、C++ライブラリとツール群から構成された軽量にして必用十分な機能を持つ「JETエンジン」を、さまざまなプロダクトで活用しています。

もっとも、プラットフォームごとに仕様が確定しているコンシューマ機と違い、スマホアプリの開発は「言われているほど大変ではなかったが、OSや機種依存など独自の対応や準備が必要だった」とのこと。CEDEC2015で石井泰寛氏・森下宏樹氏・小田垣寛樹氏は「自社ゲームエンジンでモバイルゲームを作ってみてわかったこと」と題してポストモータムを行いました。

複雑な仕様だからこそ、慣れた環境で開発



従来のPS3・Vita・Wii U・3DSに加えて、新たにAndroidとiOSにも正式対応したJETエンジン。もっとも商用ゲームエンジンを否定しているわけではなく、要は適材適所だといいます。なお、JETエンジン開発の背景については、CEDEC2014「30~40人規模の開発チームでマルチプラットフォームタイトルをゲームエンジンから作った理由とその効果」で解説されています。

今回スマホアプリ『ワールドトリガー スマッシュボーダーズ』をJETエンジンで開発したのも「比較的複雑で、多くのオブジェクトを表示させる必要があったため、問題対応のしやすさも含めて、慣れた環境で作りたかった」(石井氏)から。本作はタワーディフェンスにアクション要素を入れた新機軸の内容で、描画ポリゴン数は最大8万ポリゴン。使用メモリは約250MBとなっています。

想定されるAndroidの機種依存問題については、対応端末をAndroid4.0(最終的に4.1)以上に限定することで「足きり」を実行。複数存在するGPUへの対応も公開資料でカバーできると判断されました。通信関係については同社にノウハウが乏しかったため、サーバプログラム部分を社外で作成。ゲーム側の通信処理はOS標準のAPIで対応する方針が立てられました。

アプリは基本的にVisualStudio上でWindowsアプリとして開発され、ゲーム部分はC++で実装。Android版は一部でJava、iOS版はC#が使用されました。ムービーやサウンドなどではコンシューマ開発で慣れ親しんだCRI WAREが採用されています。トラブルについても自社エンジンならではの「見通しの良さ」で解決できました。以下、講演トピックは多岐にわたりましたが、ポイントだけ紹介しましょう。

サーバ周り・ドローコール問題への対応



まず「スマホ特有」というわけではありませんが、結果的に大きな問題になったのがサーバ周りです。前述の通りサーバプログラムを外注したため、ゲーム側とサーバ側で実装スケジュールがあわず、ゲーム側で動作検証や実装が滞る事態が発生しました。結果、通信を行わないローカルプレイ版を新たに作成して対応することに。小田垣氏は「サーバサイドを丸ごとアプリ内に実装したようなもので、クオリティアップにはつながったが、作業コストがかかりすぎた」とふりかえります。

描画の最適化も問題でした。本作は16×16のグリッド上に建物などを配置していく仕様で、クォータービュー視点によりほぼ全景が映るため、常にマップ全体の書き換えが必用な状態に。開発中は16×16=256回ものドローコールが発生し、フレーム中のCPU負荷のほとんどを占める事態となりました。そこで森下氏によって、モデルを動的にマージしてドローコールを削減することになります。

具体的にはモデルの頂点とインデックスバッフのマージと、テクスチャのアトラス化を共にランタイムで実施することで対応。これによりドローコールを13回まで減らすことができ、高速化と省電力化に貢献しました。もっとも実装には潤沢なメモリ量が必用で、無駄な部分も発生し、最終的に使用するテクスチャが非圧縮になる問題も、トレードオフとして発生したといいます。

GPU周りで活かされた過去の開発資産



一方でスマホ特有の問題としては、さまざまな仕様のGPUへの対応があります。中でもiOSで採用されているPowerVRは、αテストや半透明の表示を苦手としています。ハードウェアによるオクルージョンカリングが無効となるため、他のGPUに比べてボトルネックになりやすいのです。

もっとも小田垣氏は、同じくPowerVRを搭載したハードであるPS Vitaの開発経験から、「極力これらの描画物をおさえてアセットを作成してもらった」と回答。コンシューマの開発経験が生きたとしました。

また描画周りのAPIについては、対応端末からOpenGL ES 2.0にとどめ、3.0については採用を見送っています。そのためシェーダについてはMaya+dx11shaderを使用しており、HLSL(DirectX向けの上位レベルシェーダー言語)をGLSL(OpenGL Shading Language)にコンバートして使用しています。

これについても過去の開発で作成したコンバータを流用しており、資産を活かせました。一部の端末でコンパイルエラーが発生したため、ソースを修正しましたが、軽微ですんだといいます。

このほか▽想定以上の電力消費量や発熱が発生したため、最終的に60フレーム/秒を30フレーム/秒に変更した▽Android端末の一部のGLドライバで画像表示が反転した▽デプスバッファやビューポートで機種依存がみられた▽ゲームの終了時にメモリリークがみられた▽クレードルに設置するとゲームが再起動した▽メモリ解放で、ファイルキャッシュの解放がうまくいかなかったーーなどの問題が発生しました。

もっとも、小田垣氏は「想定通りiOSより、各ベンダーがOSをカスタマイズできるAndroidの方が大変だったが、想像していたよりは機種依存は少なかった」と振り返ります。これには対応するAndroid OSを4.1以上にしたことが効果的だったとのこと。そのため、そこまで大きな問題に発展することはありませんでした。

長所・短所を見据えつつ現実的な対応を



最後に石井氏は、ゲーム部分はコンソールと同じような方法で開発できたし、インハウスのゲームエンジンを使ったことで、最適化も容易だったと語りました。なにより中身がわかる点が大きく、スマホならではのOS依存、機種依存や、不具合の調査も簡単だったと言います。もっとも、これらに対する備えは常に必用。そのうえでタイトルや社内環境などに応じて、最適な選択を行うことが重要だとまとめました。

ちなみに、同社が今回直面した問題の中には、商用ゲームエンジン側で吸収してくれるものも少なくありません。またインハウスのツールにはタイトル開発だけでなく、保守・管理コストも発生します。同社ではJETエンジン専属で2名のエンジニアをつけており、現在はPS4・Xbox Oneへの正式対応などを行っているとのこと。このように、どちらを使ってもメリット・デメリットが存在するのは事実です。

それよりも問題は「インハウスのゲームエンジンなど、今の時代はあり得ない」と思考停止してしまうこと。そうした意味からも、本講演はインハウスエンジンへの投資が中小ディベロッパーでも現実的な選択肢としてあり得るという、貴重な共有事例になったと言えるでしょう。
《小野憲史》

関連ニュース

特集

人気ニュースランキングや特集をお届け…メルマガ会員はこちら