CASE STUDY / C99 / PROCEDURAL DUNGEONS / ENEMY BEHAVIOR
1.44 MB :: Sectors of the Lost Disk
容量制約の中で、生成・描画・敵の行動を組み合わせたダンジョンクロウラー。見た目だけでなく、世界のつくり方と振る舞いの仕組みを読むためのケーススタディです。
- 96,256 B
- size-log.md記録のWindows / UPX版。今回の再計測値ではありません。
- 15 floors
- READMEに記載された手続き生成フロア数
- C99
- 生成・ゲーム状態・敵AI・レイキャスターを公開
ROLE & CONSTRAINTS
何を、どうつくったか。
ゲーム設計・C99による実装。描画・入力はTIGR、タイル画像はDCSSのCC0素材を使用。
1枚のフロッピーディスクという制約の中で、探索できる世界と、読みやすいターン制の遊びをどう構成するか。
DESIGN DECISIONS / SOURCE EVIDENCE
仕組みまで、見せる。
BSPで部屋を分割し、L字通路で接続
領域を再帰的に分割し、葉の領域内に部屋を配置。生成順に隣接する部屋の中心をL字の通路で結びます。コードのコメントにはMST風とありますが、最小全域木を計算しているわけではありません。
src/map.c / bsp_split・connect_centers ↗「最後に見た位置」を記憶する敵
敵の位置が現在の可視領域にあるときにプレイヤー位置を記憶。追跡は差分の符号から斜め移動を試し、失敗時に縦横へ切り替える局所的な規則です。ランダム移動やテレポートもフラグで切り替えます。A*や学習ベースAIではありません。
src/mob.c / ai_step ↗描画とゲームロジックを分ける
DDAによる壁の探索、床・天井の透視補正、スプライトの深度判定をrender3d.cに、ターン進行をgame.cに分けています。画像素材の埋め込みとUPX圧縮による容量変化は、段階別のログで追えます。
src/render3d.c / size-log.md ↗LIMITATIONS & NEXT QUESTION
できたことと、次の問い。
- 公開ログは特定のビルド段階の容量です。環境や依存ツールを変えた再ビルドのサイズは未検証です。
- 部屋の接続は生成順。経路長・分岐・到達率を複数seedで比較した評価は、この作品には掲載されていません。
- 局所的な追跡では障害物の迂回に限界があります。最適経路や高度な意思決定は保証しません。
今後は生成器のseed集合を固定し、到達率・経路長・敵の追跡成功率を評価したいと考えています。追加したブラウザーデモは、その評価の入口となる別実装です。
REPRODUCTION / READING GUIDE
実装を確かめる。
公開READMEの手順です。macOSの開発用ビルドとWindows提出用ビルドを区別しています。既存ゲームのビルドをこのサイト改修では再実行していません。
make mac
make run
# Windows submission / MinGW-w64 + UPX
make submit解説は2026年11月1日に確認した固定コミットの公開ソース・README・記録に基づきます。
FROM SOURCE TO EXPERIMENT