The Quiet Revival of Self-Imposed Constraints in Indie Game Development

A solo developer recently published a long technical writeup about Catlantean 3D, a first-person shooter built to run as if it were 1993. The rules he set for himself read like a dare: 320x240 resolution, 256 colors, all rendering done by hand, all sound mixing done by hand, fixed-point math for deterministic game logic, and a flat refusal to use any "AI slop." He's been at it for over a year and plans to ship on Steam in Q1 2027 for somewhere between five and eight dollars.

On its own, this is just one person's hobby project. But it lands in the middle of a pattern that has been building across developer communities for a couple of years now, and that pattern is interesting precisely because it runs against the prevailing current.

The trend: constraint as a feature, not a bug

The dominant story in software right now is removal of friction. Code generation, asset generation, automatic upscaling, one-click everything. The promise is that you spend less time on the tedious parts and more time on the parts that matter. It's a compelling pitch, and for a lot of work it's the right call.

What's notable is the countercurrent. A visible and vocal segment of indie developers is moving the opposite direction, choosing constraints that no tool forces on them. The Catlantean 3D author put it bluntly: "Restriction forces deliberate choices, and deliberate choices tend to look good." He's not the first to say this. The PICO-8 fantasy console, which caps developers at a 128x128 screen, 16 colors, and a tiny code budget, has cultivated a devoted following for exactly this reason. The Pico-8 community treats its limits as a creative engine rather than a cage. Game jams like the long-running Ludum Dare lean on hard time and theme constraints for the same effect.

The argument these developers make is consistent: when every pixel and every byte costs you something, you make decisions you would otherwise defer or automate away. The result reads as intentional because it was.

The evidence: this is craft writing, not just a tech demo

What makes the Catlantean 3D writeup worth examining is how much of it is about technique that has no shortcut. Take the lighting. A raycaster like this can't just multiply a color by a darkening factor the way a GPU shader would, because the framebuffer holds palette indices, not RGB values. The classic solution, used by Doom and its contemporaries, is a colormap: a precomputed table where each color has 31 progressively darker variants, all sourced from the same fixed palette.

The detail that signals real care is how he picks those darker shades. The naive approach is Euclidean distance in RGB space, which several older games used. He tried it and found that dark shades drifted toward grey and looked "cold and lifeless." So he converted the palette into Oklab color space, which models perceptual color difference far better than raw RGB, and added a slight warm hue shift as colors darken, a trick pixel artists call hue shifting. His justification is refreshingly honest: "I have no idea, it just looks right."

That tension runs through the whole piece. He pre-renders complex animated sprites in Blender because hand-animating every frame would be too slow, then admits that the hand-drawn status bar face of his cat Vilko looks far better than the Blender-rendered version everyone kept criticizing. "Some things just need to be drawn by hand," he writes. The lesson isn't "automate everything" or "hand-craft everything." It's knowing which is which.

Even his procedural work is constrained craft rather than generation. The gibbing system that blows enemies into bloody chunks uses Voronoi decomposition to partition a sprite into pieces, a breadth-first search to bleed wound color inward from chunk borders, and a crude physics pass with no collision detection. Chunks just stop when they hit the floor. "It's crude, but it's good enough" is a sentiment you rarely see in marketing copy, which is part of why it's persuasive.

The counter-perspective: is any of this actually necessary?

It would be dishonest to present this as obviously correct. There are strong arguments against the whole approach, and they deserve airing.

The first is economic. The author works a full-time job and builds this in his spare time, and even he repeatedly optimizes for speed: gitignoring rendered assets and regenerating them in ten seconds, scripting Blender to batch out eight-direction sprite sheets, parameterizing texture generation so tweaking a material is a config change rather than a repaint. So the constraints are selective. He uses a modern compiler, a platform abstraction layer, Python, Affinity Photo, Aseprite, and pybind11 bindings to his C++ engine. The 1993 aesthetic is real, but the toolchain is thoroughly 2026. A skeptic could reasonably ask whether the "made it like it's 1993" framing is partly a story being told to an audience rather than a strict engineering necessity.

The second is that constraint-driven retro work can curdle into a cliché of its own. The market is now thick with pixel-art roguelikes and intentionally low-res shooters. Limited palettes and chunky pixels are no longer a guarantee of distinctiveness. The author even names the failure mode himself, the "asset flippers or low-effort indie games" that combine assets at inconsistent pixel scales and look wrong because of it. His point is that the look only works when it's disciplined, which cuts both ways: most attempts won't have that discipline, and the style alone won't save them.

The third, and most pointed, is the anti-AI stance. Calling generated content "AI slop" is a position, not a neutral observation, and there are accomplished developers shipping good games with AI-assisted pipelines who would push back hard on the implication that machine-generated assets inherently lack "soul." The author's own workflow blurs the line anyway. Procedural Voronoi gibbing and noise-driven particle synthesis are algorithmic generation; the distinction he's drawing is really about authorship and control, not about whether a computer produced the pixels.

What the sentiment signals

The most revealing part of the writeup isn't technical at all. It's the closing argument about why he's open-sourcing the engine while selling the data archive, and why he's documenting the process in such detail. "Transparency about process is one of the few things that actually builds lasting trust," he writes. "Indie games live and die on it in a way AAA simply doesn't, because that market has demonstrated it will accept whatever it's given."

That's the real trend underneath the palette tables and colormaps. The constraint-driven, show-your-work approach is partly an aesthetic choice and partly a trust strategy aimed at an audience that increasingly suspects it's being marketed at rather than made for. The developers leaning into visible craft are betting that a smaller audience which feels "in on the process" is worth more than a larger one that doesn't.

Whether that bet pays off at the cash register is genuinely unsettled. Plenty of lovingly hand-built indie games sell a few hundred copies. The visibility of the technique on developer forums and aggregators doesn't translate cleanly into sales, and survivorship bias makes the successful examples look more representative than they are. But as the cost of generating passable content trends toward zero, the things that can't be generated cheaply, demonstrable intent, consistent taste, and a credible account of how the work was made, become the scarce signals. A 256-color shooter built one deliberate pixel at a time is, among other things, a wager on which kind of scarcity will matter.