ゲームの進化とは「カプセル化」の歴史だった——Wizardryの壁から生成AIまで

What Game Evolution Really Was — A History of Encapsulation, from Wizardry's Walls to Generative AI

著：霧星礼知（min.k）｜mncc.info / Author: Reichi Kirihoshi (mncc.info)

ゲームの進化は、たいてい「ゲームでできるようになったこと」で語られる。
2Dから3Dへ、ドットからポリゴンへ、オフラインからオンラインへ。
CPUとGPUの性能が上がり、敵のAIは賢くなり、世界はシームレスにつながった。

ただ、ソフトウェアの作り方から見ると、もう一本別の歴史線が引ける。
ゲーム世界を構成する「要素」が細かく分かれ、それぞれが独立したシステムとして箱に入れられてきた、という歴史である。

この現象を受けて、ゲームは確実に複雑になった。
けれど、開発者がその複雑さをすべて直接扱ってきたわけではない。その時代時代で技術が成熟するたびに、昨日まで考えなければならなかった問題が「解決済みの部品」に変わってきた。

この記事では、初期のRPGからゲームエンジン、生成AIまでを、この見方でたどってみる。

なお「カプセル化」は、オブジェクト指向プログラミングの厳密な用語としてではなく、複雑な内部実装を単純な窓口の背後に隠すこと、という広い意味で使う。

1. 「Wizardry」の迷宮は何でできていたか

線だけの3D

1981年9月、Sir-TechはApple II向けに『Wizardry: Proving Grounds of the Mad Overlord』（邦題『狂王の試練場』）を発売した。作者はコーネル大学の学生だったアンドリュー・グリーンバーグとロバート・ウッドヘッドで、二人は大学のPLATOシステムで遊べたダンジョンゲームに影響を受けていた^[1]。

Wizardryでは、画面の大半は文字で、迷宮の一人称視点は全体の一割ほどしかない。そこに線で描かれた壁と通路と扉が表示される^[2]。迷宮は一階層20×20マスで、地下10階まで続く。オートマップはなく、プレイヤーは同梱の方眼紙に自分で地図を描きながら進んだのである^[2:1]。

この画面表現を「性能が低かったから」とだけ説明すると、取りこぼすものがある。
コンピュータの側から見れば、迷宮を成立させるのに必要な情報はそれほど多くない。

• プレイヤーがいるマスの座標
• 向いている方角
• 各マスの四方に壁や扉があるかどうか

これだけあれば、前に進めるか、右に何があるか、どこで行き止まりになるかが決まる。Wizardryの線画は、コンピュータの保持している内部構造を人間が読める最低限の形で描いたものと見ることができる。

一枚絵の出る戦闘

敵の表現についても事情は似ている。
Wizardryでは敵と遭遇すると迷宮の表示が消え、モンスターの絵が一枚表示される^[2:2]。その絵は動かない。戦闘はコマンドの選択と、結果を報告する文字で進む。

ゲームの計算にとって、オークは名前と体力と防御力と攻撃の数値である。
顔がどうなっているかは計算に関係しない。絵は、数値の束に付けられた絵札のようなものだった。

2. 「画面」から世界モデルが透けて見える

Rogueの「O」

同じ頃、UNIX上ではもっと切り詰めた表現のゲームが遊ばれていた。1980年に作られた『Rogue』は、画面を文字だけで構成した。プレイヤーは「@」、壁は記号、モンスターはアルファベット一文字で表される^[3]。オークなら「O」である^[4]。

プレイヤーは「O」という文字を見て、そこにオークがいると理解し、姿は想像で補う。
ゲーム内部のデータ構造を、人間の頭がレンダリングしていたのである。

表現距離

初期のゲームでは、コンピュータが持っている世界の情報と、プレイヤーに見せる情報がかなり近い。座標、壁、向き、敵の種類、数値。内部で扱っているものが、ほとんど加工されずに画面に出ている。

ここでは、この内部モデルと画面表現のあいだの隔たりを、仮に「表現距離」と呼んでみたい。
初期のゲームは表現距離が短い。現代のゲームは長い。プレイヤーが見ている一体のキャラクターの背後には、今や何層もの変換があるのである。

3. Ultimaの見下ろし視点

一方、1981年6月に発売された『Ultima』（のちの『Ultima I』）は、地上を見下ろし視点で描いた。町や城、森、川がタイル状の絵で並び、プレイヤーは地図そのものの上を歩く。ダンジョンに入ると、こちらも一人称の線画に切り替わる^[5]。

Wizardryとの比較として、同じ時期同じApple IIの上で、内部の世界モデルをどこまで人間向けの絵に変換するかについて、違う判断があったことは注目に値する。
Wizardryでは、周囲数マスしか見えない一人称の画面から、プレイヤーが頭の中で地図を組み立てる。Ultimaの地上では、世界の位置関係を最初から画面が引き受ける。
迷宮を解読する感覚と世界を旅する感覚の違いは、表現距離をどこでどれだけ取るかの違いでもあるのだ。

