Someone Wrote a DOOM-style FPS Engine in COBOL, and It Actually Runs

A developer going by icitry has published FPS.cob, a working first-person shooter written in COBOL. The project's own description sets the tone: it is "what you get when you decide that game development is too easy nowadays," offering "an out-of-body experience in the ways of COBOL tomfoolery." The joke lands because COBOL is about the last language anyone reaches for when they want to push pixels in real time.

What's claimed

The repository advertises a raycasting engine with two distinct rendering modes. The first, loaded from map/level1.map, is the classic grid-based layout familiar to anyone who has poked at a Wolfenstein 3D clone: walls live on a uniform tile grid, and the renderer casts rays across the player's field of view to figure out wall distances and column heights. The second mode, map/doom_sectors.map, moves up to a sector and linedef representation. That is the data model DOOM itself used, where the world is described as polygons (sectors) bounded by line segments (linedefs), each sector carrying its own floor and ceiling height. The README notes this gives you doors and "different heights (so DOOM-like)."

Controls are what you would expect from an early-90s shooter: W and S to move, A and D to turn, Space to fire, Q to quit. Textures and sprites live under res/, maps under map/, and you build and launch through a build.sh script that optionally takes a map path as an argument.

What's actually new

Nothing here advances game technology. Raycasting was a solved problem by 1992, and the sector/linedef approach DOOM popularized is exhaustively documented. The interesting part is the implementation substrate. COBOL, the Common Business-Oriented Language, dates to 1959 and was designed for batch processing of records: payroll, ledgers, transaction reports. It has no native concept of a frame buffer, no graphics primitives, and its arithmetic and string handling were built around fixed-point decimal business data, not the floating-point trigonometry a raycaster leans on.

The project leans on two external pieces to bridge that gap. It compiles with cobc, the GnuCOBOL compiler, which translates COBOL into C and then to a native binary. Display and audio are handed off to ffplay, the lightweight media player bundled with FFmpeg. That division of labor tells you how the trick works: COBOL does the math and produces frames, and ffplay handles getting them onto your screen. A bash wrapper ties the build and run steps together. So the engine is genuinely computing visibility and projection in COBOL, while delegating the parts COBOL fundamentally cannot do to tools that can.

That is the substance worth appreciating. Writing a raycaster forces you to implement vector math, angle wrapping, a depth calculation per screen column, and texture sampling. Doing it in a language whose PERFORM loops and PIC clauses were meant for tallying invoices is a real exercise in mapping a domain the language never anticipated onto the primitives it does offer.

Limitations

This is a curiosity, and the author frames it that way. There is no claim of performance, portability, or completeness. You need a working GnuCOBOL toolchain, an FFmpeg install with ffplay, and a Unix-like shell, which already rules out running it the way most COBOL actually executes today, on IBM z/OS mainframes. The reliance on ffplay for output means the COBOL code is not drawing to a real graphics context on its own; it is producing data that another program renders. Anyone hoping for a self-contained COBOL graphics stack will not find it here.

The DOOM-style mode is described as "DOOM-like" rather than a faithful reimplementation, and the feature list (doors, variable heights) is modest next to the original engine's BSP traversal, lighting, and monster AI. Treat the sector renderer as a demonstration of the concept, not a port.

Why projects like this matter

There is a long tradition of porting DOOM and DOOM-adjacent renderers to absurd targets: pregnancy tests, oscilloscopes, PDF files, Minecraft redstone. Each one is partly a stunt and partly a teaching artifact. FPS.cob fits that tradition while making a quieter point about COBOL specifically. Estimates routinely put hundreds of billions of lines of COBOL still in production across finance and government, and the language carries a reputation as an inert relic that only does batch reports. A real-time renderer is a direct rebuttal to that framing. The language is more general-purpose than its usual job description suggests, even if no sane person would choose it for graphics.

For anyone curious about how raycasting works under the hood, an unconventional implementation can be more instructive than a polished one, because the author has to make every step explicit rather than calling into a graphics library that hides the geometry. The full source, maps, and assets are available in the FPS.cob repository, and the build comes down to running bash build.sh from the repo root once you have cobc and ffplay installed.