「COBOLでFPSは作れるのか」という挑戦：ビジネス言語によるレイキャスティングの実装を紐解く

2026年6月8日 H.Ueda

今回は、Hackaday で紹介されていた「COBOLで作成されたレイキャストFPS」というトピックを参考に、一見すると不向きに思える言語でいかにして複雑なシステムを構築するか、そのハックの面白さについて整理してみます。

中々やるなって感じだね。(^^;

ビジネス言語で3Dグラフィックスを実現する

COBOL（Common Business Oriented Language）といえば、その名の通り事務処理や会計システムのために設計された言語です。1950年代に誕生して以来、堅牢な帳票出力や大量のデータ処理を支えてきましたが、およそゲーム制作、それもリアルタイム性が求められるFPS（ファーストパーソン・シューティング）に向いていると考える人は少ないでしょう。

しかし、理論上はチューリング完全である以上、計算によって3D空間を描画することは可能です。YouTubeで活動するハッカーの [icitry] 氏は、この「可能かどうか」を実際に形にすることで証明しました。

まずは、このシステムがどのようなパイプラインで動いているのか、その全体像を確認してみましょう。

実行の仕組みとデータフロー

COBOLにはモダンなゲームエンジンのようなグラフィックスライブラリは存在しません。そこで、描画や入力といった低レイヤーな処理を、外部ツールや標準入出力を駆使して解決しています。

flowchart TD
    subgraph Terminal [ターミナル環境]
        Input[キー入力: Raw Inputモード]
    end

    subgraph COBOL_App [COBOL プログラム]
        direction TB
        STDIN[STDIN 読み込み] --> Logic[ゲームロジック / 敵のAI]
        Logic --> Raycast[レイキャスティング計算]
        Raycast --> Bitmap[ビットマップデータ生成]
    end

    subgraph Display [外部ビューア]
        FFplay[ffplay: 標準入力を映像として再生]
    end

    Input --> STDIN
    Bitmap -->|STDOUT / パイプ| FFplay

こちらのような構造になっており、COBOLプログラム自体は「生のビットマップデータを標準出力（STDOUT）へ流し続ける」という極めてシンプルな（そして力技の）役割に徹しています。

開発における工夫とトレードオフ

事務処理用言語でゲームを作るとなると、普段私たちが当たり前だと思っている機能が使えないため、独自の工夫が必要になります。

入出力のハック

通常、COBOLの入力はバッチ処理や定型フォームからの読み込みがメインですが、このプロジェクトではターミナルを「Raw Input（生入力）」モードに設定しています。これにより、キーボードの入力をリアルタイムに STDIN から読み取り、プレイヤーの移動や旋回に反映させているようです。

出力に関しても、描画ライブラリをリンクするのではなく、ffplay（FFmpegに付属するプレイヤー）にパイプでデータを渡す手法が採られています。ビットマップ画像を1フレームずつ垂れ流し、それを動画として表示させているわけです。

実装の比較

従来の用途と、今回のFPS開発での使い方の違いを表にまとめると、そのギャップが分かりやすいかもしれません。

項目	事務処理（本来の用途）	今回のFPS実装
主な処理	算術計算、帳票作成、DB操作	行列計算、スプライト制御、視界判定
データの流れ	固定長レコードの読み書き	リアルタイムな入出力ストリーム
描画方法	テキストベースの帳票、CSV	生ビットマップ（RGBデータ）の出力
パフォーマンス	正確性が最優先	フレームレートの維持（秒間数10回）

レイキャスティングとロジックの構築

ゲームの内容は、初期の『Wolfenstein 3D』のような、レイキャスティングを用いた擬似3D表現です。

プレイヤーの視界から「光線（レイ）」を放射状に飛ばす。
壁に当たるまでの距離を計測する。
距離に応じて、画面中央に描画する垂直線の高さを決定する。

これに加え、[icitry] 氏は「可変高さのセクター」まで実装しており、これは『DOOM』のような高低差のある表現に一歩近づいたものといえます。

COBOLの冗長な構文で、スプライトの描画や敵の移動ロジックを記述するのは、想像以上に骨の折れる作業だったのではないかと思います。動画内でも、言語仕様に対する愚痴がこぼれる場面がありますが、それでも最終的に「動くもの」を作り上げている点は、ハッカー精神の賜物と言えるでしょう。

なぜ「不向きな言語」で挑戦するのか

わざわざCOBOLでFPSを作ることに、実用的な意味はほとんどないかもしれません。しかし、この試みは「特定の用途に特化したツールであっても、工夫次第で本来の目的を超えた使い方ができる」という大切なことを教えてくれます。

たとえば、システム開発の現場でも「今の言語やフレームワークでは実現が難しい」と直面する場面があるかもしれません。そうした際に、標準入出力を組み合わせたり、外部ツールとパイプで繋いだりといった「泥臭いハック」が解決の糸口になることもあるのではないでしょうか。

今回の事例は、プログラミング言語の限界を決めるのは言語そのものではなく、私たちの想像力と実装力であるということを、改めて認識させてくれる面白い試みだったと感じます。興味がある方は、GitHubに公開されているソースコードを眺めてみると、COBOLに対する見方が少し変わるかもしれません。

MicroArchitectures

H.Ueda

Programmer

ブログ