ゲームの開発環境
80年代・90年代のゲーム開発環境について の講演資料。興味深い。HSPの人による70-80年代の講演もある( http://www.digrajapan.org/modules/mydownloads/singlefile.php?cid=11&lid=17 )。
日本における家庭用ビデオゲームの本格的な普及はファミコンからで、ファミコンは当時としては非常に画期的なスペックを持っていたのでファミコン以前の開発環境がいかに"牧歌的"であったかはなかなか理解されづらいかもしれない。
リバースエンジニアリングによる業界への参入はそれなりに行われている。ナムコに関して言えば、
- MIDWAYの8080基板を解析して業務用ブロック崩しに参入
- (スライドにあるように)ハードウェアの解析によりファミコンに参入
- 同じくハードウェアの解析によって制作されたクインティ(ゲームフリーク)を販売
と、かなりの関連が有る。現在こそVirtual ConsoleやGame Archivesのように、エミュレータによって過去のゲームを再現することができるが、いわゆる"移植"のためにはリバースエンジニアリングは不可欠だった*1。
クロス開発
本質的には、ゲームの開発環境はクロス開発環境であることが最大の特徴と言える。一般に、ゲームコンソールはPC(やミニコン)よりも貧弱なコンピューティングリソースに特殊なグラフィックスハードウェアを搭載したものであるため、アセンブラのように大量にメモリとCPUサイクル、I/O能力を消費するソフトウェアを動作させることはあまり現実的でない。
...この点は現在の開発環境にも当てはまるため、"live preview"機能がゲームエンジン(= ゲーム開発環境)のウリとして挙げられることが未だにある。他にも、アーティストがハードウェアを理解しなければならない点なども現在と共通している。
ゲームコンソールのクロス開発環境は2段階の進化をしている。
1) ホストPCと緊密に連携する拡張ボードとしての実装。これは、PC Engineくらいまでのゲームコンソールでは開発サイクル全体で用いられ、現代のゲームコンソールであっても(チップ単体の検証などの目的で)開発の初期段階に用いられることがある。
ファミコンはスライドにあるようにFM-R*2にintsys(パネルでポン等のゲームも開発している)のエミュレータボードで構成されていた。おそらく、当時の外部バス(シリアルや8bitパラレル)は頻繁なプログラムの入れかえやprobingに使えるほど高速でなかったのが原因に思える。
2) デバッグ専用の本体。現在の開発でも一般的に利用されている。バスアナライザのようなデバッグ用の追加ハードウェアを搭載しているケースも多い。
ゲームコンソールそのものと同様、全てをin-houseで作ることは稀であり、開発環境はより多くのサードパーティが関わるケースが多い。
- in-houseに近いベンダを使用するケースも有る。
- インテリジェントシステムズはハードウェア開発環境にも多くの実績が有る。http://www.nintendo.co.jp/nom/0703/12/index.html
- CRIのミドルウェアはセガの開発環境に採用されている。
- もちろん、多くの開発用コンポーネントはゲーム以外の企業から調達しているケースが多い。
SS以降の全てのコンソール(Xbox除く)でGNUまたはGNUPro(Cygnus、現RedHatによる)やexeGCC(KμCによる)といったGNU系の開発ツールを提供している。このため、同時に大抵のコンソールではELFフォーマットを標準のオブジェクトフォーマットとしているように見える。
抽象化(BIOS)
日本のゲームコンソールで最初に(一般的意味の)BIOSを採用したのはファミコンディスクシステムだと考えられる。ディスクシステムのBIOSは、ファイルの読み書きなどをサービスcallとして備え、ライセンスされたゲームはBIOSを通してディスクにアクセスすることが期待されていた。
BIOSによる抽象化は一般にうまく機能していない。ディスクシステムやPSで独自のファイルシステムを採用するケースが有る。
GameboyやSEGA Master Systemのように、初期化やロゴの表示、カートリッジのセキュリティチェック等のために利用される起動ROMは比較的早期から採用されていた。
インディース開発環境
スライドにあるように、正当な方法で制作されたインディース開発環境もいくつか存在する。これらはあまり成功したとは良い難い。逆に公式の環境(iPhone SDK、XNA、...)は非常に大きく成功している。SONYのNet Yarozeはクリエイタ発掘としての機能は果たしたように思える。
the Internet上で最も初期に成功したインディース開発環境はGBDKだろう。これは、カスタマイズされたSDCC Cコンパイラと、いくつかのライブラリの組合せで、GBの(PC上で動作する)エミュレータは比較的完成度が高かったことと、GBのCPUが普及したZ80にかなり近かったことで受け入れやすかったことが原因と考えられる。
GBDKはnanoloopやLittle Sound DJのような音楽ツールの制作にも使われ、任天堂ライセンシのうちいくつかはこれらの環境での制作からライセンシとなった企業も有る。
PSやGBA以降は、GNUツールとNewlibの組合せが一般的に利用されている。
インディースと公式開発環境の間の溝は急速に埋まりつつある。Bullet PhysicsやExpatのように、ゲームコンソールで一般的に利用されるオープンソースライブラリも非常に多く存在し、採用は拡大の一途であるように感じられる。
