【CEDEC 2009】WiiとDSで同じゲームを動かす～『FFCC EoT』を巡るプラットフォーマーとソフトメーカーの取り組み事例

スクウェア・エニックスから発売された『ファイナルファンタジークリスタルクロニクルズエコーズ・オブ・タイム』はWiiとニンテンドーDSで全く同じゲームが楽しめるという今までにない挑戦に取り組んだ意欲作です。

CEDEC初日に開催された「WiiでDSが動くまで～面白いコト・新しいコトに対するプラットフォーマーとソフトメーカーの取り組み事例」では、スクウェア・エニックスの紙山満氏と任天堂の光吉勝氏が登壇し、両社のコラボレーション事例について紹介しました。


多くの聴衆が集まった	紙山氏	吉光氏

紙山氏はスクウェア・エニックスの開発部所属のプログラマーで、FFCC関連では第一作目からメインプログラマーとして参加、『リング・オブ・フェイト』からはディレクターとメインプログラマーを兼任しています。

吉光氏は任天堂の業務技術部の技術渉外グループ・サブマネージャーとして、サードパーティに対する技術的な窓口業務を行っています。最初の所属は開発第2部で、ファミコンのファミコンフットネスシステム3(FFS3)という幻のハードの開発にも携わった事があるそうです。これは『Wii Fit』を20年くらい先取りしたシステムで、ペダルをこぐと15分ごとに体力年齢を測定して健康状態を診断してくれるものだそうです。その後業務部技術課、招布を経て、2004年かに業務技術部に所属しています。

業務技術部はサードパーティ向けの技術窓口で、スタッフは15名、そのうち国内を主に担当するのは7～8名で、少人数で回すためにオンライン上の技術交流サイト「NTSC-ONLINE」で任天堂プラットフォームの開発者同士が質問し合ったり、任天堂のサポートを受けたりできるようにしているそうです。部署内に3つのグループがあり、今回対応した技術サポートグループ、新製品の紹介や個別タイトルの要望を聞く技術渉外グループ、NOAのサポートチームをサポートする海外サポートグループです。技術面のサポートでは、業務技術部以外では、100名以上のスタッフを抱える環境制作部が任天堂プラットフォームにおけるミドルウェアやライブラリなどの開発に当たっています。


業務開発部とは?	業務開発部のメンバー	みかとそほらみりにみぃ

やり取りの様子	3つのグループが存在	組織上の立ち位置

■DSのコードを完全流用したい

そもそも「エコーズ・オブ・タイム」は当初からWiiとDSでリリースする予定であったタイトルではありません。元々はDSのみをプラットフォームとして、Wi-Fiに対応して友達と一緒に冒険できる、というのが特徴のゲームになる予定でした。それがWii版も登場することになったのは、ある時の和田社長のコメントだったそうです。「これからのゲームはマルチプラットフォームに」それを聞いた紙山氏はひらめき、DSとWiiという異色のマルチプラットフォームを目指すことにしたそうです。しかも、DS版のソースコードを全く変更せず、Wiiで動かすという壮大な目標です。


マルチプラットフォームが大原則	そこで・・・	しかしソースコードは変更したくない

ゲームはCodeWarrior上で開発されていました。CodeWarriorはマルチプラットフォームに対応した統合開発環境です。もちろんDSでもWiiでも使用できます。まずはWii版のCodeWarriorにDS版のソースをそのまま載せてビルドしてみるところからスタートしたそうです。とはいえ、Nitro-SDKとRVL-SDKでは全く仕様が異なります。「当然怒涛のビルドエラー」(紙山氏)になります。まずはエラーが出た関数を、自力で実装してビルドしてみる、という作業を5日間くらい続け、ようやく動くものになったそうです。CodeWarriorはエラーが100個出るとそこでビルドが止まってしまうという仕様だそうで、5日目にそれが98個で止まったとき、「感動を覚えた」そうです。

しかし問題は終わりません。次にぶち当たるのはエンディアン(メモリにデータを載せる際の並びの方式)の問題です。GCの流れを汲むWiiはビックエンディアン、GBの流れを汲むDSはリトルエンディアンです。バイナリデータはそのままでは流用できません。ただ、これはコンバータを書くことで、1日かからず対応が出来たそうです。


