第 5 回：Revolution SDK と「Wii メニュー」への統合
Wii の公式開発環境は、開発コードネームを冠した「Revolution SDK」と、実機開発ハードウェア「NDEV」を中心に構成されていました。しかし、その新しい名称の下に流れているのは、ゲームキューブ用 Dolphin SDK の明確な血統です。CPU の命令セット、GX グラフィックス、VI、AX、PAD といった基礎が継承されたことで、開発者は前世代で積み上げたソースコードと知識を、大がかりに捨てることなく Wii へ持ち込めました。「Revolution」を名乗りながら、開発現場に無用な革命までは強いない。この慎重な連続性が、Wii のソフトウェア開発を支える出発点だったのです。
その連続性は、ビルド環境の隅々にまで及んでいます。公式コンパイラとデバッガには Metrowerks CodeWarrior が使われ、SDK のビルドシステムは Windows XP 上の Cygwin と GNU Make を組み合わせる構成でした。全ライブラリを一括して利用する <revolution.h> のほか、<revolution/os.h> や <revolution/gx.h> のように必要なモジュールだけを選べる構造を持ち、さらに旧来のインクルード形式を受け止める互換用ヘッダーまで用意する。ハードウェアだけでなく、コードを移す際の細かな摩擦まで徹底して削ぎ落としていたのです。
もっとも、Wii を「そのまま高速化したゲームキューブ」と考えれば、本質的な変化を見落とします。A メモリは廃止されて大容量の MEM2 へ統合され、セーブ先はメモリーカードから NAND フラッシュへ、標準入力は PAD から WPAD / KPAD へ、さらにネットワークや保護されたストレージへのアクセスは IOS 経由へと変わりました。Revolution SDK は、使い慣れた GX や OS の感触を残したまま、開発者をこうした Wii 固有のメモリ、入力、I/O へ無理なく導く「新旧アーキテクチャの橋」として設計されていたのです。
市販 Wii の白く小さな筐体とは対照的に、公式開発機「NDEV」は、無骨な黒い箱の姿をしています。その役割は、Wii 相当の処理を実シリコンで動かすだけではありません。ホスト PC からプログラムを直接投入し、光ディスクを仮想的に再現し、デバッガを接続し、実行ログを外へ引き出すための専用インターフェースを一台へ集約した、いわば「内部をむき出しにした Wii」でした。
PC 上のディレクトリを仮想ディスクとして見せ、データを変えるたびに光ディスクを焼き直す手間を消します。
Host I/O（HIO2）を使い、実行中のゲームとホスト PC の間で開発用データをやり取りする通信経路です。
RS-232C を使う端末出力の経路です。OSReport などの実行ログを PC 側から監視できます。
CodeWarrior と実機を直結し、ELF のロード、停止、ステップ実行、メモリやレジスタの観測を可能にします。
NDEV とホスト PC は、DI、COM、DEBUG の 3 系統でそれぞれ USB 2.0 接続され、さらに端末出力用の RS-232C SERIAL を備えていました。COM は Host I/O によるゲームと PC 間のデータ通信、SERIAL は OSReport など人間が読むログ出力と、役割が分けられていました。さらに、無線状態に左右されず入力を再現するため、専用ハブを介して有線 Wii リモコンを最大 4 台まで接続できました。製品版ではケーブルを消し去ることに価値がある一方、開発現場では同じ条件を何度でも再現できることに価値がある。NDEV は、ユーザーに見せたい「魔法」と、その魔法を冷静に検証するための現実を、鮮やかに切り分ける装置でもあったのです。
第 3 回で見た通り、Wii の内部では Broadway と Starlet という二つのプロセッサが、全く異なる責務を担っています。しかし Revolution SDK のライブラリ群は、Broadway から直接制御する高速なハードウェアと、Starlet / IOS へ処理を依頼する保護された I/O を、同じアプリケーションから自然に扱えるよう整理していました。開発者がアクセスのたびに IPC の内部形式やハードウェアレジスタを組み立てるのではなく、目的に応じた API を呼べばよい。複雑な二重構造を覆い隠し、その性能と安全性だけを引き出すための、巧妙な窓口だったのです。
| 主なライブラリ | 対象 | 設計上の意味 |
|---|---|---|
OS / MEM |
割り込み、スレッド、キャッシュ、MEM1 / MEM2 | 二つのメモリアリーナを明示して、配置を制御する |
GX / VI |
Hollywood の描画と映像出力 | GC から継承した低オーバーヘッドの描画経路を保つ |
AX / AI |
DSP、ミキシング、音声出力 | DSP によるミキシングと本体の音声出力を扱う |
WPAD / KPAD / PAD |
Wii リモコンと GC コントローラ | 新旧の入力方式を別々の API で共存させる |
DVD / NAND / SC |
ディスク、内蔵保存領域、本体設定 | IOS の権限管理下にある資源を安全に利用する |
HIO2 |
NDEV とホスト PC 間の Host I/O | 実行中のゲームと PC ツールを開発用データ通信で結ぶ |
| RevoEX / RFL / HBM | ネットワーク、Mii、HOME メニュー | Wii 共通の操作や画面を各タイトルへ組み込む |
ネットワーク機能は、基本 SDK から切り分けられた拡張パッケージ「RevoEX」として提供されました。また、Mii を管理・描画する RFL (Revolution Face Library) や、共通の HOME メニューを表示する HBM ライブラリも用意され、各ゲームが本体機能を一から作り直す必要をなくしています。どのタイトルを起動しても Mii は同じ顔で現れ、HOME ボタンは同じ画面を呼び出す。Wii が重視した「本体全体で統一された振る舞い」は、表面的なメニューデザインだけでなく、SDK の分割方法そのものにまで刻み込まれていたのです。
しかし Wii において、開発の成果物は実行ファイルが動いただけでは完成しません。ユーザーはゲームを始める前から、ディスクドライブチャンネルに表示されるアイコン、アニメーション、名称、そして音を通じて、そのタイトルと出会います。セーブデータも本体のデータ管理画面から一つの製品として識別される。つまり Wii のゲームは、画面の中で遊べるだけでなく、Wii メニューの中で正しい「顔」を与えられて初めて完成するのです。
CodeWarrior と SDK ライブラリでリンクし、デバッグ情報を保持した ELF を作成します。
NdevRun でプログラムを投入し、PC のディレクトリを仮想ディスクとして何度もテストします。
実行コードを DOL 形式へ変換し、Apploader、ファイルシステムテーブル、データを製品同様の起動構造へ配置します。
ディスクドライブチャンネル用バナーを組み込み、リージョンや製品情報を設定した提出用マスターへ仕上げます。
opening.bnr に入るもの公式ツール WiiMakeBanner.exe は、タイトル名などのヘッダー、アイコンのレイアウト資産、プレビュー用バナー、サウンドを一つのパッケージへ束ねます。ディスクタイトルでは、これを opening.bnr として仮想ディスクのルートへ置くことで、Wii メニューのディスクドライブチャンネルに初めて「顔」が現れます。しかもパッケージの上限は 512 KB。ユーザーを長く待たせない小さな容量の中へ、視覚と音による第一印象を凝縮しなければならなかったのです。
一方、セーブデータ用のバナーは別に生成される成果物であり、Wii のガイドラインでは、必要なセーブファイルを作った最後に生成するよう定められていました。バナーだけを先に置けば、本体のデータ管理画面には有効なセーブとして見えるのに、ゲーム内部のデータは不完全という危険な状態が起こり得るからです。メニューに浮かぶ小さなアイコン一つでさえ単なる装飾ではなく、電源断や破損からデータの整合性を守る、ファイルシステム設計の一部だったのです。
Wii プログラミングガイドラインは、Wii 向けタイトルが満たすべき必須・推奨の実装事項を示す開発資料です。完成したマスターを任天堂へ提出し、規定に適合しているか確認する検査工程がロットチェックです。
Wii プログラミングガイドラインが求めたのは、単にゲームがクラッシュせず最後まで動くことだけではありません。ストラップ装着の案内、Wii リモコンの切断や電池低下への対応、HOME ボタンを押した直後の共通メニュー、本体設定に応じた言語と画面比率、NAND の容量不足や読み書き失敗、そしてリセットと電源操作。家庭のリビングで起こり得る無数の状態を一貫して扱うところまでが、Wii における「完成した製品」でした。
その象徴が HOME メニューです。各社が似て非なる終了画面を独自に作るのではなく、SDK 付属の HBM ライブラリとレイアウト資産をそのまま使い、どのゲームでも同じ操作で本体へ戻れることが要求されました。ディスクドライブチャンネルのバナー、セーブアイコン、Mii、通信設定にも、同じ思想が貫かれています。個性豊かなゲームを Wii メニューという一つの玄関へ接続し、子供でも大人でも、初めて触れた瞬間から迷わず扱える振る舞いを守り抜くためです。
開発会社は提出前にロットチェックの確認項目に沿って動作を検証し、その結果をマスターとともに任天堂へ提出しました。ここまでを含めて「開発環境」と捉えたとき、Revolution SDK の真の姿が見えてきます。それは Hollywood を高速に叩くためだけの関数集ではありません。ソースコードを実機で走らせ、Wii メニューの一員として正しい顔を与え、家庭で起こる例外に耐えさせ、最後には誰もが迷わず遊べる製品へ仕立て上げる。試作コードを、リビングに置ける「Wii のゲーム」へ変える工程そのものだったのです。