モバイル端末向けのゲームの場合、スマートフォンが流行する以前から、移植性を意識した上で開発するのが一般的でした。ゲーム以外のモバイルアプリであれば、最初は特定のプラットフォーム向けに作った上で、ツールやフレームワークを利用して、それを別のプラットフォームに移植するといった手順で開発されることも少なくありません。しかしモバイルゲームの場合、開発の規模が比較的大きいことや、コーディング量が多いといった理由から、開発の初期段階から複数のプラットフォームへの展開を前提に設計する必要があるからです。したがって、開発の現場では当時からマルチプラットフォームへ対応を、どのように行っていくかが大きな課題になっていました。

従来の基本的なノウハウとしては、ゲームの本体部分の機能の実装と、プラットフォームと端末に依存する部分との間にポーティング層を設けることで、移植性を確保するといったやり方が挙げられます。ポーティング層を設けることでプラットフォームに依存する部分がゲーム本体に与える影響を極力少なくするわけです。この場合、いかに依存性を減らしてポーティング層を厚くするのかが開発者にとっての腕の見せ所になります。

それに対して、最近ではこのポーティング層の部分を専門に提供するベンダーが登場しており、CP側ではそのようなツールやサービスを利用するというスタイルが一般的になってきています。ポーティングのテクニックを身につけるには幅広いプラットフォームや端末に対する知識と経験が不可欠ですが、その部分を第三者に任せることで、ゲーム本体の開発により注力することができるというメリットがあります。これによって新規参入への敷居も下がり、開発者の裾野も広がってきました。

Gゲーby GMO（以下Gゲー）で提供している「VIVID Runtime」のようなランタイムも、そのようなポーティング層を担保する存在です。また、最近では「Unity」や「Cocos2d-x」といったマルチプラットフォーム対応のゲームエンジンやフレームワークも人気を集めています。

それでは、実際に使用するランタイムやゲームエンジンを選ぶ際にはどういった点を基準にすればいいのでしょうか。一般論としては、次のような点が挙げられると思います。

・作りたいゲームの内容に対して十分な機能が提供されているか
・開発の工数をどれだけ減らすことができるか
・品質をどれだけ担保することができるか

マルチプラットフォーム開発の場合、特に工数は大きな問題になりがちです。通常、対象とするプラットフォームの数だけ工数は増えていきます。したがって、これをどう抑えるかがコスト削減やリリースサイクルに大きく関わってくるからです。

具体的にどのツールが最適なのかについては、そのときの開発プロジェクトによって異なるため明確な回答はありません。ただし、「Unity」に代表されるゲーム開発のためのツールと、「VIVID Runtime」のようなランタイムとでは、その位置づけが多少異なるという点は意識しておくべきでしょう。前者はゲームに特化した開発支援環境および実行環境であるため、マルチプラットフォーム対応のためのアーキテクチャがゲームエンジンとセットになった形で提供されるものです。それに対してあくまでも共通層の機能を主体として提供されており、ゲームエンジンを含まない点が大きな違いとなっています。

この位置づけの違いが、開発者にとってどのように影響してくるのでしょうか。「Unity」を例に挙げると、その人気の背景には、3Dエンジンの性能の高さやライブラリの使いやすさ、トライ＆エラーで開発できる手軽さ、エディターやプロファイラーをはじめとするツールの使いやすさが挙げられます。ハイレベルなゲームの開発にも対応できる環境がワンセットで提供されており、それに加えて複数のプラットフォームで動作させられるということが魅力です。

一方、「VIVID Runtime」の場合にはゲームエンジンが含まれていません。これは、言い換えれば特定のゲームエンジンに依存しないということで、例えば独自のゲームエンジンを載せて利用するといったこともできるようになっています。ゲームベンダーの場合にはすでに自社開発ゲームエンジンを持っていたり、既存のゲームエンジン用の資産を持っているようなことも少なくないため、そのようなケースではランタイムを選択するメリットが強くなります。

もうひとつ重要なのが、ゲーム機能以外の部分でのマルチプラットフォーム対応のサポートは、ランタイムの方が圧倒的に手厚いということです。代表的なのが、アプリストアへの公開のための仕組みや、課金のための仕組みです。これらはプラットフォームごとに仕様が異なるため、通常であれば個別の開発が必須になりますが、ランタイムではそれが基盤側でサポートされるという強みがあります。

このことは、新規開発だけでなく運用時にも大きく影響してきます。最近のモバイルゲームでは、リリース後にもアップデートを繰り返して運用していくというスタイルが主流です。そのため、プラットフォーム側で仕様の変更が発生した場合には、その度に対応するアップデートを出さなければいけません。しかし現実には、運用のフェイズに入ってからの仕様変更は極めて大きな負担になります。ランタイムの場合、そのような仕様変更も基板側で吸収してくれるのです。

「VIVID Runtime」の場合には、Gゲーのプラットフォームとの組み合わせによって、マルチプラットフォーム対応のためのレイヤーをより手厚くサポートしているという特徴があります。課金システムの共通化はもちろんのこと、プッシュ通信の仕組みなど、プラットフォームに強く依存する機能も備えられています。いずれもプラットフォーム側で仕様の変更が行われたことがありますが、ゲーム本体に影響させることなくランタイム側で対応しています。

仮にプッシュ通信を自前で実装しようとした場合、仕様を確認してコードを書き直すだけでなく、プッシュ通信に対応したサーバーを用意したり、テストの工数を増やしたりといった作業も必要になります。そういった煩わしさを基盤側で吸収し、本来のゲーム開発の部分により大きなリソースを割けるようにすることがランタイムの役割と言えます。

これまで3回にわたって、ランタイム開発者の立場からマルチプラットフォーム開発について語ってきました。ランタイムやゲームエンジン、フレームワークなどのツールを使いこなせば、プラットフォーム固有の問題や仕様の違いをそれほど意識することなく、複数のプラットフォームに向けたゲーム開発ができるようになります。とはいえ、技術者として一歩先を目指すのであれば、常に最新の技術動向に目を光らせておくことは忘れてはいけません。

モバイルゲーム市場における最近の事情を考えると、技術動向と並んでOSの動向にも注目しておく必要があります。特に、アメリカで発表された内容については、日本に入ってくる前に対応を済ませておくというくらいのスピード感が必要です。もちろん、その中にはランタイムなどのツール側で吸収できる部分もあるでしょう。モバイル市場はとりわけ変化の激しい分野ですから、それに追従できる対応力を身につけることが大切です。


取材日：2013.09.02