ひたすらエラー潰し	関数を実装していく	エンディアンにも対処

ここまでの作業で出来たのは、プログラムだけです。まだ絵や音声データは入ってません。グラフィックに関してはDSと同じモデルやテクスチャを利用しているものの、Wiiの描画機能を活用することで、より高解像度・高品質で描画できるようになっています。約4倍の解像度になっているそうです。サウンドに関してはDSとWiiでオーサリングツールの仕様が類似していることに着目。DSのサウンドプロジェクトをWiiのサウンドプロジェクトに変換する汎用的なC#のコンバータを作成。アーティストがDSのツール上でバイナリを出力する際には、Wii用のバイナリも出力されるという風にしたそうです。


グラフィック	DSとWiiでは表示で異なります	サウンド

ここまで来るとプログラムも、グラフィックも、サウンドも乗り、一通りのゲームになります。ここで初めて紙山氏は任天堂にプレゼンし、任天堂の協力を求めます。

次にぶつかったのは通信対戦の問題です。通信対戦では、一方のプレイヤーで起こったことが、もう一方のプレイヤーにも同じように起こらなければなりません。例えば『マリオカート』で、一方のプレイヤーが赤コウラを取れば、後ろを走るもう一方のプレイヤーから見た最初のプレイヤーも赤コウラを取らなければなりません。そのためにはゲームの開始時に、参加する全てのプレイヤーの乱数の初期値(シード)を同じに設定しなければなりません。同じハードで同じ計算をすれば同じ初期値が得られます。

しかしこれが異なるハード間となると問題が起きてきます。DSでは、CPUに除算命令がない代わりに、高速な整数除算器や平方根演算器が搭載されています。一方でWiiにはCPUに除算器があります。ここでハードの仕様が分からなければ、DSの整数除算器・平方根除算器の結果と、Wiiでの"/"やsqrtl関数の結果が同じになるかどうか分かりません。基本的にはハードの中身はブラックボックスです。ここでは任天堂の助けを借り、それぞれの結果を比較したところ、全ての数値が一致したそうです。


通信対戦はキーシェアリング方式を採用	キーシェアリングとは?	キーの入力をやりとりする

つまり・・・	乱数の誤差が大敵	そこで・・・

C言語の実装依存が疑わしい箇所もあったそうです。

さらに、Wiiのメインメモリが厳しいという問題もあったそうです。DSはROMメディアで高速に読み出しができるため、メインメモリには必要最低限のみを置き、その他のリソースは随時必要に応じて読みだす仕組みになっていました。それをディスクに移植するに当たっては、細かい修正をしないためにも、DSのROMイメージを丸々Wiiのメインメモリに常駐させるという手法が取られました。しかしそうするといかにWiiのメインメモリでも厳しい。そこで、ムービーはディスクに置き、ボイスデータはテンポラリのNANDメモリに出すというやり方で乗り切ったそうです。

その他にも、DSのソースコードをWiiで流用することについての懸念や、Wi-FiコネクションをWiiとDSでマッチングすることについての動作確認など、様々な個所で任天堂とは緊密に取り組み、無事に完成を迎えたということです。


メインメモリとの戦い	その他の様々な戦い	まだまだあります

開発を終え、汎用ライブラリが出来上がり、既存のタイトルであれば簡単にWiiに移植することができるようになったそうです。しかし紙山氏は「今回はたまたまゲームデザインとWiiとDSの両方で、ということが一致しただけで、どんなゲームにでも意味があるわけではなさそう」と振り返りました。

ちなみに今回、任天堂業務技術部とのメールは総計1082通となり、「史上最多ではないか」(光吉氏)とのこと。「任天堂は、面白くて新しいこと、みんなを驚かすことに関してはどんどん協力していきたいと思うので気軽に相談して欲しいです」と講演を締めてくれました。ただ、「普通は50通ですよ」と釘を刺すことも忘れませんでした。

ちなみに最終盤には、テレビCMでどちらのロゴを最初に出すか、といった問題もあったそうです。