COBOL FPS project brings Wolfenstein-style Raycasting to legacy code

A first-person shooter written in COBOL sounds like a joke with a compiler attached. It is not the kind of project anyone would choose for speed, elegance or an easy development cycle. COBOL was built for records, ledgers and business systems, not textured corridors, enemy sprites and weapon fire. That is exactly why this COBOL FPS game is interesting. It takes one of the most conservative programming languages still in use and pushes it into a space normally occupied by C, C++, JavaScript engines and dedicated game frameworks. The result is not a commercial shooter and does not pretend to be one. It is a working technical experiment that asks a simple question with surprising seriousness: how far can an old business language be stretched before it stops being practical?

A business language enters the corridor shooter

COBOL has a public image problem. For many developers, it represents legacy banking systems, mainframes, government payrolls and codebases that survive because replacing them is expensive and risky. That reputation is not entirely unfair, but it is also incomplete. COBOL is verbose, structured and deeply shaped by business computing, yet it remains a general-purpose programming language. Given enough patience, it can perform calculations, manage state, read files, call system functions and push bytes around. A raycasting first-person shooter needs all of those things.

The project uses that uncomfortable overlap to its advantage. Instead of treating COBOL as a museum piece, it treats it as a stubborn tool. The game renders a 3D-like world using raycasting, the same family of techniques associated with early 1990s corridor shooters. The player moves through compact maps, turns left and right, fires a weapon, sees enemies and navigates spaces that range from grid-based layouts to more advanced sector-style levels. It is a reminder that game engines are not magic. They are loops, maths, memory, input and output. COBOL can do those things, even when it makes the developer work for every step.

What is raycasting?

Raycasting is a rendering method that sends virtual rays from the player’s viewpoint into a 2D map to work out where walls should appear on screen. It creates a convincing first-person view without building a full 3D engine. That is why it was so useful for early shooters: it offered speed, clarity and atmosphere on limited hardware. In this COBOL project, raycasting is a practical choice because it keeps the problem difficult but still manageable.

Why this matters for retro game development

The appeal of a COBOL FPS game is not that COBOL is secretly the next major game development platform. It is not. The appeal is that the project exposes the layers that modern tools normally hide. Today, a developer can open an engine, import assets, add a camera and get a playable prototype quickly. That accessibility is valuable, but it can make rendering feel abstract. Building a shooter in COBOL strips the process back to fundamentals.

The game has to manage its own frame buffer, its own input loop, its own map data and its own rendering decisions. It outputs frames as raw bitmap data and relies on a media playback tool to display them. Keyboard controls are read through the terminal rather than a polished input library. This is not the smooth path. It is closer to building a display pipeline out of whatever the operating system will tolerate. That makes the project useful as a learning exercise, because every compromise is visible.

The technical trick behind the screen

The most interesting part of the project is not the fact that it compiles. It is the way it gets images onto the screen. COBOL does not arrive with a convenient modern graphics stack. There is no obvious equivalent of dropping into a popular game framework, opening a window and drawing textured polygons. The workaround is direct and deliberately rough: the program produces image frames as raw pixel data, then sends those frames outward so another tool can display them.

This matters because it separates game logic from visual presentation in a very blunt way. COBOL calculates what each frame should look like. Another program takes care of showing it fast enough to look like motion. The approach is inelegant compared with a native engine, but it works. It also fits the spirit of the project. The goal is not to make COBOL comfortable. The goal is to see whether a playable first-person shooter can exist when the language is dragged far outside its usual habitat.

The game uses a small low-resolution window, texture data, sprite data, player movement, enemies, health, weapon fire, map loading and a main loop that updates the world before building and writing each frame. It is recognisably a game engine, even if it is written in a language more often associated with invoices and account balances.

From Wolfenstein-style grids to Doom-like sectors

The project is not limited to a single flat maze. It supports two level styles. One is a grid-based layout similar in spirit to early raycasting shooters, where walls and paths are arranged in a regular map. The other moves towards a sector and linedef structure, with doors and different heights that bring it closer to the design language of early Doom-like spaces.

That jump matters. A basic grid raycaster is already an odd fit for COBOL, but it is still a known exercise. Sector-based geometry raises the ambition. It asks the program to handle more varied spaces, not just square rooms and simple corridors. Different heights make the world feel less flat, and doors introduce interactive structure. These additions turn the project from a simple proof of concept into something closer to a compact engine experiment.

The result still belongs to the world of hobbyist engineering rather than finished commercial game design. Yet that is part of its value. The rough edges help show the machinery. The game is not hiding behind shaders, middleware or asset stores. It is a direct demonstration of what happens when a language from the business computing era is forced to solve visual, interactive problems in real time.

COBOL makes everything explicit

