ドゥームエンジン

id Tech 1はDoomエンジンとも呼ばれ、id Software のビデオゲームDoomおよびDoom II: Hell on Earthで使用されているゲームエンジンです。また、Heretic、Hexen: Beyond Heretic、Strife: Quest for the Sigil、Hacx: Twitch 'n Kill、Freedoom 、およびライセンシーが制作したその他のゲームでも使用されています。これはJohn Carmackによって作成され、 Mike Abrash、John Romero、Dave Taylor、および Paul Radekによって補助機能が記述されました。もともとNeXTコンピュータで開発されましたが、^[3] Doomの最初のリリースのためにMS-DOSおよび互換オペレーティングシステムに移植され、後にいくつかのゲームコンソールとオペレーティングシステムに移植されました。

Linux版Doomのソースコードは、1997年12月23日に非商用利用の権利を認めるライセンスの下で一般に公開され、その後約1週間後の1997年12月29日にLinux版Doom IIがリリースされた。 ^{[4] [5]}ソースコードはその後、 1999年10月3日にGNU General Public License v2.0以降の下で再リリースされた。 ^{[6] [7]}それ以来作成された 数十の非公式Doomソースポートにより、 Doomは以前はサポートされていなかったオペレーティングシステムでも実行できるようになり、新しい機能でエンジンの機能が大幅に拡張されることもある。

エンジンは3D空間をレンダリングするが、その空間は2次元のフロアプランから投影される。視線は常に床と平行であり、壁は床に対して垂直でなければならず、多階層構造や傾斜エリア（角度の異なる床と天井）を作成することはできない。これらの制限にもかかわらず、エンジンはidの以前のWolfenstein 3Dエンジンからの技術的飛躍を表していた。Doomエンジンは後にid Softwareの長いゲームエンジンのリストに分類するために「id Tech 1」に改名された^[要出典]。^[8]

Doomエンジンはレンダリングをゲームの他の部分から分離しています。グラフィックエンジンは可能な限り高速に動作しますが、ゲームの世界はハードウェアに関係なく毎秒35フレームで実行されるため、複数のプレイヤーがさまざまなパフォーマンスのコンピューターを使用して互いに対戦することができます。[ ^9]

Doomが内部的にレベルを表現する 方法を示す簡単なセットアップ

上から見下ろすと、Doom のすべてのレベルは実際には 2 次元であり、Doomエンジンの主要な制限の 1 つである、部屋を重ねることができないことを示しています。ただし、この制限には明るい面もあります。右側の最初の画像のように、壁とプレイヤーの位置を表す「マップ モード」を簡単に表示できます。

基本単位は頂点で、単一の 2D ポイントを表します。頂点 (または内部では「頂点」と呼ばれます) は結合されて線を形成します。これは「ライン定義」と呼ばれます。各ライン定義には 1 つまたは 2 つの辺があり、これは「サイド定義」と呼ばれます。サイド定義はグループ化されてポリゴンを形成します。これらは「セクター」と呼ばれます。セクターはレベルの特定の領域を表します。

各セクターには、床の高さ、天井の高さ、光のレベル、床のテクスチャ、天井のテクスチャなど、いくつかのプロパティが含まれています。たとえば、特定のエリアに異なる光のレベルを設定するには、そのエリアに異なる光のレベルを持つ新しいセクターを作成する必要があります。したがって、片側ライン定義は固体の壁を表し、両側ライン定義はセクター間のブリッジ ラインを表します。

サイドデフは壁のテクスチャを保存するのに使われます。これらは床や天井のテクスチャとは完全に別個のものです。各サイドデフは 3 つのテクスチャを持つことができます。これらは中間テクスチャ、上部テクスチャ、下部テクスチャと呼ばれます。片面ラインデフでは、中間テクスチャだけが壁のテクスチャとして使われます。両面ラインデフでは、状況はより複雑です。下部テクスチャと上部テクスチャは、隣接するセクターの床と天井の高さが異なる場合の隙間を埋めるのに使われます。たとえば、下部テクスチャは階段に使われます。サイドデフには中間テクスチャも使えますが、ほとんどはそうではありません。これはテクスチャを宙に浮かせるために使われます。たとえば、透明なバーテクスチャがケージを形成しているのが見える場合、これは両面ラインデフの中間テクスチャの例です。

