xyzzy

Colossal Cave Adventure の設計思想と革新性

序論：すべての冒険の始まり

1975年から1976年にかけて、William Crowther という一人のプログラマーが、コンピューターゲームの歴史を永遠に変える作品を生み出した。それが「Colossal Cave Adventure」（通称 ADVENT または Adventure）である。BBN Technologies のメインフレーム PDP-10 上で FORTRAN で書かれたこのゲームは、インタラクティブ・フィクションの祖であり、すべてのアドベンチャーゲームの原点である。

Crowther はケンタッキー州にある実在の Mammoth Cave（マンモスケーブ）を熟知した洞窟探検家であり、その体験と D&D（ダンジョンズ＆ドラゴンズ）のファンタジー要素を融合させて、このゲームを作り上げた。彼の離婚後、娘たちと過ごす時間を共有するために作られたこのゲームは、技術的にも設計思想的にも、驚くべき先見性を持っていた。

データ駆動設計の先駆け

Adventure の最も革新的な側面の一つは、そのデータ駆動型アーキテクチャである。Crowther は、ゲームのロジックとコンテンツを明確に分離するという設計判断を下した。これは1970年代においては極めて先進的な発想であった。

advent.dat：世界初のゲームデータファイル

ゲームのコンテンツは advent.dat という外部データファイルに格納された。このファイルは複数のセクションに分かれており、それぞれが異なる種類のゲームデータを保持していた：

部屋の説明文：66の実際の部屋と12のナビゲーションメッセージを含む78のロケーション記述
語彙テーブル：193の認識可能な単語（後に Don Woods により293語に拡張）
トラベルテーブル：部屋間の移動を定義する接続情報
オブジェクト状態：アイテムの初期位置と状態変化の定義
ヒントとメッセージ：ゲーム中のイベントに対応する各種テキスト

この設計により、ゲームエンジン（FORTRAN コード）を変更することなく、ゲームの世界を拡張・修正することが可能になった。これは現代のゲーム開発における JSON や XML によるコンテンツ管理の原型である。

自然言語インターフェースの誕生

Crowther は、彼の娘たちを含む非技術者ユーザーでも楽しめるゲームを目指した。その結果として生まれたのが、ゲーム史上初の自然言語パーサーである。

2語コマンドシステム

プレイヤーは「GET LAMP」「GO NORTH」「KILL SNAKE」といった簡単な2語コマンドでゲームを操作する。このシステムは以下の設計原則に基づいていた：

入力の寛容性：最初の5文字のみを認識し、タイプミスへの耐性を持たせた
同義語サポート：「ENTER」「DOOR」「GATE」を同じ動作として認識
コンテキスト認識：「GET LAMP」はランプが存在する場所でのみ有効

Crowther 自身が述べたように、彼は「英語のコマンドを入力して、それが実行されるという錯覚を与えるもの」を作りたかったのである。この「錯覚」という言葉は重要だ。完璧な自然言語理解ではなく、プレイヤーの期待に応えられる程度の賢さを目指したのである。

テキストによる世界構築

グラフィックスが存在しない時代、Crowther は文章のみで没入感のある世界を創り出した。その技法は今日のゲームライターにとっても学ぶべきものが多い。

二重記述システム

各部屋には2種類の説明文が用意されていた。初めて訪れた時の長い説明と、再訪時の短い説明である。これにより、新鮮な発見の興奮を維持しつつ、探索のテンポを保つことができた。

実在する洞窟の魔法

Crowther の説明文が特別な力を持つ理由は、それが実体験に基づいていたからである。「狭い小石だらけの這い穴」「霧の間」「オレンジ色の石の凍った川」といった描写は、実際の Mammoth Cave の地形と驚くほど一致する。Dennis Jerz 教授の研究により、ゲーム内の多くの場所が実在の洞窟とほぼ正確に対応していることが確認されている。

パズルデザインの哲学

Adventure のパズルは、単なる障害物ではなく、世界との対話を促す仕掛けとして設計された。

XYZZY：魔法の言葉

ゲーム史上最も有名なイースターエッグの一つである「XYZZY」は、2つの場所間をテレポートさせる魔法の言葉である。Crowther は「魔法の言葉は奇妙に見えつつも発音できるものであるべき」と考え、この言葉を選んだ。この言葉は後にコンピューター文化全体に広がり、無数のプログラムに隠しコマンドとして組み込まれることになる。

