DOOMソースコードを読み解く 第2回

今回も第1回と同じく、まだソースコード自体には立ち入らず、予備知識を付けるための周辺的な話をしてみたいと思います。


DOOMの魅力の一つが、ユーザーが自分でマップを作れるという点にある事は言うまでもないと思います。
しかし、DOOMはどうやってそれを可能にしたのでしょうか？

id softwareは1997年の末にDOOMのゲームプログラムのソースコードを公開しましたが、実はDOOM関連のソースコードを公開したのはこれが初めてではありません。
正確な時期はわかりませんが、おそらくDOOMを発売して間もない時期に、id softwareは自分たちがDOOMの開発時に使ったツール群のソースコードを公開しています。
この中にDOOMの公式のレベルエディタであるDoomEDがありました。
そしてこのDoomEDのソースコードを元にして、プログラミングに通じた一部の人たちが独自のレベルエディタを作っていきました。

考えてみると、当時使われていたレベルエディタはすべて一般のユーザーが作った非公式なものだったのは不思議といえば不思議です。
何故そうなったかと言うと、公式のレベルエディタであるDoomEDがDOS/Windowsマシン用ではなく、NeXTマシン用に作られていたからです。
そこでソースコードだけを公開して、プログラミングの心得のあるユーザーに独自のレベルエディタを作る事を促したわけです。

話は少し逸れますが、NeXTというのは言うまでもなくアップルを追われた後にスティーブ・ジョブズが作ったコンピュータ会社です。
ジョブズには、どういう訳か教育機関向けのPCを作るという願望があって、NeXTも最初は大学などの教育機関向けに販売されたそうです。
ジョブズ復帰後のアップル復活のきっかけを作ったともいえる大ヒットした初代iMacも、発売前は教育機関向けのPCになると言われていました。
NeXTの場合は、教育機関向けのわりには値段が高かった事が失敗の原因と言われていたので、今度は低価格のiMacで再挑戦したかったのではないでしょうか。

話を元に戻すと、id softwareはこのようにNeXTを使ってDOOMを開発していましたが、DOSゲームが盛んだった頃は、開発だけはUNIX系のワークステーションを使う事は一般的に行われていたと思います。
結局当時のDOSマシンでは、あまりにも非力だったからでしょう。
それでも、NeXTを開発に使っていた会社はほとんどいなかったと思います。NeXTマシンのCPUはモトローラの68000系で、これは当時のMacやアミーガと同じですから、それほど性能が高いわけでもなかったと思います。
NeXTを採用したはっきりした理由はわかりませんが、とにかくそれによってDOOMの開発ツールのソースコードは、NeXTのOSであるNeXTSTEPの標準開発言語であるObjective-Cで書かれる事になりました。
そうは言っても、Objective-CはC言語の機能はすべて備えていて、John CarmackもなるべくC言語の機能だけを使っていたようなので、DOSなどへのポートが比較的容易だったようです。

下の画像は、NeXTSTEP上で開発中のDOOMの様子です。




この画像は、自分が持っているGAME DEVELOPER誌のバックナンバーを収めたCD-ROMの中の1994年1月号の記事からキャプチャしたものです。

自分は、DOOMのゲームプログラムのソースは公開して間もない頃から少しはいじってはいましたが、2003,4年頃にたまたまどこかでid softwareがそれよりも前に公開していた開発ツールの一つであるノードビルダーのソースを入手してから本格的にDOOMのソースポート等のプログラム作りを始めました。
BSPツリーのアルゴリズムについては既にだいたいはわかってはいましたが、このオリジナルのノードビルダーのソースコードを読んで具体的なBSPツリーの構築方法が理解できた事が大きかったです。WadCraftでのBSPツリーの構築の部分は、このコードをほぼそのままの形で使っています。
現在でもオリジナルのノードビルダーのソースコードはこちらからダウンロード出来ます。

DOOMソースコードを読み解く 第1回

本ブログは、DOOM を様々な角度から深く掘り下げていく事を趣旨としていますが、今回からは DOOM をソースコードという側面から分析して、ゲームの挙動、プログラム上の制限等を考察し、不定期にではありますが、連載記事にしていこうと考えています。

今回は初回でもあるので、まずはプログラムその物には踏み込まず、肝心の id software が公開したソースコードの簡単な紹介をしてみたいと思います。
しかし最初に言っておきたいのは、ここで言う DOOM は DOS ゲームとして発売された DOOM および DOOM2 の事で、DOOM3 や今後発売される予定の新DOOM (DOOM4 と呼ばれていたもの)の事ではありません。また、現在では id の公開したソースを元に様々なソースポートが作られていますが、それらはあくまで傍系なので、オリジナルの id のソースコードだけを考察対象とします。

さて、今しがた id の公開したソースコードを「オリジナル」と呼びましたが、残念ながらこの公開されたソースコード自体が、実は本当のオリジナルである DOS 版の DOOM を Linux にポートした物です。
何故そうなったかと云えば、id が DOOM を作る時にサウンドプログラミングだけは他社製のサウンドライブラリを使っていたため、そのソースコードが残る DOS 版のプログラムは契約上公開出来ないとの理由からだそうです。この事は、ソースコードに付随する John Carmack が
書いた readme.txt で述べられています。(この readme.txt は非常に重要で、本連載では何度か言及すると思いますので、勝手にソースコードのアーカイブから抜き出してアップさせてもらいました。)
その本体のソースコードのアーカイブファイルはこちらからダウンロード出来ます。
もちろんLinux版のソースコードなので、そのままではビルドは出来ないので、ほとんどの人にとっては無用かもしれませんが、やはり唯一の「公式」なソースコードですので、リファレンスとして持っている価値はあると思います。

最後に、この DOOM のサウンドコードだけが他社製ライブラリだった事について少し考えてみたいと思います。
readme.txt の中では Carmack は「今だったら自分でサウンドコードが書けたのに...」と言って当時はその知識が無かった事を示唆していますが、DOS の時代は AdLib や Sound Blaster といった各社のサウンドカードに合わせて、アセンブラを使ったプログラムを書かなければならなかったと思いますので、そういったサウンドライブラリを提供する会社があったんだろうと思います。おそらく当時の DOS ゲームの製作会社の間では、そういったライブラリを使うのが普通だったのではないかと推測します。