Doom はバイナリ空間分割(BSP)と呼ばれるシステムを使用しています。 ^[10] レベルの BSP データを事前に生成するためのツールが使用されます。このプロセスは、大規模なレベルではかなりの時間がかかります。このため、Doomでは壁を動かすことはできません。ドアやエレベーターは上下に動きますが、横に動くものはありません。

レベルはバイナリツリーに分割されます。ツリー内の各位置は、レベルの特定の領域を表す「ノード」です（ルートノードはレベル全体を表します）。ツリーの各ブランチには、ノードの領域を2つのサブノードに分割する分割線があります。同時に、分割線はライン定義を「セグメント」と呼ばれる線分に分割します。^[11]

木の葉には凸多角形があり、それ以上のレベル分割は必要ありません。これらの凸多角形はサブセクター（または「SSECTORS」）と呼ばれ、特定のセクターにバインドされています。各サブセクターには、それに関連付けられたセグメントのリストがあります。^[10]

BSP システムは、サブセクターをレンダリングに適した順序に並べ替えます。アルゴリズムは非常にシンプルです。

1. ルートノードから開始します。
2. このノードの子ノードを再帰的に描画します。カメラに最も近い子ノードが、スキャンライン アルゴリズムを使用して最初に描画されます。これは、ノードの分割線のどちら側にカメラがあるかを確認することでわかります。
3. サブセクターに到達したら、それを描きます。^[12]

ピクセルの列全体が埋められると（つまり、隙間がなくなると）、プロセスが完了します。この順序付けにより、見えないオブジェクトの描画に時間がかからないため、速度の低下を招くことなくマップを非常に大きくすることができます。

Doomの壁はすべて垂直に描かれているため、適切に上下を見ることができません。「y シアリング」を介して上下を見る形式を実行することは可能であり、多くの最近のDoomソース ポートや、 Hereticなどのエンジンを使用する後のゲームでもこれが行われています。基本的に、これは画面内で地平線を上下に移動することで機能し、実質的に、より高い表示可能領域に「ウィンドウ」を提供します。ウィンドウを上下に動かすことで、上下を見ているような錯覚を与えることができます。ただし、これにより、プレイヤーが上下に見るほど、ビューが歪んでしまいます。

Doomエンジンは、 BSP ツリーをトラバースしながら壁をレンダリングし、カメラからの距離順にサブセクターを描画して、最も近いセグメントが最初に描画されるようにします。セグメントが描画されると、それらはリンク リストに格納されます。これは、後でレンダリングされる他のセグメントをクリップして、オーバードローを減らすために使用されます。これは、後でスプライトのエッジをクリップするためにも使用されます。

エンジンが特定の x 座標で固体 (片側) の壁に到達すると、その領域にそれ以上線を描く必要はありません。クリッピングのために、エンジンは固体の壁に到達した画面領域の「マップ」を保存します。これにより、プレイヤーには見えないレベルの遠くの部分を完全にクリッピングできます。

Doomグラフィック フォーマットは、壁のテクスチャを垂直の列のセットとして保存します。これは、基本的に多数の垂直のテクスチャ列を描画して壁をレンダリングするレンダラーにとって便利です。

床と天井 (「フラット」) を描画するシステムは、壁に使用されているものほどエレガントではありません^{[誰によると? ] 。フラットは}塗りつぶしのようなアルゴリズムで描画されます。このため、悪い BSP ビルダーを使用すると、床や天井が画面の端まで流れ落ちる「穴」ができてしまうことがあります。これは一般に「スライム トレイル」と呼ばれる視覚的なエラーです。^[13]これは、プレイヤーがnoclip チートを使用してレベルの外に移動すると、床と天井がレベルから空のスペースに伸びているように見える理由でもあります。