迷路：すべて同じに見える通路

「YOU ARE IN A MAZE OF TWISTY LITTLE PASSAGES, ALL ALIKE.」という有名な一文は、10の部屋すべてが同じ説明を持つ迷路を表現している。プレイヤーは自分で持ち物を各部屋に落として目印にし、地図を作る必要がある。これはプレイヤーの能動的な参加を要求する革新的なパズルデザインであった。

後に Don Woods が追加した「ALL DIFFERENT」の迷路では、微妙な言葉の違いを見つけ出す必要があり、異なる認知スキルを試すものとなった。

技術的優美さ

1970年代のコンピューターは、現代のスマートフォンよりもはるかに制限されたリソースしか持っていなかった。その中で Adventure は驚くべき効率性を実現した。

メモリ効率の追求

Crowther のオリジナル版は約60Kワード（約300KB）のコアメモリを必要とした。PDP-10 システムでは、これは利用可能なメモリの大きな部分を占めていた。後の Woods 版では42Kワードに最適化された。

5文字に入力を切り詰めるというパーサーの設計は、単なる制限ではなく、36ビットワードに5つの7ビット ASCII 文字を詰め込むという PDP-10 のアーキテクチャに最適化されたものだった。制約を創造性に変換する好例である。

不滅の遺産

Adventure の影響は計り知れない。以下のゲームジャンルとタイトルが、直接または間接的にその影響下で生まれた：

Zork (1977)：Adventure に触発された MIT の学生たちが開発し、後に Infocom を創設
Adventureland (1978)：Scott Adams による最初の商用アドベンチャーゲーム
Mystery House (1980)：最初のグラフィックアドベンチャーゲーム
Rogue (1980)：ローグライクジャンルの祖
MUD：マルチユーザーダンジョンの概念は、Adventure のオンライン版として始まった

結論：設計の普遍性

Colossal Cave Adventure の設計が素晴らしい理由は、単に「最初」だったからではない。Crowther が下したすべての設計判断が、ユーザー体験を中心に据えていたからである。

技術者ではない娘たちでも楽しめるように自然言語インターフェースを採用した。実体験に基づいた描写で没入感を創出した。コードとコンテンツを分離して拡張性を確保した。制約を創造性に変えて効率的なシステムを構築した。

これらの原則は、50年後の今日でも変わらず有効である。最高のゲームデザインとは、技術の限界の中でいかに人間の想像力を解き放つか、という挑戦への答えなのだ。

YOU ARE STANDING AT THE END OF A ROAD BEFORE A SMALL BRICK BUILDING.

この一文から始まるすべての冒険へ、敬意を込めて。

Colossal Cave Adventure の設計の素晴らしさ

PDP-10 FORTRAN版 Colossal Cave Adventure の advent.for / advent.dat / advent.readme を読むと、このゲームの「設計の凄さ」は 物語（テキスト）を“コードから分離したデータベース”として扱い、限られた計算資源の中で“世界シミュレーション”を成立させている 点に凝縮されていることが分かります。以下、その設計美をソースの構造に沿ってエッセイとしてまとめます。

1. 物語を「データベース」として実装した先見性

この版の Adventure は、単にテキストをハードコードしたプログラムではありません。最初に驚くのは、ゲーム世界の文章・地形・語彙・ヒント・運用メッセージまでを外部データファイルの“セクション”として定義し、起動時に読み込んで内部テーブルへ変換していることです。

データファイルはセクション番号で始まり -1 で終わる、という明確なフォーマットを持ちます。たとえば…

セクション 1: 場所ごとの「ロング説明」
セクション 2: 繰り返し訪問時の「ショート説明」
セクション 3: 移動（トラベル）表 – 「場所Xでこの動詞を使ったらYへ」
そのほか、ヒント、メッセージ、語彙表などがセクションごとに定義

こうして、物語は“編集可能なデータ”へ落とし込まれています。これは現代の言葉で言えば データ駆動設計（data-driven design） そのものです。ゲームエンジン（ルール・状態更新・入出力）と世界コンテンツ（文章・地名・語彙・イベント文）を切り離すことで、物語側は修正・拡張がしやすく、エンジン側は汎用化されます。これを 1970 年代にやっているのが凄いところです。

2. “テキストの保存”が、すでにエンジン設計になっている

