今のゲーム屋なら、誰でもTRCというものを知っている…と思う。

TRCっていうのはどういうものかというと、大雑把にはハードメーカーが決めている規定を守っていますか？　というチェックシートだ。これをマスター提出時にひっつけて出すことになる。
で、TRCを守っているかどうか、バグがないかも兼ねてハードメーカーがチェックを行い、OKなら発売される。
つまり、ゲームが発売にいたるためには
１）ゲームを作り、社内でデバッグし
２）TRCをつけて、マスターを提出し
３）ハードメーカー側がTRCを守っているか、加えてバグがないかチェックし
４）全てOKなら発売される
…というシステムだが、これが出来たのは、僕が知っている限りではPS1からだ。
もちろんFCやPCエンジンの時代も似たようなものはあったが、システマチックに完成されたのはPS１が最初だと思う（もしメガCDでこれがあったならスマンだけど。僕はMDは手伝ったことしかないのよ…）。

では、どうしてPS1でTRCみたいなものが登場したのか…というと、これはゲームハードの歴史の話と絡む。
ファミコンやPCエンジンではどんなチェックをやっていたのかというと、ファミコンの場合にはROMを提出するときに「ハード的な規格」を書いた紙をつけていた（1本しかやってないから記憶間違いだったらすまぬ）。PCエンジンも同じ。
そしてハードメーカーから、内容のチェックとともにメジャーなバージョン毎に動作確認をして「Ｘで動きません」みたいな感じでレポートがＦＡＸで返ってきていた。（当時はインターネットがないから）。
こんなモンでよかったのは、ゲームハードが単純だったから。
例えばファミコンでは電源を切らずに次のソフトに切り替えることは出来ない。だから切り替えのことなんて考えなくて良かった。（もちろん引っこ抜いて変えれば出来ないこともないが、そんなことまでチェックをする必要はデベロッパー側にはない）
BIOSすら載っておらず、リセットされた瞬間にROMカートリッジでプログラムが動くから、ハードウェアの初期化から全て自分で行うことになる。だから自分のやりたい放題。せいぜいが拡張端子に専用コントローラが刺さってないか程度のチェックで十分だった。
ハードメーカーは起動＆動作確認をハードの癖が違う各バージョンで行えばよかった。また初期化や操作が単純なので、ハードメーカーがハード的なチェックをすることでオッケーだった（簡単に追いかけることが出来る）。

ところが、話が怪しくなりはじめるのがCDROMの登場からだ。
CDROMはCDROMにセーブできないから、セーブ用のバックアップは外部に持っている。つまりセーブデータは共用になるのは確定で、勝手にムチャするわけにはいかない。またCDROMには規格があり、それを満たしていないとCDROMと名乗れない。さらにうっかり変なプログラムを書くとハード的な負荷がかかったりする。だからアクセスは直接ハードを操作するのではなく、メーカーのプログラムを経由しないとダメ！　ってことになった。つまり初期のCDROMマシンにはOS…と呼べるほどではないが、ファイル管理だのCD制御だの…PCまがいの使い方が出来るように入れたグラフィックルーチンだの結構高級なシステムプログラムが搭載されることになり、それを経由せずにプログラムするのはまかりならんという話になった(PCエンジンではこれをBIOS、Basic Input Output Systemの略…と呼んだ。いわゆるシステムカードだ）。
だから、PCエンジンCDROMでは、マスターに書くことが結構増えてめんどくさくなった。

この初期CDROMゲームマシンがさらに進んだのがPS1世代。
PS1は開発環境をC／C++に置き、ハードウェアはSCE謹製のライブラリを経由して操作し、直接操作を許さないことになった（後にこの制限は緩和される）。
結果としてPS1のゲームは「SCE製のライブラリ＋メーカー製のプログラム」の形で出来上がり、ゲームプログラムはハードを操作するときゲームプログラム→SCE製のライブラリ→ハードウェアという構造を持つにいたった。
簡単に書いてしまえば、ゲームマシンがまあPCみたいな構造になり、PCみたいなゲームの書き方になったわけだ。
どうしてこんな風になったのかといえば、PS1世代（３DO・SSなど）はそれまでのゲームマシンと比較して桁違いに複雑なハードで、なんのサポートもなく一からプログラムを書いていたのではやってられなかったからだ。
動画展開用のデコーダだのジオメトリエンジン（GTE）だのGPUだの、複雑怪奇なVDPだのがあったり、CPUが２つあったりしたし、ソフトは２Dと３Dが入り混じるのが当たり前になり、テクスチャだの頂点カラーだの、ライティングだのが登場し、メモリカードを引っこ抜いて差し替えたり、ゲームが複数ディスクで構成されたり、ストリーミング（動画やデータをCDからプログラムを止めずに読み込むこと）が出来たりと、一つ前の世代と比較して、桁違いに複雑で*VideoControl=0xDEADFACE; なんてイチイチやってたら命がいくつあっても足りない。
それに開発環境は基本的に高級言語（サターンでもCが提供されていた。噂によると初期版はかなりエエエな出来だった）で当然ライブラリは供給しやすい。そしてハードを良く知ってるのはメーカーだ。
だから、ライブラリを作るのに一番向いてるのはメーカー…というわけで、メーカーがライブラリを提供するようになった。
ところが、こうなると
●ハードには相変わらずバージョンがあり（ライブラリが違いを吸収する＜こと＞になっていたが、現実は…）
●メーカーのライブラリもバージョンがあり（しかもメーカーのライブラリにも致命的なバグがあることも…）
●さらに開発機と実機の差が大きくなり（メモリ搭載量が全く違った）
●メモリーカード、コントローラなどの扱いがやたらと複雑化した。（抜き差しのプロセス自体が複雑）
ゲーム開発はとても面倒くさいことになり、マスター提出時に書かないといけないことも飛躍的に増えた。「ライブラリはバージョンいくつが使われていて、メモリカードはこんなんで、ストリーミング時のエラーはちゃんと処理してるか？」みたいな具合だ。
つまりだ、PS1世代で、メーカーがライブラリまで提供するようになったので、ソフトとハードのチェックが入り混じるようになり、その両面についてチェック事項のフォーマットをカッチリ決めたのがTRCだったということだ。
ところで、下らないトリビアを書くと、多分、僕は世界で一番TRCを提出した人間の1人なのは間違いない（正確にはそのグループの1人）。
というのもTRCは当然のことながら、付録CD/DVDにも適用されていた。
そして僕は、電撃プレイステーションD／PS2を約10年、本数にして約100本ちょっと作っている。つまり100回ほどTRCに関わっている。これに加えてPS1のゲームで3本、PS2のゲームで2本の計５本が追加されるので、110本近くのTRCに関わっている。
これに対抗できる人間は、多分世の中では、僕の同僚だった電撃PSDのデータ管理をしていたヤツだけだろうと思うｗ

Tweet

Pocket