イースの制作日記で自分がやったことの中で経験値繋いで一本にしたとか、シナリオの修正をしたことは大事だけど、技術的なことは、過去の遺物の話なのでワリとどうでもいいと思っていたのだけど、去年の年末にあったイースの同窓会みたいな飲み会で進藤が「そんなこと知ってるのはHahi君と岩崎さんしかいないから、後世の人のために残しておけ」というので書いておくことにした。

ところで、これが天外２のセクションに入っているのには若干の理由がある。
このシステムは『イースⅠ・Ⅱ』を作っているときに、どえらい目にあって作り上げ、それをivに対応させて、なおかつイースの時よりも改善してシステマチックに完成させたのが『天外Ⅱ』だった。
特に『天外Ⅱ』では多人数で作るのが前提になっていたので、以下のようになっていた。

• １国1人のivプログラマ。
• 一国単位で完全に独立して制作可能。インターフェースは全て構造化されている。
• 基本の移動・戦闘システムなどは必要なファイルだけを回覧（フロッピーで回覧であるｗ）
• 全体のファイルはテープで回覧し、ビルドは一日一度夜だけ行う。

フルビルドすると8時間かかるために、システムが完全に分離されていて、独立してビルド出来ることがとても大事で、そこらへんの整合性まで取ったバージョンとして完成し、以後、PCエンジンで仕事をしている間ずっと使い、PS1でも実は使い、PS2時代になって初めてIDEに全部切り替えたりするぐらい長く付き合ったのが、このmakefileなので『天外Ⅱ』 のセクションに入っているわけである。

なお天外２では、最終的には１国を１人のプログラマが担当＋システム＋バトル３人＋ビジュアル＋ivを使ったイベントみたいな感じの構成で、総計は20名を超える制作者を管理できるようにシステム化したけれど、最初にシステム化した『イースⅠ・Ⅱ』の時ほどツラくはなかった

さて。
make/makefileについては今では知らない人もいるだろうから説明すると、今の目から見ると原始的な自分の手で書いて管理するbuild systemだ。
まずソースと出来上がるバイナリの依存関係を記述したmakefileと呼ばれるファイルを自分で書く。
思い切りわかりやすい単純な例で、foo.c をcc すると。foo.exeが出来るとする。
makefileという名前のテキストファイルを作り、下のような内容を書き込む。

foo.exe: foo.c
 cc foo.c

そしてコマンドラインから”make”と打ち込むとfoo.exeがなければ、
cc foo.c
が実行されて、foo.exeが出来上がる。

わかる人には当然わかるが、これは全く無駄な記述方法だが、例としてわかりやすく記述している。また出てくるバイナリがfoo.exeばかりではないというのもわかっているが、そこらへんは単純化していると理解して欲しい。

ここで重要なのがfoo.exeがfoo.cよりも新しい間は、 cc foo.cはいくらmakeと打っても実行されないこと。
そして逆にfoo.cが1秒でもfoo.exeより新しくなると、cc foo.cは実行されるようになる（またfoo.exeがなくてもビルドされる）。
かくして、foo.cとfoo.exeの間には時間を介した依存関係ができ、foo.cを編集して保存してmakeと打ち込めばたちまちfoo.exeが出来上がるようになる。
これだけなら「だから？」なのだけど、foo.exeはfoo.cとhoge.cの二つのファイルから出来上がるとする。
これがmakefileで書くと

foo.exe: foo.c hoge.c

と書けば（本当はもうちょっと追加がいるけれど）、foo.exeよりhoge.cかfoo.cが新しいと、ccが走ってfoo.exeが生成される。
つまり「foo.cかhoge.cを編集してmakeをすると、foo.exeが出来上がる」ようになる。
こんな風にして「ファイル同士の依存関係から自動的に更新するべきファイルを更新して、これを繰り返して自動的にいろんなものをbuild出来るようにする」のがmakeとmakefileだと理解してくれるとありがたい。

まあ二つぐらいのファイルならありがたさもよくわからないが、数百・数千のファイルがあって、かつ「AというファイルはBを書き換えたら更新しなければいけない。BというファイルはCとDが更新されたら…」なんて関係があったら、そんな更新を人間がやるのはばかげてるし、これがどんだけありがたいかわかるだろう。