さらに面白いのが、テキストの保持方法です。 advent.for では、読み込んだ文章は巨大配列 LINES に格納され、各行の前に「次の行へのポインタ」を置く方式がコメントで説明されています。さらに、そのポインタが負なら「そのメッセージの先頭行」を意味するなど、 メッセージを“リンク構造”で保持しています。

そして STEXT / LTEXT / PTEXT / RTEXT / CTEXT / MTEXT といった配列は、その LINES の“ポインタ位置”を指す索引テーブルとして働きます。これは単なる省メモリ技巧ではなく、 「同じオブジェクトでも状態（PROP）によって別の文章を出す」 といったゲーム表現を、きちんとデータモデルに落としている点が本質的です。

文章はコードに焼き付いた定数ではなく、 状態と結び付いたデータ として設計されている。ここからすでに「インタラクティブフィクションのエンジン」という視点が見えます。

3. 移動（世界の地形）を“グラフ”として圧縮し、条件分岐まで符号化する

Adventure の“洞窟”は、結局のところ 場所（ノード）と移動（エッジ） のネットワークです。ここでも設計が冴えています。

データベースのセクション 3（トラベル表）では、「場所 X・行き先 Y・動詞（移動語）」のリストで移動を定義します。実装側では、各場所の移動候補を配列 TRAVEL の連続領域として詰め込み、各要素を NEWLOC * 1000 + KEYWORD の形で格納し、最後の要素だけ負数にして“終端”を表します。先頭インデックスは KEY(N) に保持されます。

これは今のゲームでも通用する「テーブル駆動の遷移表」そのものですが、終端を符号で表す・領域を連続化するなど、当時の制約（メモリ、速度）を前提にした美しい圧縮です。そして行き先番号に“条件（フラグ）”をエンコードしておき、遷移時にその条件を解釈することで 条件付き遷移 を実現しています。

移動＝単なる場所移動ではなく、パズルの骨格となる ロジック付きのグラフ遷移 になっている点が、この設計の肝です。

4. 二語パーサ＋語彙表：自然言語“風”を、テーブル参照へ落とす

プレイヤー入力は自然言語に見えますが、内部構造は非常に明快です。入力ルーチン GETIN はコマンドを読み取り、 第 1 語と第 2 語を切り出して返す 仕様になっています。 YES/NO 確認も同じ入力系の上に構築され、 YES なら Y、NO なら N も受け付け、それ以外なら「質問に答えて」と促して再入力させます。 UI としても堅牢です。

語彙はデータベース由来の配列（KTAB, ATAB など）に保持され、 VOCAB() が検索して「定義番号」を返します。ここで重要なのは、この“定義番号”が単なる ID ではなく、 N / 1000 によって語の種類（動詞/名詞など）を埋め込む設計 になっている点です。そのため、非同義語（non-synonymous）に 1000 個という上限が設定されます。

これは「自然言語っぽさ」を、最終的に 型付きトークン へ落とす設計です。現代で言うところの字句解析＋シンボルテーブルのミニマム実装が、すでにここにあります。

さらに語彙テーブルは XOR 'PHROG' で簡単にマスクされ、コアダンプなどからゲームの秘密が読み取られにくくなっています。「ゲームを遊ばせるためのエンジニアリング」が、細かいところまで徹底されています。

5. 世界状態の表現：オブジェクト連結リスト＋プロパティ＋場所条件ビット

Adventure の世界は、「場所」「物体」「状態」で成り立っています。ソースコードはそれを極めて直截に表現します。

物体は PLACE / FIXED / PROP などで位置と状態を持つ（所持中は PLACE = -1 で表現）
場所ごとに「その場にある物体の連鎖」を ATLOC と LINK の“鎖”で管理し、場所の描写後に順に物体描写を出す

特に美しいのが COND(LOC) のビット設計です。光（0 ビット）、液体属性（1, 2 ビット）、盗賊（pirate）の制約（3 ビット）、さらにヒント用の状況ビット（4〜9 ビット）まで、場所条件がビット単位で持たれています。

そこから見えてくるのは、このゲームが“物語”ではなく、 状態遷移システム（simulation） として書かれていることです。 advent.dat 側にも、ドラゴンやトロル等の“状態別メッセージ”が 0/100/200… のように段階を持って並び、コード側は PROP をキーに出し分けます。

