Nancy Nicolaisen
記事のダウンロード
開発事例: Antix* ゲームプレイヤーの MeeGo* への移植* [PDF 590KB]
Antix Labs* の開発者達は、ハイパフォーマンスなゲームを音楽や写真、動画、ドキュメントなどのように、すべてのデバイスで楽しめるようにしたらどうだろうか? という革新的なアイデアを持っていました。Antix Game Player* (AGP) は、まさにこのアイデアを実現するためのミドルウェア・レイヤーです。AGP はオペレーティング･システム、チップセット、画面サイズ、画面の向き、入力デバイスを抽象化し、オンデバイスのソフトウェアベースのゲームクライアントを提供します。ゲーム開発者やゲームメーカーは、AGP を利用することで、クロスプラットフォームでゲームコンテンツとサービスを迅速に配布し、ビルトイン機能により収益と知的財産権を保護できます。
ユーザーは AGP を利用することで、Antix* ATX 形式で配布されたゲームをインストール、管理、プレイすることができます。ATX は、ゲームを使用するすべてのデバイスで単一の移植可能な実行形式を提供します。ユーザーは、質の高いゲームをオンライン/オフラインを問わず、携帯電話、PC、テレビ、その他の接続されたデバイスで楽しんだり、共有したりできます。AGP は、ユーザーが多種多様なデバイスでハイパフォーマンスなコンテンツをプレイできるようにし、ゲームを別のマシンにコピーしたり、友人とゲームを共有したり、インターネットや短距離ネットワークを介して接続したりできるようにします。
モバイル開発プロセスの合理化
歴史的にマルチプラットフォームのモバイル向けゲーム開発は — 特に、断片化の複数の層のために — コストと時間がかかるものでした。これまで、デバイス、オペレーティング・システム、通信事業者によって課せられる市場障壁は、プラットフォームに中立的なモバイルゲーム空間へ参入しようとするゲーム開発者を悩ませてきました。しかしながら、近年、ネットブックとオープンソース・テクノロジーの組み合わせによりこの状況が大きく変わり、Windows* および Linux* の両方で、開発者は使い慣れたツール、ターゲット、レガシーコードを利用できるようになりました。Antix* の開発者が Moblin* v1.0 (2008 年にインテルから最初にリリースされた Moblin*) から MeeGo* へ製品を移植した経験を通して、我々は多くのことを学ぶことができます。なぜならば、現在、AGP は Android*、Linux* (Nokia Maemo*、Moblin*、および MeeGo*)、Symbian* OS S60、Windows*、Windows Mobile を搭載した ARM*、インテル、MIPS 製の各種プロセッサー・アーキテクチャーのモバイルデバイスで動作しているからです。
Maemo* + Moblin* = MeeGo*
MeeGo* は Nokia* Maemo* と Moblin* から進化したもので、それぞれの長所をモバイル開発者に提供します。Maemo* からは、モバイルデバイスで使用するための Linux* ベースのソフトウェア・スタックを継承しています。Maemo* は Nokia* で開発されたため、スマートフォンに偏りがちですが、 タブレット・コンピューターのようなデバイスでも使用されています。一方、Moblin* はインテルがモバイル向けの Linux* プラットフォームとして開発したため、特定のデバイスに偏らず、インターネットベースのモバイルデバイス、ネットブック、車載システムとして広く利用されています。Moblin* の最大の長所 の1 つは、デバイスのウェイクアップが非常に速く、数秒で接続して使用できることです。
この 2 つのシステムのハイブリッドである MeeGo* は、それぞれの長所を多数継承しており、ハンドセット、ネットブック、タブレット、ネット対応 TV、車載システムなどの多種多様なコンピューティング・デバイスで動作します。Maemo* と Moblin* の両開発チームの取り組みとリソースを活かし、さまざまなデバイスに対応することで開発者に大きな市場を提供します。
MeeGo* への移植とほかの移植との比較
Antix* 開発リーダーの Kevin Digweed 氏は、MeeGo* への取り組みで最も驚いたことの 1 つに、普段使い慣れたツールが使用できたことをあげています。「Moblin* v1.0 から MeeGo* への移植は比較的スムーズでした。開発作業の一部は、ネットブックを使用してオンデバイスで行うことができました。Ubuntu* デスクトップ上に MeeGo* のバイナリービルドをネイティブに実行できる環境を作成しましたが、 これには 2 つの重要な利点がありました。まず、使い慣れたすべての Linux* コマンドラインと GUI (グラフィカル・ユーザー・インターフェイス) ツールに加えて、いくつかの社内のツールを使用することができた点です。つまり、普段使っている慣れ親しんだツールでコードを記述、解析、デバッグすることができました。そのため、すぐに MeeGo* 開発環境に慣れ、使いこなせました。」 さらに、Digweed 氏は、デスクトップでバイナリーをネイティブに実行できたため、生産性が大幅に向上したと語っています。「開発サイクルを通して、容易にプロセスを繰り返すことができました。最初にデスクトップで予備テストを行った後、作業ディレクトリーからネットブックへコピーし、ターゲットデバイス上で実行して、テストすることができました。VM (仮想マシン) やエミュレーター、クロスコンパイラーのセットアップと設定に時間を費やさずに済みました。」
MeeGo* への移植のための Antix* ツールチェーン
AGP の移植では、コードの 90% は C、残りの大部分は C++ で記述されていました。「デスクトップ環境には、Ubuntu* 9.10 のみを使用しました。開発ワークステーション上に chroot環境をセットアップできたため、生産性が大きく向上しました。」と Digweed 氏は語っています。chrootは、開発の早期段階で完全に安定していないアプリケーションをサンドボックス化するのに有効な手法です。chrootは、Linux* 系または UNIX* 系オペレーティング・システム上で、特定のプロセスやそれによってスポーンされた子プロセスの有効な root ディレクトリーを変更します。これにより、プロセスの実行環境を制限することができます。この手法を使って Digweed 氏らは、AGP が実際に動作する MeeGo* デバイスとほぼ同じランタイム環境をデスクトップ上に作成することができました。
デバッグ段階では、Digweed 氏らはできるだけ早期にネイティブ環境 (ターゲットデバイス) で作業を行うようにしました。「chroot 環境を使用して初期評価を行った私の経験から、ほかの開発者の方々に 1 つだけアドバイスするとしたら、"最終的なデバッグと QA (品質保証) は必ずデバイス上で行うことです。そうすることで、ユーザーと同じ視点で動作とパフォーマンスを確認するができます。」と Digweed 氏は述べています。
小型デバイスを扱ったことがある開発者の大半は、リモートデバッグの設定には少なくともいくつかの困難が伴うことを予測します。多くの問題は、ケーブルやネットワークを介して 2 つのデバイスを接続し、通信とプロセス制御の詳細について両デバイスの同意を取り付けられるかどうかに関連しています。ここでも、Antix* の開発チームは、作業を効率良く、容易に進められたことに驚きました。Digweed 氏らは、デスクトップ環境とターゲットデバイスの両方で GNU* デバッガー (GDB) を使用しました。GDB は、ほとんどの UNIX 系のシステムで動作し、さまざまな開発言語に対応しています。GDB を Antix* プロジェクトに採用した理由について、Digweed 氏は次のように語っています。「言語が混在した開発に適しており、多くの開発者に馴染みがあるものでした。ターゲットデバイスが比較的高性能なネットブックだったので、それぞれのシステムにローカルでデバッガーをインストールし、実行するだけで済みました。もし、スマートフォンのようにもっと制限されたデバイスでデバッグしなければならなかったとしたら、デバイス上で gdbserver を実行し、TCP/IP を介してデスクトップと通信して調査を行っていたでしょう。」
参考までに、以下に gdbserver のセットアップ手順を紹介します。
- ネットブック側で、デバッグする実行ファイルと gdbserver アプリケーションのコピーを作成します。
- ネットブック上で、引数としてデバッグターゲットの完全修飾パスとポート番号 (TCP/IP または UDP) を指定し、gdbserver を起動します。
- ターゲットデバイス上で gdbserver がアプリケーションを開始すると、ステータスメッセージにプロセス ID (PID) が表示されます。この ID は、後でホスト上の GDB をターゲットデバイス上の gdbserver セッションへ接続するのに必要になるため、控えておいてください。
- ホスト側では、デバッグターゲットの実行ファイルとソースファイルの両方が必要になります。
- ホスト上で、引数としてデバッグするアプリケーションを指定し、GDB を起動します。
注: 通常、環境設定によりソースファイルと .exe ファイルへのパスが解決されるため、フルパスを指定する必要はありません。(そうでない場合は、gdb –helpと入力するとオプションが表示されます。) - 次のように、GDB コマンドラインで GDB がリモートターゲットを参照するように指定します。
- target remote mylittlenetbook:1234 (1234は gdbserver を起動して取得した PID、mylittlenetbook はシステムのエイリアス)
– または – - target remote 145.114.13.85:1234 (1234は gdbserver を起動して取得した PID、145.114.13.85 はネットブック の IP アドレス)
最終的に Antix* の開発チームは、ネットブックを使用してオンデバイスで開発の多くを行うことができたため、AGP の MeeGo* への移行を迅速に進めることができました。いくつかの開発段階にわたり、作業の約 20% ～25% をこの方法で行うことができました。
「個々の主な開発タスクはデスクトップ上で行い、その後ネットブックに移してオンデバイスのテスト結果を基に細かい調整を行いました。そして、それが終わったら、デスクトップに戻って次の主なタスクに取りかかりました。このように 2 つの環境を行き来することで、移植作業の大半が終わるまで細かい調整作業をためておき、その後ターゲットデバイスに移って作業することがなくなりました。このため、より正確に所要時間を見積もり、計画を立てることができました。」と Digweed 氏は述べています。
開発チームにとってはこれが初めての MeeGo* プロジェクトであり、精通したコードベースでの作業でしたが、使い慣れたツール — そのほとんどはコマンドライン・ベースのもの — を使用できたことは大きな利点でした。もし新しいプロジェクトをゼロから始めなければならなかったとしたら、デスクトップ上の主な開発環境として Eclipse* などの統合開発環境 (IDE) の使用を検討していたことでしょう。
MeeGo* とオープンソース・コミュニティー
Maemo* および Moblin* のオープンソース・コミュニティーとテクノロジーをマージすることで、MeeGo* はモバイル・アプリケーションの市場規模を大幅に拡大しました。MeeGo* はさまざまなデバイスとチップ・アーキテクチャーで動作するため、移植リスクが抑えられます。オープンソースにすることで開発者が自由にアイデアを出し合えるようにし、開発者コミュニティーの参加により確実に将来への道が開けるようにしています。「つまり、MeeGo* は安定し、成熟したオープンソースであるだけでなく、MeeGo* にはその前進に向けて活発に取り組み、拡大し続けているコミュニティーがあります。MeeGo* プロジェクトの目的は、多種多様なシリコン・プラットフォームにおいて、高速で移植性に優れたアプリケーションを可能にするエコシステムの基盤を築くことであるとされています。」と Digweed 氏は語っています。
Antix* は、ゲーム開発者とゲームメーカーが、売り上げ予測やデバイス出荷台数などに関係なく、ゲーム・プラットフォームとしてターゲットデバイスを選択できるようにします。つまり、Antix* は独自のプラットフォームだけでなく、オープンソースもサポートします。Antix* のクロスプラットフォーム戦略の鍵は、グラフィックスのレンダリングとアクセラレーションにオープンソースのツールとテクノロジーを活用していることです。そのために、Antix* はより広範なオープンソース・コミュニティーに積極的に参加し、Khronos Group のメンバーとして中心的な役割を果たしています。Khronos Group は、2000 年に設立された会員企業の会費によって運営される非営利の業界団体です。メディア関連の IT 企業で構成され、さまざまなプラットフォーム上でコンテンツ開発と高速再生を実現する、業界標準のロイヤルティー・フリーのアプリケーション・プログラミング・インターフェイス (API) を策定することを目的としています。現在、12 種類以上の Khronos API があり、広範なデバイスに対応しています。Khronos Group には、インテルを含む 100 以上の企業が参加し、プロジェクトに貢献しています。
Antix Labs* は、Khronos Group の中でも特に動的メディア API 仕様の定義に取り組み、OpenKODE* API の仕様編集者として貢献しています。OpenKODE* は、メディア、グラフィックス、並列コンピューティングのアクセラレーションを可能にする、オペレーティング・システム・リソース (ファイルシステムやネットワークなど) の抽象化レイヤーです。ネイティブ API を組み合わせた統合メディアスタック仕様の標準規格を提供します。Digweed 氏は、その開発プロジェクトにおける OpenKODE* ツールセットの利点を次のように述べています。「OpenKODE* ツールセットを実装したすべてのプラットフォームにおいて一貫した方法でハイエンドのメディア機能が利用可能となり、メディアとグラフィックスの処理を高速に行うことができます。Antix* Game Player にとって、OpenKODE* の最大の利点の 1 つは、Khronos のメディア API は Linux*、Brew*、Symbian*、Windows* Mobile、WIPI、RTOS ベースのプラットフォームに関係なく、2D/3D グラフィックスのレンダリングで最先端のアクセラレーションを提供してくれることです。」 OpenKODE* コミュニティーへ貢献することで、同社はデバイスの進化とともに AGP 製品を新しいプラットフォームへスムーズに移植できるように、コミュニティーを介して API とコンポーネントの進化に影響を与えることができます。
Antix* の MeeGo* への移植から学べること
今回の移植経験について、Digweed 氏はモバイルゲーム・ビジネス環境全体の観点から次のようにまとめています。「さまざまなデバイスにコンテンツを素早く、簡単に移動したいというユーザーの要求は高まるばかりです。ゲームのスコアボードやマルチプレイヤー環境などのサービスに、ラップトップやデスクトップからだけでなく、スマートフォンやテレビからも接続できることを望んでいます。MeeGo* や OpenKODE* のようなオープンソース・テクノロジーは、ユーザーが求める 3D グラフィックス・アクセラレーション、高品質なベクトルフォント、3D インタープロセス・ナビゲーション、高度なユーザー・インターフェイスなどの機能を備えた製品を、迅速にコスト効率の良い方法で提供できるようにします。インテルや Nokia* のような業界の中心的な企業が MeeGo* を主導していることは、オープンソース・コミュニティーの強みといえるでしょう。」
著者紹介
Nancy Nicolaisen は、ソフトウェア・エンジニアリング手法について多数の書籍を執筆しており、 小型のモバイルおよび組込みシステム向けソリューションの設計と開発を専門としています。ゲーム業界には 1981 年から関わっており、ゲームのパイオニアである Imagic に在籍し、Demon Attackなどの開発に携わりました。