イースの制作日記で自分がやったことの中で経験値繋いで一本にしたとか、シナリオの修正をしたことは大事だけど、技術的なことは、過去の遺物の話なのでワリとどうでもいいと思っていたのだけど、去年の年末にあったイースの同窓会みたいな飲み会で進藤が「そんなこと知ってるのはHahi君と岩崎さんしかいないから、後世の人のために残しておけ」というので書いておくことにした。
ところで、これが天外２のセクションに入っているのには若干の理由がある。
このシステムは『イースⅠ・Ⅱ』を作っているときに、どえらい目にあって作り上げ、それをivに対応させて、なおかつイースの時よりも改善してシステマチックに完成させたのが『天外Ⅱ』だった。
特に『天外Ⅱ』では多人数で作るのが前提になっていたので、以下のようになっていた。



フルビルドすると8時間かかるために、システムが完全に分離されていて、独立してビルド出来ることがとても大事でそこらへんの整合性まで取ったバージョンとして完成し、以後、PCエンジンで仕事をしている間ずっと使い、PS1でも実は使い、PS2時代になって初めてIDEに全部切り替えたりするぐらい長く付き合ったのが、このmakefileなので『天外Ⅱ』 のセクションに入っているわけである。
（なお天外２では、最終的には１国を１人のプログラマが担当＋システム＋バトル３人＋ビジュアル＋ivを使ったイベントみたいな感じの構成で、総計は20名を超える制作者を管理できるようにシステム化したけれど『イースⅠ・Ⅱ』の時ほどツラくはなかった）

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


そしてコマンドラインから"make"と打ち込むとfoo.exeがなければ、
cc foo.c
が実行されて、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より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を駆使していた）


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


どうしてなのか？

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


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

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



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

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


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



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