つまり文章は固定台本ではなく、 状態に結び付いた反応 として設計されている。これがインタラクティブフィクションを“ゲーム”にしている核です。

6. ペース設計：ロング/ショート描写、ヒント、そして「プレイヤーの停滞」を検知する

設計の“優しさ”も、コードに埋め込まれています。

まず、同じ場所に何度も来たときの冗長さを避けるため、ショート描写（STEXT）とロング描写（LTEXT）を切り替える仕組みがあります。配列 ABB(LOC) を増やして「省略（abbrev）」を管理し、一度見た説明を再びダラダラ表示しないようにする。これにより探索のテンポが上がりつつ、必要であれば詳細描写も見られるというバランスがとれています。

次にヒント。ヒントは「その状況の場所に何ターン居続けたか」を条件にトリガーされ、質問を投げ、了承すればポイントを差し引きつつヒントを出します。

ここが本当に上手いのは、ヒントが“救済”であると同時に、 スコア（達成）との交換 になっていることです。詰まってやめるよりは、減点してでも前へ進む。その選択をプレイヤーに委ねる倫理的設計があります。

7. 緊張の演出：ランタン、閉鎖、そして時間で物語を駆動する

Adventure は「洞窟探検」というテーマを、資源制約によって体験に変換します。

代表例がランプです。ランプが弱ってくると警告し、条件が揃えば電池交換で延命し、最終的には消える。外に出てランプが尽きた場合は“強制終了”さえあります。暗闇は即死リスク（落とし穴など）にもつながりうるため、プレイヤーは「行けるうちに行く」「戻れるうちに戻る」という判断を常に迫られます。

さらに「洞窟の閉鎖」。宝物発見後に一定ターンで閉鎖フェーズへ移行する設計によって、探索は終盤に向かう“物語の締め切り”を持ちます。そしてスコアは 350 点満点として設計され、宝物・生存・閉鎖到達など複数の達成を束ねて評価します。

プレイヤー体験が「迷って終わり」ではなく、 「達成して終わる」 ように締められている──それがこの設計です。

8. 動的世界：ドワーフと海賊が「物語の揺らぎ」を作る

静的なパズルに留まらないのは、敵対存在が“イベント”としてではなく、簡易的な AI として存在するからです。

ドワーフは初期位置 DLOC を持ち、プレイヤーが Hall of Mists（場所 15）に達するとシステムが活性化し、段階（DFLAG）に応じて挙動が変わります。これにより、プレイヤーには「世界が反応して動いている」という感覚が生まれます。

しかも行動には確率が絡むため、再プレイでも同じ展開になりにくい。 “語り”ではなく、“システム”が緊張を生む。ここにゲームデザインの強さがあります。

9. そして異様に現代的な「運用設計」── cave hours と wizard mode

この版の最も興味深い特徴の一つが、ゲーム内に運用ポリシー（勤務時間に遊ばせない）が組み込まれている点です。

advent.readme には、この版が「cave hours（洞窟の営業時間）」の概念を持ち、管理者が時間帯を設定できること、デモゲームだけを許可するモードがあることなどが書かれています。実装側にも「prime time の判定」「再開の待ち時間（latency）」「ウィザードは短縮可能」などが組み込まれています。

これは“ゲーム”がタイムシェアリングという社会環境の中で動いていたことの証拠であり、同時に「遊び」を現実の制約と共存させる設計思想でもあります。ゲームデザインが、システム運用まで含んでいるのです。

結び：Adventure の設計が今も輝く理由

このソースから見える Adventure の凄みは、懐古趣味では片付けられません。

データ駆動で世界を定義し（セクション分割）
遷移表（TRAVEL）と語彙表（VOCAB）で入力と移動を形式化し
ビットと配列で状態を持ち、文章を状態に結び付け
ヒント・スコア・資源制約でプレイヤー体験を破綻させず
運用ポリシー（cave hours）までシステム化している

こうして見ると、Adventure は「テキストの名作」である以前に、 ゲームエンジン＋ワールド DB＋対話 UI＋運用機構 をひとつにまとめた、非常に完成度の高い“システム設計”です。

文章が美しいのはもちろんですが、設計が美しいからこそ、その文章がゲームとして機能し、何度でも“冒険”になり続ける── それが、このソースを読んで改めて分かる素晴らしさです。

```

ジジイのひとりごと

2025年12月11日木曜日