床と天井は「visplanes」として描画されます。これらは、特定の高さ、光レベル、テクスチャの床または天井からのテクスチャの水平方向のランを表します (2 つの隣接するセクターの床がまったく同じである場合、これらは 1 つの visplane にマージできます)。visplane の各 x 位置には、描画される特定の垂直方向のテクスチャ ラインがあります。

各 x 位置に 1 本の垂直線を描くという制限があるため、visplane を複数の visplane に分割する必要がある場合があります。たとえば、2 つの同心円状の正方形がある床を表示することを考えてみましょう。内側の正方形は、周囲の床を垂直に分割します。内側の正方形が描画される水平範囲では、周囲の床に 2 つの visplane が必要です。

Doom には、visplane の数に静的な制限がありました。この制限を超えると、「visplane オーバーフロー」が発生し、ゲームは「visplane がこれ以上ありません!」または「visplane オーバーフロー (128 以上)」のいずれかのエラーで DOS に終了します。visplane 制限を呼び出す最も簡単な方法は、大きなチェッカーボードの床パターンです。これにより、多数の visplane が作成されます。

セグメントがレンダリングされると、セグメントの端から画面の垂直端に向かって伸びる visplane も追加されます。これらは、既存の visplane に達するまで伸びます。この仕組みのため、システムは、セグメントが全体のエンジンによって順番にレンダリングされるという事実に依存しています。最初に近くの visplane を描画して、遠くにある visplane で「カットオフ」できるようにする必要があります。停止しないと、前述のように、床または天井が画面の端に「にじみ出て」しまいます。最終的に、visplane は、特定のテクスチャを描画する画面の特定の領域の「マップ」を形成します。

visplanes は基本的に垂直の「ストリップ」から構築されますが、実際の低レベルのレンダリングはテクスチャの水平の「スパン」の形で実行されます。すべての visplanes が構築された後、それらはスパンに変換され、画面にレンダリングされます。これはトレードオフのように見えます。visplanes を垂直のストリップとして構築する方が簡単ですが、床と天井のテクスチャの表示方法の性質上、水平のストリップとして描画する方が簡単です。

レベル内の各セクターには、そのセクターに格納されているもののリンク リストがあります。各セクターが描画されると、スプライトは描画されるスプライトのリストに配置されます。視野内にない場合は無視されます。

スプライトのエッジは、以前に描画されたセグメントのリストをチェックすることでクリップされます。Doom のスプライトは、壁と同じ列ベースの形式で保存されます。これもレンダラーにとって便利です。壁を描画するために使用される同じ関数が、スプライトの描画にも使用されます。

サブセクターは順序が保証されていますが、その中のスプライトは順序が保証されていません。Doomは描画するスプライトのリスト (「vissprites」) を保存し、レンダリング前にリストを並べ替えます。遠くのスプライトは近くのスプライトより先に描画されます。これによりオーバードローが発生しますが、通常は無視できる程度です。

最後に、透明なバーなどで使用される 2 辺の線の中央のテクスチャの問題があります。これらは、他の壁ではなく、レンダリング プロセスの最後にスプライトと混合されて描画されます。

Doomエンジンは、古典的な一人称シューティング ゲームDoomに搭載されたことで最も有名になり、他のいくつかのゲームでも使用されました。通常、Doomエンジンを使用したゲームの「ビッグ 4」は、 Doom、Heretic、Hexen: Beyond Heretic、およびStrife: Quest for the Sigilであると考えられています。

1990年代には少数の開発者がDoomの完全版を配布するライセンスを取得し、1997年のソースコード公開以降、フリーウェア、ファンゲーム、商用タイトルなど、数多くのスタンドアロンタイトルがこのエンジンで制作された。^[14]

• ゲームエンジンの一覧
• 一人称視点シューティングエンジン
• idテック
• ビルド（ゲームエンジン）
• クエイクエンジン
• クエイク（シリーズ）
• 一人称視点シューティングエンジンの一覧

• GLノード仕様
• Doom と Doom2 を編集するためのユーティリティ
• Fabien Sanglard による Doom エンジン コードのレビュー

• Doom Wiki の Doom エンジン
• Doom Wiki の Doom レンダリング エンジン
• Doom エンジンの完全なゲームリスト
• Doomエンジンのソースコード