ついでに書くと、このファイルのリストそのものを自動で生成させることが出来るので、makefile自身がmakefileを更新するマネをやらかすのも当たり前だった(今ならpythonとかperlあたりを使う所だろうが、当時はsedとawkを駆使していた）

ところでこの記事を書いているときに「まだmakeって使ってるのかなあ？」とtwitterで聞いたところ、まだまだみんな使っているといっていた。古いシンプルなツールはなくなりにくいって典型かもしれない

ここまでは話の前振り。
話はまだ僕がゲーム屋としてピカピカの新米だった1988年に戻る。
この当時、ハドソンではあまりmakeは使われていなかった。
僕が覚えている限りでは、かなりの人がバッチでバイナリを生成していて、makeを使っていたのは飛田さん・和泉さんあたりのCでツールを作る人たちぐらいだったと記憶している。

ちょっと付け加えておくと、インハウスでCでツールを自作するのは全く当たり前だったし、プロジェクト一回ごとにだいたいお手製の特殊ツールが必ず登場した。

どうしてなのか？
まず88年にはDOSの上ではmakeはメジャーでなかった。
当時、makeが普通に付属していた開発環境でアマチュアの手が届く範囲にあったのはLSI-Cの試食版（フリー）・Turbo C（すっごい安い）・MS-C（安くないけどMSのだから）ぐらいだったので（のはず。Lattice-Cとかについていたかは覚えてない）、そりゃ使っていない人もいるのもムリはない。

この記憶はストレートに書くが定かではない。確実についていたと思うモノについて書いてある。

また実用的な意味がまだ薄いって理由もあった。

なぜなら、この当時のROMのゲームはメガビット、すなわち128キロバイトぐらいのサイズで、４～８メガビット、つまり512キロバイト～１メガバイトもあれば、超大容量だ。
そしてその512～1メガバイトのうち、プログラムと呼べるのはたぶん64-256キロバイト程度だったと思う。で、それらのプログラムは数十、多くて200程度しかないファイルで出来上がっていたのだから、別段バッチファイルでもそんなにつらくなかったわけだ。

次に、そもそも初期のファミコンで使われていたACT65がアブソリュートアセンブラなので、ビルドは毎回フルになってしまう（正確にはフルでなくす方法もないではないが、実用性に問題がある）。
このあたりは説明するとウルトラ大変なので、ともかくアブソリュートアセンブラは、関係があるところは全部ビルドしないとビルドが完成しないルールがある、と思っておいてほしい。
だからバッチファイルで十分だった…という理由もあったりしたわけだ。

これを書いていて、当時、ビルドするのを「アドレスをなめる」という表現があったのを思い出した

このアブソリュートアセンブラの環境は飛田さん作のas/lkで終わる。
asは中間ファイルの.o を生成する。そしてlkが複数の.oから実際のファイル（.binって名前をつけていた）が生成される。つまり全部のプログラムをアセンブルする時代から、必要なオブジェクトを必要なタイミングで生成できる時代になる。
でも僕がハドソンで仕事を始めたときは、飛田さん作のasに移行してまだ1年程度なのだから、そりゃあハドソンの中では、まだまだバッチファイルでゲームを作る人がいても驚かない。

では僕はどうだったのか？
自分がやっていた仕事(OS-9/68000 の上でいろんなツールを作るお仕事）の都合でmakeを使うのは当たり前だったので、makeを使っていた。というかないと暮らせなかった。

ここらへんで面白くも微妙な話をすると、コンピュータがお仕事になったとき、最初に仕事道具として使ったのはVAXの上に乗っからかっているUNIX 4.2BSDで、そのあとはSONY NEWS、Appolo Domain、IRIS 2000/3000といったワークステーション群とOS-9/68Kが乗っからかったCD-iの開発システムだった。つまりUNIX系の環境で暮らしていたわけだ。
だから実はハドソンに行ったとき「うわ、またMS-DOSに逆戻りか！」と思ったのがホントーだったりする。

とはいっても、バッチファイルで生成するのがそこまで非効率だったのか？
この質問を立てると、ここに微妙な話が出てくる。
上に書いた通り、当時のゲームマシンのソフトウェアは出力されたバイナリがせいぜい128キロバイト程度のファイル数にして数十～グラフィックまで含めても数百もあれば大きな方に入るモノだ。
そして飛田さんのasとlkは当時としては飛びぬけて高速で、別にバッチファイルでドーンと全部アセンブル＆リンクしてもそんなにつらくはなかったので、少なくともROMであるうちはmake/makefileなんてめんどくさいものを使う必要はなかったわけだ。

ちなみに当時のMS-DOSはファイル名は8.3形式、つまり8文字のファイル名＋拡張子で終わりだった。これはファイル名にもフォルダ名にも同じ制限がかかる。
だから”サルモン神殿東端ブロック”なんて名前はもちろん付けられず”sal01.s”なんてソース名がついていたわけである。

というところで、次回に続く。

Tweet

Pocket