4. オークは少しずつ大きくなった

その後のゲーム史で、一体のオークに必要なものは増え続けた。

名前と数値だけだったものに、絵が付く。絵が動くようになり、攻撃が当たる範囲を持つ。声を出し、装備を持ち、周囲の物音や視界を知覚する。状況に応じて行動を選び、地形に合わせて道を探し、倒れれば物理的に床を転がる。表情や視線を持ち、他のNPCの行動に反応する。

現代のアクションRPGで一体の敵を成立させるには、描画、アニメーション、衝突判定、物理、音響、AI、経路探索といったシステムが同時に協調して動いている。それでもプレイヤーから見れば、そこには「オークが一体いる」だけである。

表現距離はここまで伸びた。そして、作る側がこの距離をすべて手で埋めているわけではない。

5. 複雑化とカプセル化は同時に進んだ

箱に分けられた複雑さ

ゲームが複雑になる過程で、その複雑さは独立したシステムへ切り分けられていった。レンダリング、アニメーション、物理演算、衝突判定、経路探索、サウンド、入力、UI、セーブ、ネットワーク。それぞれの内部には巨大な実装がある。

上の層から見ると、それぞれの窓口は単純である。このキャラクターを表示する。この地点まで移動させる。この音を鳴らす。

SetDestination一行の向こう側

Unityの経路探索を例にとる。Unityのマニュアルは、ナビゲーション用のコンポーネントが経路探索と移動制御の両方を受け持つため、スクリプト側は目的地を渡すだけで済むと説明している。キャラクターを動かすには SetDestination を一度呼べばよい^[6]。

歩ける場所の割り出し、障害物を避ける経路の計算、移動の制御。その処理は一行の呼び出しの向こうにある。

同じページには、ナビゲーションシステムがゲームロジックのすべてを扱えるわけではなく、どこを目的地にするかは別に決める必要がある、という注記もある^[6:1]。道の探し方はエンジンが引き受けた。どこへ向かわせるかは、今も作り手が決めているのである。

「カプセル化」は最初からあった

こういったカプセル化は現代になって始まったものでもない。WizardryはPascalで書かれていた^[1:1]。Rogueの作者の一人ケン・アーノルドは、端末の画面を制御するcursesライブラリの作者でもある^[3:1]。

初期のゲームも、すでに何層かの抽象化の上に立っていたのである。
違うのは、年月が経つにつれて、重なっている層の数が増えたことと、どこまでが「ゲームを作る人が考えなくてよいこと」になっていたか、である。

6. ゲームエンジンという箱の集合

UnityやUnreal Engineのような現代のゲームエンジンは、こうした箱をまとめて提供する。3D空間、カメラ、光源、物理、アニメーション、ナビゲーション、パーティクル、サウンド。かつては「3D空間を画面に描く」ことそのものが大きな技術課題だったが、今はエンジンを起動した時点で3D空間がそこにある。

技術自体が簡単になったわけではない。エンジンの内部は、初期のゲームと比べものにならないほど複雑である。
変わったのは、その複雑さについてツールを利用する開発者が直接考えなくてよくなったことだ。

考える対象はこう移っていく。

• 画面に迷宮をどう表示するか
• 3D空間の中に、どんな迷宮を作るか
• その迷宮を歩くことで、プレイヤーにどんな体験をさせるか

技術は人間の思考を消したのではなく、考える場所を一段ずつ上へ押し上げてきた。

7. 「考えなくてよくなった階層」でゲーム史を読む

一般的なゲーム史は、できるようになったことを並べる。2D、3D、高解像度、オンライン、オープンワールド。

同じ歴史を、人間が直接考えなくてよくなった問題の順に並べることもできる。

難しい問題に解き方が発明され、繰り返し使われ、標準化され、ライブラリやエンジンに収まる。そうなると、次の世代は内部を知らなくてもそれを使える。昨日までの高度な技術が、次の世代の前提条件になる。

以前の記事「構造も、いつか答えに成り下がる」で、定型化された構造はやがて誰でも使える答えになる、と書いた。

今回の話の中では、「成り下がる」ことは悪い意味ではない。「3D空間をどう構築するか」は、かつて設計上の大問題だった。今は「3D空間がある」ところから設計を始められる。構造が答えになったから、その上の構造を考える余地が生まれた。

8. 生成AIは何を箱に入れ始めているか

ゲームエンジンが描画や物理や経路探索を箱に入れたとすれば、生成AIはその上の層に手を伸ばしている。

Unityは2025年のUnity 6.2で、エディタに統合したAI機能「Unity AI」を導入した^[7]。テキストや参考画像からスプライト、テクスチャ、マテリアル、サウンド、アニメーションを生成する「Generators」と、コードを書き、問題を調べ、エディタ上の作業を自動化する「Assistant」が含まれる^[8]。コード生成の支援は、エンジンの外でも汎用のAIツールとして広く使われている。