A modern programmer looking at the code will notice how much is declared up front. Window dimensions, field-of-view values, texture sizes, map buffers, sprite data, player position, enemy states and world geometry all sit inside a structure that feels very different from contemporary game code. COBOL’s style is not subtle. It wants data definitions to be visible and formal. That can feel cumbersome, but it also gives the project a certain transparency.

The code defines enemies with states such as looking, chasing, attacking, taking pain and being dead. It tracks player health, shooting cooldowns, muzzle flashes and hit feedback. It stores wall textures, sprite textures, map rows, sectors, linedefs and things. Underneath the unusual language choice, the design is familiar to anyone who has studied old-school shooter engines. There is a player, a world, visible walls, animated threats and a loop that keeps everything moving.

That familiarity is what makes the project more than a novelty. The COBOL syntax is strange in this context, but the architecture is not absurd. The same core game development ideas appear here as they would in a more conventional language. The difference is that COBOL turns ordinary game-engine work into a negotiation.

The challenge is not just performance. The bigger issue is convenience. COBOL was not designed around graphics libraries, real-time input, asset pipelines or fast interactive development. Making a shooter in COBOL means solving problems that other ecosystems have already packaged neatly. That friction is the point of the experiment.

Performance is not the full story

The project targets a deliberately modest display resolution, with a small frame size and a frame cap around the familiar 60 frames per second range. That is sensible. A technical stunt does not need high-definition output to prove its point. Lower resolution reduces the amount of pixel data that must be generated for every frame and keeps the workload within reach.

But performance is only part of the discussion. The more interesting question is usability. Could this become a practical way to build games? Almost certainly not for most developers. The toolchain is awkward, the rendering route is indirect and the code is harder to iterate than it would be in a modern engine. The project is impressive precisely because it does not make the case for COBOL as a sensible game development choice. It makes the case that old languages remain capable when someone is willing to meet them on their own terms.

A useful lesson for modern programmers

There is a temptation to see programming languages as fixed categories. Some are for web apps, some are for systems programming, some are for data science, some are for games and some are for legacy maintenance. Those categories are useful, but they are also cultural habits. A language’s common use is not the same as its total capability.

This COBOL FPS game demonstrates that distinction neatly. COBOL is a poor fit for the task, but not an impossible one. That gap between poor fit and impossible is where a lot of interesting engineering lives. Developers learn by operating inside constraints. They learn when a missing library forces them to understand what the library would have done. They learn when graphics output becomes bytes, when input becomes terminal state, and when a map becomes a set of structures that must be parsed and rendered manually.

For students and experienced developers alike, the project is a useful reminder that abstraction is a privilege. Modern tools save time because they absorb hard problems. Recreating those problems in an inconvenient language can make the hidden work visible again.

Not nostalgia, but engineering curiosity

It would be easy to wrap this project in nostalgia: old language, old shooter style, old-school rendering. That would miss the sharper point. This is not really about returning to the past. It is about using the past as a stress test for the present. By forcing COBOL into real-time graphics, the project shows how much of programming is transferable and how much depends on ecosystem support.

The shooter format is a smart choice because it is immediately understandable. Everyone knows what should happen when the player presses forward, turns, fires or sees an enemy. That clarity makes the technical achievement easier to judge. The game either draws the corridor correctly or it does not. The enemy either appears in the right place or it does not. The input either feels live or it does not. There is little room to hide behind theory.

The open-source angle

The code being available under a permissive licence also matters. It turns the project from a video-friendly curiosity into something developers can inspect, run, modify and argue with. That is where experiments like this gain a longer life. A viewer can enjoy the absurdity, but a programmer can examine the frame loop, look at the data layout, test the map formats and consider how the same problem would look in another language.

It also gives COBOL a different kind of visibility. Many developers encounter COBOL only as an enterprise maintenance problem. Seeing it used for a first-person shooter does not erase that history, but it does loosen the stereotype. The language can be frustrating, verbose and inconvenient while still being computationally capable.

What this COBOL shooter really proves

The project does not prove that COBOL should be used for game development. It proves something better: that technical limits are often more flexible than they look. With enough persistence, a business language can produce a playable raycasting shooter with textured walls, enemies, firing, health, pickups and more advanced map structures. It can do so through a pipeline that is rough but functional, turning terminal input and raw frame output into a small interactive world.

For the wider programming community, that is the real story. The COBOL FPS game is funny at first glance, but its staying power comes from the seriousness of the implementation. It reminds us that software history is not a straight line from primitive to obsolete to forgotten. Old tools still contain possibilities, especially when used by people curious enough to ignore the expected boundaries.

In a computing culture obsessed with new frameworks and fresh abstractions, a shooter built in COBOL is a useful interruption. It does not ask developers to abandon modern tools. It asks them to look more closely at what those tools are doing. Behind every engine is a loop. Behind every frame is data. Behind every smooth demo is a stack of compromises. This project simply makes those compromises visible, one COBOL-generated frame at a time.