容易に移植可能なゲームを開発するための 6 つのヒント

この記事は、インテル® ソフトウェア・ネットワークに掲載されている「Six Tips for Developing Easily Ported Games」(https://software.intel.com/sites/default/files/m/7/5/e/f/1/30212-6_Tips_for_Porting_Games.pdf) の日本語参考訳です。

---

ゲーム開発者にとって、プレイヤーがゲームを楽しんでいるのを見ることほど嬉しいことはありません。楽しんでいるプレイヤーを見て、こんなに面白いゲームをほかの人達がプレイしないのを疑問に思ったことはありませんか。

その最たる理由は、誰もがプレイできるわけではないからでしょう。人によって持っているハードウェアやオペレーティング･システムは異なります。毎年数百万ものゲームコンソールが販売され [1]、驚くべきスピードで新しい PC、ラップトップ、ネットブック、スマートフォンがリリースされています [2]。また、タブレットは早くも市場においてその位置を確立しつつあります。

つまり、ゲーム開発者と世界中のプレイヤーとの間には、多種多様なハードウェアとソフトウェアという大きな壁が立ちはだかっているのです。大勢の人達がゲームをプレイできるようにするには、どうしたら良いのでしょうか。それには、次の 6 つのヒントが役立つでしょう。

ヒント 1: 柔軟なプレゼンテーション・レイヤー

私が Pocket PC* 向けのゲーム開発に取り組み始めた当初、そのゲームを他のプラットフォームに移植するつもりは全くありませんでした。テスト用に Windows* システムで Microsoft* Visual C++* を使ってコーディングし、コンパイルしていただけなので、あまり先のことは考えていなかったのです。

その結果、ゲームを実際のデバイスで実行する前に、Microsoft* eMbedded Visual Tools (無料) でコードを再コンパイルしなければなりませんでした。さらに、私はもう 1 つの誤りを犯してしまいました。当時すべてのデバイスで使用されていた縦長の QVGA (Quarter VGA: 320 x 240 ピクセル) に解像度を固定してしまったのです。

この経験から、一般にゲームを開発する際には解像度や画面の向きを固定しないほうが良いということを痛感しました。デバイスによってディスプレイはさまざまなので、プレゼンテーション･レイヤーには柔軟性を持たせ、データレイヤーから切り離しておく必要があります。スマートフォンやタブレットが登場する前はほとんどのディスプレイが横長でした。ハンドヘルド・デバイスはディスプレイの向きを変えられるため横長と見なすことができ、これにより移植がはるかに容易になります。

異なる解像度を処理するための手法は多数あります。特定の解像度 (例えば 800 × 600 ピクセル) 向けに設計した 2D ゲームを、ユーザーは通常、全画面表示で実行することができます。この場合、拡大縮小はモニターによって処理されます。また、ウィンドウでゲームを実行することもできます。しかし、ウィンドウをサイズ調整可能にしたり、800 × 600 をサポートしていないデバイスで実行する場合、拡大縮小処理は誰が行うのでしょうか。

OpenGL* でよく使用されている手法の 1 つに、任意の解像度の 1 つのテクスチャーでイメージを描画し、そのテクスチャーを拡大して全画面表示する方法があります。2D ゲームであっても、デバイスの解像度に関係なくイメージ全体が表示されるように 3D エンジンを利用することができます。

この他にもいくつかの要因を考慮する必要があります。拡大縮小によりフォントが判読不能になったり、解像度の変更によりオブジェクトが適切に表示されない場合はどうしたら良いのでしょうか。このような場合には「ピクセル精度」が必要となり、画面への表示を変更しなければならないことがあります。

例えば、800 × 600 ピクセルのゲーム (図 1 の A) を、1024 × 600 ピクセルの一般的なネットブックで実行するケースについて考えてみましょう。背景の上にゲームボードがある場合、ゲームボードは変更せずに背景だけを全画面表示になるように拡大できます (図 1 の B)。あるいは、ワイドスクリーン用に別の背景を使用したり (図 1 の C)、2つの 112 × 600 ピクセルのイメージを背景の左右両端に配置することもできます (図 1 の D)。

図 1. 寸法変更によりゲームの表示を改善

解像度や向きを調整するためにディスプレイの変更を行うかどうかに関係なく、ビジュアル要素には可変位置を使用します。これにより、柔軟性が大幅に向上するだけでなく、デバイスの加速度センサーからのフィードバックを基に、瞬時に画面構成要素を移動したり、画面の向きをスムーズに変更したりする優れた機能を実装できます。デバイスによっては特定のレイアウトのほうが見栄えがいいため、簡単に要素を再配置できる機能は非常に便利です。

ヒント 2: マルチプラットフォーム対応のミドルウェアを使用する

ゲームのすべてのコードをスクラッチから記述する場合を除いて、ほとんどの場合はほかの開発技術やミドルウェア・ソリューションを統合することになるでしょう。これには、ゲームエンジン全体 [3] からパス検索ロジック、スクリプト・インタプリター、ビデオとオーディオのマルチメディア・ライブラリーまであらゆるものが含まれますが [4]、ここではそのうちのいくつかについて見ていきましょう。

コンピューター・グラフィックス
コンピューター・グラフィックス分野では、3D 技術において Microsoft* Direct3D* [5] と OpenGL* [6] の 2 つが突出しています。どちらも素晴らしい映像を提供し、グラフィック・カード・メーカーによってサポートされています。ただし、OpenGL* だけがオープン仕様です。これは、Windows* 専用のゲームを開発する場合にはあまり問題になりませんが、そのゲームを Microsoft* DirectX* をサポートしていないプラットフォームに移植する場合は大量のコードの書き直しが必要になります。

オーディオ・ライブラリー
オーディオ・ライブラリーでも同じことがいえます。通常、各プラットフォームには専用のアプリケーション・プログラミング・インターフェイス (API) があり、これらを利用することができますが、別のプラットフォームに移植する場合は関数呼び出しの書き直しが必要になります。幸いなことに、たいていの場合は、代わりに OpenAL* [7] や FMOD* [8] といったマルチプラットフォーム対応のオーディオ・ライブラリーを利用することができます。

専用ライブラリーは全く使用しないほうが良いのでしょうか。いいえ。専用ライブラリーによっては、マルチプラットフォーム・ライブラリーでは得られない品質、パフォーマンス、機能、省電力、コスト削減が得られることがあります。そのため、長所と短所を比較検討する必要があります。最終的には、ユーザーのプラットフォームにおいてできるだけ豊富な体験を提供できるようにするべきです。

プラットフォームはすべて同じではありません。プラットフォームによっては、開発期間を短縮したり、機能の少ないソリューションを使用することでライセンス費用を削減することができるでしょう。例えば、ステレオのみ再生可能なプラットフォームで 7.1 サラウンドを実装する必要はありません。

ヒント 3: モバイルユーザーも考慮する

毎日、数千ものスマートフォン、ラップトップ、タブレット・コンピューターが新たに利用されています。これらのデバイスはバッテリーの持続時間しか動作できませんが、現代社会において電源を確保するのはそう難しいことではありません。このことを念頭に置くと、ゲームをモバイルへ移植する際に役立ちます。もちろん、ゲームはネイティブ・アプリケーションとしてコンパイルする必要があります (図 2 を参照)。ネイティブ・アプリケーションは、インタプリター型プログラムと比べて移植性が劣ります。

図 2. インタプリター型プログラムよりもネイティブ・アプリケーションのほうが処理は少ない

インタプリター型プログラムは、インタプリターという別のプログラムを使ってマシン語命令に変換する必要があります。インタプリターは、ゲームとホスト・オペレーティング・システムの間でユーザーの入力とゲームのマルチメディア出力を処理するための仲介も行います。これにはインタプリター自身を実行する追加の CPU サイクルがかかるため、パフォーマンスの低下を招き、同等のコンパイル済みプログラムよりも多くの電力を消費します。

ネイティブ・アプリケーションはインタプリターを必要としないため、高いフレームレートと優れた応答性を達成しつつ、バッテリーの消耗を抑えます。また、複雑なレイヤーが排除されることで、テクニカルサポート件数を軽減することもできるでしょう。

ただし、インタプリター型プログラムにはいくつかの重要な利点があります。それは、短期間で開発できることと、互換インタプリターがあればどのプラットフォームでもプログラムを利用できる点です。すでにインタプリターが移植されている場合は、何もしなくてもそのプラットフォームでゲームを実行できます。これはゲーム開発者にとって非常に便利ですが、その代価はモバイルユーザーが払うことになります。

Adobe* Flash* ベースのゲームをプレイする場合 [9]、ゲームはブラウザーウィンドウでプラグインとして実行されます (図 3 を参照)。この場合、キー操作やマウス操作がゲームのロジックに到達するまでに、複数回の翻訳 (変換) が必要です。このコストはデスクトップ・マシンではわずかです。

Flash* プログラムはさまざまなプラットフォームと互換性があり、通常は 1 度記述するだけで済みます。ただし、すべてのプラットフォームでサポートされているわけではないので、最初に Flash プラグインのインストールが必要になることもあります。また、コンテンツはサーバーから送信しなければならないため、ユーザーのインターネット接続状況によってはダウンロードに時間がかかることもあります。さらに、モバイルデバイスでは、ワイヤレスシグナルによりバッテリーの消耗が早くなります。

図 3. Adobe Flash ベースのゲームはほとんどの Web ブラウザーでプレイ可能

どのような方法を使用するにしても、モバイルユーザーのプレイ時間はバッテリーに依存するということを覚えておく必要があります。スムーズで魅力的な体験を維持しながら、消費電力を抑えるための取り組みは、ユーザーに喜ばれるでしょう。ゲームがネイティブに実行されるようにコンパイルすることは、そのための第一歩といえます。ただし、移植の目的を達成するには長い時間がかかることを覚悟しなければなりません。

ヒント 4: 複数の入力方法に対応する

キーボート、マウス、タッチパッド、タッチスクリーン、加速度センサー、ジョイスティック… これらはゲームを移植する場合に考慮しなければならない典型的な入力方法です。あまりの多さに圧倒されるかもしれませんが、いくつかのカテゴリーに分けることができます。

例えば、ラップトップやネットブックでタッチパッドを使用する場合、あるいはタブレットやスマートフォンでタッチスクリーンを使用する場合、一般に操作内容を「X + Y + イベント」のようなマウス入力に変換することができます。ジェスチャーは比較的新しく、すべてのデバイスでサポートしているとは限りません。キーボード、加速度センサー、ジョイスティックが使用できるかどうかは、デバイスの状態によって異なることもあります。

要するに、あまりにも多種多様なハードウェアがあるため、特定のデバイスに移植する場合を除き、通常は 1 種類の入力方法だけに対応するプログラムでは不十分だといえます。ゲームで対応するべき入力方法は、どのように判断したら良いのでしょうか。表 1 にそのためのガイドラインを示します。

	キーボード/ハードウェアのボタン	マウス/タッチパッド/タッチスクリーン	加速度センサー	ジョイスティック
デスクトップ	X	X
ラップトップ/ネットブック	X	X
タブレット		X	X
スマートフォン		X	X
コンソール	X			X

表 1: ハードウェア・カテゴリー別の一般的なデバイス入力

実際には、ジョイスティックが接続されているデスクトップやビルトインキーボードを装備したスマートフォンも多数あります。最終的にどの入力を実装するかによって、ゲームの要件が決まります。

ヒント 5: ローカライズを視野に入れる

ゲームをグローバルに展開する場合は、すべてのユーザーが英語を話すわけでないということを念頭に置かなければなりません。開発者が外国語を知らない場合でも、ローカライズに対応したゲームを作成することは可能です。通常は、テキスト文字列、アートワーク、音声の 3 つをローカライズすることになります。

ラベル、ALT テキスト、長い説明として表示されるほとんどの文字列には、インデックスと翻訳された単純なテキストファイルを使用できます。ゲームをロードするときにそのファイルを配列に読み込み、必要に応じて適切な翻訳を呼び出して表示します。

アートワークの場合、コードの変更はほとんど必要なく、ローカライズされたイメージをロードするだけです。ただし、同じアートワークをロケールの分だけ複数作成し直すことはできるだけ避けたほうが良いでしょう。デバイスごとや画質ごとなど、すでに複数のアートワークがある場合は、ローカライズ作業が大幅に増えます。

音声は、プレイヤーをゲームに没入させる上で非常に重要です。音声を多言語で録音する代わりに、映画で一般的に使用されている「字幕」を挿入すれば、簡単に多言語化することができるでしょう。字幕には、ユーザーがサウンドをオフにしていたり、ゲームから一瞬注意をそらした場合にも、キャラクターが何を言っているのか理解できるというメリットもあります。

通常、テキストはそれほどでもありませんが、イメージファイルとサウンドファイルの容量は大きくなります。ほとんどのプレイヤーは母国語だけでゲームをプレイするため、ほかの言語のアートワークや音声のために余分な容量が増えることを望まないでしょう。特に、モバイルデバイスやソリッド・ステート・ドライブ (SSD) では容量は貴重です。

どうしても複数のローカライズ・バージョンが必要な場合は、バージョンごとに個別にパッケージしたほうが良いでしょう。そうすることで容量が減り、ゲームのダウンロード時間が短縮され、ユーザー体験を向上できます。また、すべての言語のローカライズが完了するまで待たずに済むため、ゲームをより短時間で市場に投入できます。

ヒント 6: 移植が容易な開発環境を選ぶ

当初はほとんどの統合開発環境 (IDE) がマルチプラットフォーム開発に対応していませんでしたが、現在では多くのツールで、ソースコードをほんの少し変更して、あるいは全く変更しないで、デスクトップ、モバイル、そしてコンソール・プラットフォーム向けにゲームのコンパイルを行うことができます。その中でも人気があるのは、Microsoft* XNA* Game Studio [10] と Torque* [11] の 2 つです。

XNA* Game Studio
Microsoft* Visual Studio*、Visual C#*、Microsoft* .NET Framework、XNA* Game Studio を利用すると、それらの持つプロプライエタリー性により制限されるように思われがちですが、実際にはソースコードをほとんど変更することなく、Windows* オペレーティング・システム (デスクトップ、ラップトップ/ネットブック、タブレット)、Microsoft* Xbox 360*、Microsoft* Zune* メディアプレーヤー、Windows* Phone 7 シリーズを搭載したデバイス向けのゲームを開発し、大勢のプレイヤーに提供できるようになります。図 4 は XNA* Game Studio のインターフェイスです。

XNA* Game Studio の最大のメリットの 1 つは、無料でダウンロードしてゲームを開発できることです。Windows* 用のゲームはリリースも無料です。Microsoft* への支払いは一切発生しません。ただし、Xbox 360*、Zune*、Windows* Phone 7 用のゲームは、各種配信ポータルで開発者の登録が必要になります (1 年につきおよそ US$100 かかります)。

使いやすさはどうでしょうか。経験豊富な開発者であれば短期間で使いこなせるようになるでしょう。初級者は、まずオンライン・チュートリアルや書籍を活用して C# プログラミングに慣れることから始めたほうがいいでしょう。全体的に見て、XNA* Game Studio は 2006 年初めにリリースされてから現在までに素晴らしい成熟を遂げています。

Torque* (2D、3D、X など)
Torque* 開発ツールは、当初は Tribes 2 の 3D エンジンとして構築され、過去 9 年間で大いに進化しました。現在では、特定の市場またはプラットフォーム向けの各種製品に分割され、それぞれ個別のライセンスが必要です。

各製品を使って開発されたコードのほとんどは Torque IDE 間で移植可能です。例えば、Torque 2D で開発された Windows* 用のゲームを、全く異なるデバイス群を対象とした iTorque 2D* でコンパイルすることができます。Torque* の最大のメリットは、対応プラットフォーム数が多く、大規模なコミュニティー、そしてユーザーフレンドリーなインターフェイスを提供することです(図 5 を参照)。

導入費用は少なくとも US$100 はするでしょう。最新の価格情報は Torque* の Web サイトを参照してください。Torque 2D* の 30 日間無料体験版をダウンロードすることもできます。

XNA* Game Studio と Torque* は市場に出回っているマルチプラットフォーム開発ツールのほんの一例ですが、これらからマルチプラットフォーム IDE で必要なこと (容易なアプリケーション開発、一般的なプラットフォームのサポート、わずかなコード変更またはコード変更不要) を理解することができるでしょう。

まとめ

ユーザーが利用するハードウェアは異なり、デバイスごとにオペレーティング・システムは異なります。だからといって、ゲームを楽しめるプレイヤーが限定されるわけではありません。綿密なプランを計画して適切なツールを利用することにより、世界中のプレイヤーが楽しめるゲームを作成することができます。

参考文献 (英語)

[1] VGChartz: http://www.vgchartz.com
[2] 技術系ニュースサイト: Engadget (http://www.engadget.com)、Gizmodo (http://www.gizmodo.com)
[3] Gamasutra Web サイトにおける Mark DeLaura による調査結果: http://www.gamasutra.com/blogs/MarkDeLoura/20090302/581/The_Engine_Survey_General_results.php
[4] ミドルウェア・ソリューション: http://www.gamemiddleware.org
[5] DirectX* デベロッパー・センター: msdn.microsoft.com/en-us/directx/default.aspx
[6] OpenGL*: http://www.opengl.org
[7] OpenAL*: http://www.openal.org/
[8] FMOD*: http://www.fmod.org
[9] Flash* ゲーム: http://www.flash-game.net
[10] XNA* Game Studio Creators Club Online: http://creators.xna.com
[11] Torque* 開発ツール: http://www.torquepowered.com

著者紹介

John Till は開発者として Pocket Adventures.com にあるすべてのゲームを製作しています。彼が製作したゲームは Pocket PC Magazine の Annual Software Awards で高く評価され、Handango や PocketGear などの主要な配信ポータルでトップ 10 入りを果たしています。Purdue University でコンピューター・サイエンスの学士号を取得しており、12 年以上 IT 業界に携わった経験があります。