これまでのカプセル化は、主に「どう実装するか」を箱に入れてきた。
生成AIは、「何をどう組むか」の一部、構造の側にも手をかけ始めている。仕様を文章で渡すと、それを満たすコードの構成まで提案が返ってくる形だ。

もちろん、ここから「開発者はいらなくなる」という結論を引くのは早いだろう。これまでも、新しい箱が登場するたびにこれまで起きてきたのは、人間が考える位置の移動だった。

実装の多くをAIが生成できるようになれば、人間の問いはさらに上へ移るだろう。どう実装するかから、何を作るのか、なぜそれを作るのか、組み合わせたときにどんな体験になるのかへ。それがどこまで進むかは分からない。ただ、実装だけでなく構造の一部までが「答え」の側へ移り始めていることは、今あるツールからも見て取れる。

9. カプセル化で「失われるもの」

箱に入れれば、中を理解しなくても物が作れる。その代わりに起こることもある。

• なぜ動いているのか分からないまま動いている
• 問題が起きたとき、内部まで追いかけられない
• エンジンの設計思想に、作るゲームのほうが引っ張られる
• 使える部品から逆算して企画が決まる
• 技術的な制約から生まれていた独特の表現が減る

Wizardryの線画の迷宮は制約の産物だった。どの通路も同じように見えるから、方眼紙に地図を描かなければ迷う。暗闇の区画やテレポーターがそれに追い打ちをかける^[2:3]。その不便さがWizardryの手触りを作っていた。作り手が自由になれば表現が必ず豊かになる、というものでもない。

生成AIでも同じことが起こりうる。多くの人が同じモデルから素材やコードを受け取れば、平均的に整ったものが増える。整っていることと、そのゲームにしかない手触りがあることは別の話である。

10. 「古いゲームを見る」ということ

現代のゲームでは、「迷宮がある」という状態の裏に巨大な技術の積み重ねが隠れている。
初期のWizardryやRogueでは、その境目が薄い。
座標、壁、向き、敵のデータ、数値。ゲームの内部構造が、ほぼそのまま画面に出ている。

古いゲームを見ることは、懐古とは別に、今では見えなくなったゲームの骨格を観察することでもある。表現距離が短かった時代の画面には、現代のゲームの奥にも変わらずある世界モデルの形が、むき出しで映っているのだから。

11. 次に人間が考える「階層」

ゲームは四十年あまりで途方もなく複雑になった。けれど、人間が直接扱う複雑さまで同じように増えたわけではない。新しい複雑さが生まれるたびに、それは整理され、抽象化され、箱に入り、次の世代の前提条件になってきた。

初期のWizardryでは、座標と壁と数値がほとんどそのままゲーム世界だった。現代では、その背後に何十ものシステムがある。それでも開発者は「ここにオークを置く」と考えることができる。

技術が進むとは、複雑さが消えることではない。誰かが複雑さを引き受け、次の人がもっと上の問題を考えられるようになることである。

道の探し方はエンジンが引き受けた。コードや素材の作り方の一部も、AIが引き受け始めている。その上で、「ゲーム自体の目的地」を決める仕事は、その先でどの階層に残るのだろうか。

☕️よかったらコーヒー一杯。 https://buymeacoffee.com/mink_obs

著：霧星礼知(min.k) / リサーチ・構造支援：Claude Opus 5.5、ChatGPT / AI-assisted / Structure observation

For international readers

Game history is usually told as a list of new capabilities: 2D to 3D, offline to online, better hardware, smarter enemies. This essay reads it instead as a history of encapsulation. In early RPGs such as Wizardry (1981) and Rogue (1980), the program's internal world model — coordinates, facing, wall data, monster stats — appeared on screen almost unprocessed; an orc in Rogue was simply the letter "O." The author calls the gap between internal model and on-screen representation "representational distance." Over four decades that distance grew enormously, yet developers did not absorb all of the added complexity by hand. Rendering, physics, animation and pathfinding were split into independent systems and hidden behind simple interfaces, until a single call like Unity's SetDestination could move a character around obstacles. Engines took over how to find a path; deciding where to go remained the developer's job. Generative AI now appears to be encapsulating a layer above implementation — assets, code, and parts of structure itself. The essay also notes what encapsulation costs: black boxes, lost understanding, and the fading of expression born from constraint. It closes by asking which layer of thinking will be left to humans next.

Keywords

game history, encapsulation, abstraction, Wizardry, Rogue, Ultima, representational distance, game engine, Unity, pathfinding, generative AI, software engineering

ゲーム史、カプセル化、抽象化、Wizardry、狂王の試練場、Rogue、Ultima、表現距離、ゲームエンジン、Unity、経路探索、生成AI、構造の答え化、ソフトウェア工学