ブラウザの中に、
地獄をもう一度つくる。

第1章

このデモとは

「あの1993年の DOOM を、プラグインもエミュレータも使わず、素のブラウザとコードだけで動かせるの？」に、動く実装で答えるサンプルです。

このデモは、Babylon.js ファミリーの WebGPU 専用ランタイム Babylon Lite の公式リポジトリに含まれる、DOOM の再現です。ゲームの中身が入った WAD ファイル（バイナリのデータ塊）をネット越しに読み込み、その中の地図・テクスチャ・スプライト・音を自前のコードで解析して、3D の迷宮として描き、モンスターを動かし、銃を撃てるところまで作り込まれています。

プログラムとしての見どころは、次の3点です。

第2章

あそびかた

コードを読む前に、まず走り回るのがいちばんの近道です。操作はオリジナルの DOOM に沿っています。

第3章

用語ミニ辞典

この先の章で出てくることばを先にまとめて紹介します。分からなくなったらここに戻ってきてください。

第4章

全体の地図

エントリの doom.ts（わずか49行）は、エンジンを立ち上げて WAD を取得し、あとは doom-level.ts にレベル作りを丸ごと任せます。

flowchart TD
    ENTRY["doom.ts
エンジン・WAD取得(約28.8MB)"]
    LEVEL["doom-level.ts
レベルの組み立て役"]
    subgraph DATA["WADを解く"]
        WAD["wad/*
バイナリ解析"]
    end
    subgraph VIEW["描く"]
        GEO["geometry/*
壁と床の3D化"]
        REND["render/*
素材・空・スプライト・武器"]
    end
    subgraph SIM["動かす"]
        MOBJ["mobj/*
アクター(35Hz)"]
        PLAY["player + combat + physics"]
        SPEC["specials/*
扉・リフト"]
    end
    HUDSND["hud + sound"]
    ENTRY --> LEVEL
    LEVEL --> DATA
    LEVEL --> VIEW
    LEVEL --> SIM
    LEVEL --> HUDSND
    WAD --> GEO
    WAD --> REND
  

矢印は「上が下を利用する」向きです。doom-level.ts（309行）が司令塔で、WAD を解いて→静的な壁と床を作り→動く仕掛け・敵・プレイヤーを用意し→毎フレームの更新ループを回します。「読む」「描く」「動かす」がフォルダごとにきれいに分かれているのが、このデモを読むときの最初の目印です。

第5章

WADを読み解く

担当：wad/ フォルダ。生のバイト列を、意味のあるデータへ翻訳する“考古学”の層です。

まず wad-file.ts が入れ物を開けます。WAD は12バイトのヘッダ（識別子 IWAD/PWAD＋ランプ数＋目次の位置）に続いて、16バイトずつの目次（位置・サイズ・8文字の名前）が並ぶだけの素朴な構造。ここから名前でランプを引ける辞書を作ります。

flowchart LR
    RAW["生バイト列"] --> WF["wad-file
ヘッダ+目次"]
    WF --> MAP["map
頂点/線/区画"]
    WF --> PAL["palette
256色+34段"]
    WF --> GFX["graphics
パッチ/フラット/合成"]
    MAP --> BQ["bsp-query
点→区画"]
  

map.ts は地図データを固定長レコードとして読みます。E1M1 という目印ランプの直後に、決まった順で並ぶ8種類のデータを、それぞれ正確なバイト数で切り出します。

palette.ts は色の要。PLAYPAL（14種×256色×3バイト＝10,752バイト）と COLORMAP（34段×256バイト＝8,704バイト）を読み、両者を焼き合わせて 256×34 のルックアップ表テクスチャを作ります。これが次章の“本物の光”の材料です。graphics.ts は、列単位で透明を表現する DOOM 独特のパッチ形式や、64×64 のフラット、複数パッチを合成する TEXTURE1/2 を解読します。

最後に bsp-query.ts（43行）。「座標 (x, y) はどのセクターにいて、そこの床/天井の高さは？」を、BSP の木を根からたどって即答します。カメラ・モンスター・仕掛けが共通で使う、地図の“住所案内”です。

第6章

2Dの地図を3Dの壁に

担当：geometry/。DOOM の地図は本来“平面図”。それを立体の壁・床・天井に立ち上げます。

主役は build-level-geometry.ts（360行）。すべての壁の線（リニデフ）をたどり、その両脇のサイドデフから壁の四角形を起こします。座標は ワールド＝(doomX, 高さ, doomY) で、DOOM の地図単位をそのまま1:1でワールド単位に使います（縮尺なし）。床と天井（フラット）は 64単位ごとにタイル貼り。

床・天井の形は bsp.ts が復元します。地図全体を囲む大きな四角形を、BSP の分割線で次々に切り落としていくと、各区画のぴったりの多角形が残る——という賢い手法（Sutherland-Hodgman クリッピング）です。

そして扉やリフトのように動く床・天井は、静的な壁とは別に dynamic-geometry.ts が担当。仕掛けが「動いた」と知らせるたび、動く部分の面だけを作り直します（マテリアルは使い回し、GPUのメッシュだけ再生成）。

第7章

本物の光を再現する

担当：doom-material.ts。このデモが最もこだわった、「DOOM にしか見えない画面」の正体です。

ふつうの 3D は色を RGB で持ち、距離に応じて滑らかに暗くします。でも DOOM は違いました。テクスチャは「色番号」だけ（R チャンネルにパレット番号、A に不透明度）を持ち、明るさは COLORMAP という34段の変換表で「番号 → 別の番号」に置き換えて表現します。だから DOOM の陰影は、滑らかではなくカクッと帯状に落ちるのです。

// パレット番号を、明るさの段(row)ごとに引き直す
// 明るいセクターほど浅い段。距離で段が深くなる。
baseRow = clamp(31 - floor(sectorLight / 8), 0, 31);
lightRow = clamp(baseRow + depth / 224.0, 0, 31);
// 224 = 1段ぶん暗くなるまでの距離(DOOM単位)

この DIST_PER_BAND = 224 が、あの「遠くが段階的に闇に沈む」距離感の数値です。シェーダは 256×34 のルックアップ表を、横＝色番号・縦＝明るさの段として引きます。色番号そのものは決して混ぜず（混ぜると存在しない色が生まれてしまう）、表を引いた後の最終 RGB だけを補間します。

第8章

空のからくり

担当：sky.ts（69行）。DOOM の空は「無限に遠い背景」。その錯覚を、たった1個の球で作ります。

仕掛けはこうです。カメラを中心に置いた直径 2000 の球を用意し、そのピクセルを強制的に最遠面へ（深度を反転Zの奥へ）押し込みます。すると空は必ず「すべての壁より後ろ」に描かれ、天井を張らなかった穴からだけ覗く。描画順を気にせず、空が確実に背景を埋めます。テクスチャは視線の方向から貼り、DOOM 流に360°で4回くり返します。空は距離や明るさで暗くならず、常に一番明るい段（row 0）で描かれます。

第9章

モンスターの設計図

担当：mobj/ フォルダ。DOOM の敵・弾・アイテムを支える、有名なデータ駆動アクターシステムの移植です。

あらゆる“動くもの”は mobj（マップオブジェクト）という共通の器。位置・体力・フラグ・状態を持ちます。その設計は3段構え——インフォ（型）→ ステート（アニメと行動のコマ）→ アクション（AIの関数）。この3つの表を think.ts が 35Hz で1 tic ずつ進めます。

flowchart LR
    INFO["info
型(体力/速さ/半径)"] --> STATE["states
コマ{絵,フレーム,tics,行動,次}"]
    STATE --> ACT["actions
AI関数(A_Look等)"]
    ACT --> THINK["think
1ticずつ進める"]
    THINK --> WORLD["world
全mobjの管理"]
  

info.ts の目録には、モンスター・アイテム・武器・弾・置物までがずらり。E1M1 に登場する主なモンスターはこちらです（数値はソース実測）。

第10章

敵を動かす頭脳

担当：actions.ts。ステートの各コマに紐づく“行動”が、敵の思考そのものです。

DOOM の AI は驚くほどシンプルな関数の集まりです。ステートが進むたびに、そのコマに書かれた行動名が呼ばれます。

攻撃するかどうかの判断（checkMissileRange）も DOOM 譲り。距離が近いほど発砲しやすく、遠いと撃ち控える確率計算になっています。近接の間合いは MELEE_RANGE = 64、遠隔の射程は MISSILE_RANGE = 2048（＝32×64）。移動方向は「標的に近づく向き」を対角優先で選び、壁や仲間にぶつかれば別の向きを試します。

第11章

スプライトを板に描く

担当：sprites.ts と sprite-render.ts。DOOM の敵は3Dモデルではなく、1枚絵の板です。

モンスターは常にカメラへ正面を向くビルボード（板）に描かれます。でも、ただ正面を向くだけでは“書き割り”になってしまう。そこで DOOM は8方向ぶんの絵を用意し、「プレイヤーがどの角度から敵を見ているか」に応じて絵を差し替えます。横を向いた敵は横向きの絵、背を向けた敵は後ろ姿の絵、という具合です。

その角度計算が BAM（角度を32bit整数で表す方法）の見せ場。「視線→敵の方向」と「敵の向き」の差をビットシフトするだけで、8方向のどれかへ即座に振り分けられます。絵はスプライト名＋フレーム文字＋方向番号（例 TROOA1）で管理され、左右対称の向きは1枚を反転して使い回します。全スプライトは1枚の大きなアトラス（1024幅）に詰め込まれ、壁と同じ COLORMAP の陰影で距離に応じて暗くなります。

第12章

プレイヤーと武器

担当：player.ts と weapon-view.ts。体力・防具・弾薬・所持武器、そして手元の銃の描画です。

8種の武器はそれぞれ、弾の種類・連射間隔（tic）・発砲音を持ちます。開始時は拳とピストル、体力100、弾薬は弾丸50発から。

手元の武器は weapon-view.ts が仮想 320×200 の画面に 2D で重ねます。移動中は上下左右に揺れ（横は cos、縦は sin の絶対値で“8の字”）、発砲した瞬間は発射コマ＋別レイヤーのマズルフラッシュを 0.12 秒だけ重ねる。すべて COLORMAP の一番明るい段で、常にくっきり描かれます。

第13章

撃つ・当たる

担当：combat/attack.ts と physics/collision.ts。弾の当たり判定と、壁ずりの移動です。

ほとんどの武器はヒットスキャン——撃った瞬間に光線を飛ばし、最初にぶつかる壁までの距離を測り、その手前にいる敵を探して当てます。命中すれば血（BLOOD）、外れれば煙（PUFF）を出し、damageMobj が体力を削る。体力が尽きればモンスターは死亡ステートへ、被弾すれば painChance の確率でひるみステートへ遷移します。インプの火球だけは本物の飛翔体として飛び、着弾で爆発します。

移動と当たり判定は collision.ts。プレイヤーは半径16の円（高さ56、視点高41、登れる段差24）としてモデル化され、壁の線に沿って滑ります（法線方向に押し戻して接線方向の動きは残す＝ウォールスライド）。両側が通れる壁は「すき間が身長より狭い／段差が24を超える」ときだけ塞がる。扉やリフトで高さが変わると、この判定もその場の高さで更新されるので、閉じる扉に挟まれます。

第14章

扉とリフト

担当：specials.ts（410行・最大のファイル）と special-types.ts。壁や床に仕込まれた“仕掛け”です。

DOOM の扉・スイッチ・リフトは、リニデフに割り当てられた番号で表されます。special-types.ts はその番号表（E1M1 が使う範囲）。「どう起動するか（押す/歩いて横切る/スイッチ）」「くり返せるか」「何をするか」を定義します。

specials.ts はこれを実際の“動く床・天井”に変えます。Space で使うと、正面へ 64 の光線を飛ばして手前のスイッチ/ドアを起動。歩いて線を横切れば、横断型の仕掛けが発火。ドアは「隣接する一番低い天井の4つ下」まで開き、150 tic 待って閉じます。

第15章

ステータスバー

担当：hud.ts（342行）。画面下のあの茶色いバーを、WAD の本物のグラフィックから組み立てます。

体力・防具・弾薬・武器スロット・鍵——すべて WAD の STBAR 系グラフィックを1枚のアトラスに焼き、仮想 320×200 の座標（バーの上端 y=168）に、当時のレイアウト定数どおりに並べます。数字も本物のフォント絵です。

第16章

音

担当：sound.ts（86行）。効果音は合成ではなく、WAD の中の本物のサウンドを鳴らします。

DOOM の効果音は DS で始まるランプ（例：DSPISTOL）に、DMX 形式の 8bit PCM として入っています。sound.ts はこれを解読し（サンプルレートは通常 11025Hz、前後16サンプルの余白は切り落とす）、Web Audio の AudioBuffer に変換して再生。同じ音の連発は 1 tic（1/35秒）に1回まで、音量は 0.6 に抑えます。ブラウザの制約で、音は最初のキー操作の後から鳴り始めます。

第17章

設計テーマ

29ファイルに散らばって見えて、じつは一貫した4つの考え方が通っています。

第18章

ファイル一覧（全29ファイル）

コードリーディングのおともに。行数は master ブランチのソース実測値です。specials.ts が最大で、合計およそ5,010行。

行数は master ブランチ（2026年時点）のソース実測値です。合計およそ5,010行（29ファイル）。