The Box Makes the Art
Constraints are not a weakness in creative systems. They are the structure that makes creativity possible. Modern engines remove constraints in pursuit of flexibility, at the cost of diluted identity.
What Should I Play?
On a Friday night, some time back, I sat before my PC. Kids were in bed, work was done, time to pursue some gaming via my Steam backlog. However I soon realized, as you probably have before too, that instead of playing a game, I spent a lot of time scrolling through my library. At some point it dawns on you: you’re spending more time choosing a game than actually playing one. This isn’t a new phenomenon. Too many choices create friction with decisiveness. At the time this didn’t feel like any big insight, rather just a small annoyance that I began to take note of. It wouldn’t really become more relevant until some time later.
Building Uber Tools
As a technical artist in the video games industry, a lot of my job focuses on building the tools, pipelines, and process to empower artists to achieve the art direction goals of a game, in a way that is performant and compliant with other gameplay systems. A common aspect of this role includes authoring shaders and materials in engines like Unreal, that allow artists to make the art for content. There is always a desire from the artists for a powerful “Uber material” with tons of levers of control. Exposed parameters for a myriad of options that, while impressive on a technical level, would ultimately fall short.
Its common for artists to constantly want to push for more options, more control, and one response might be to accommodate that. When artists say “oh if you expanded that material so we could also do X, it would be more powerful”, I was inclined to jump in and add it for them. Technical art is kind of like a “service role.” But much like an honest waiter warning you away from the “fresh fish,” I realized giving the “customer” everything they asked for might not actually be in their best interest. I began to observe a slowdown to artists output and ability to use the materials as they became more complex. There were too many options now, not enough clear direction. Things started to slip from the art direction goals and game identity could become diluted.
I realized I was looking at the same problem I myself had encountered with the Steam library. When systems give people unlimited options, their ability to make decisive choices falls, and creativity stalls. A tool that can do everything rarely tells you what it’s actually for. This idea appears everywhere: streaming services, game engines, art pipelines. More capability, while holding merit, doesn’t mean better outcome by default. But why is that? How could more options not lead to better outcomes?
At this point I’ve had years of experience making AAA games and indie games. Working on the indie games allowed for a lot of good asymmetrical experiences compared to AAA. Not in a one is good/bad way, just that they are very difference experiences from the development side. I’ve shipped 2 indie games now, where I’ve worked with just one other person to make the game. In this experience I realized that speed and consistency mattered more than theoretical capability. I would make targeted tools for myself (due to time constraints). But instead of feeling handicapped, I found that I could get faster results, more cohesive art, and fewer production hiccups. I’d find sometimes I would try to push a tool or system too far, and would ultimately back out those changes and try to find another solution without expanding the box I’m working in. I began to realize that, sometimes, the tools that looked the most powerful on paper were often the ones slowing me or my co-dev down.
Time to Focus
I began to look outwards for other examples of this as well in the industry. The first good example I found was a game called The Ascent, and incredibly gorgeous action RPG, developed by a small Swedish team. It was developed using Unreal Engine 4 by a team of 12 people.
I found an older GDC talk by the developers where they discussed in detail how they enforced a single workflow for artists, with simplicity and limitations, and that the end result was a full idealized identity for the game through cohesive environmental art. No second guessing. No decision paralysis. Instead, artists knew a singular way to generate content that allowed quick speed and no distractions. And it paid off for them.
The constraints weren’t a limitation of the pipeline. They were the reason the pipeline worked, and it empowered a small team to produce a lot of content focused around a singular identity.
There was another example of this more recently in the news, as the wildly popular game Clair Obscur: Expedition 33 released. It was another example of art that exemplifies the world because it offers a focused identity, while being high-quality at the same time. But past the art, the systems and gameplay are also doing the same thing. Recently it was revealed that the team didn’t write in C++ at all, even though they were working in Unreal Engine.
This wasn’t just a pipeline constraint, it was a workflow constraint. Hearing from the devs firsthand, it also allowed for rapid iteration, allowed non-programmers to participate, and ultimately worked out for them. Using Blueprints (visual scripting) as the primary gameplay layer might seem like a huge compromise in capability, but it actually created a shared language across the team. This is important. Limited by what was offered, but the update of reduced friction, of testing ideas quickly, of more level-playing fields of communication: all that paid off big time.
A Classic Idea
These ideas are not anything new or novel, though they are more rare today. But back in the 90s, my favorite era of gaming, these limitations were constant. There were palette limits, sprite memory, hardware output limitations. These things all drove games to rely on clarity. Clarity in their identity, in silhouettes, in color design. Retro games didn’t have the options of infinite detail, so they had to communicate with lucidity instead.
Take the NES for example. It could only display 25 colors on screen at once, pulled from a palette of 54. Sprites were restricted to 8×8 or 8×16 pixels, and the system could only render 64 sprites total, with a limit of 8 sprites per scanline. If a game tried to exceed that limit, sprites would flicker or disappear. Developers couldn’t brute force their way around these constraints. They had to design characters and environments that worked within them.
You can see this clearly in games like Super Mario Bros. Mario’s design is not accidental. His large nose, bright hat, and contrasting overalls weren’t just stylistic choices, they were solutions to a problem. With so few pixels to work with, the character had to remain readable at a glance. Even the mustache exists partly because it helped separate his nose from his face at low resolution.
Color restrictions forced similar creativity. The Sega Genesis supported 64 colors on screen out of a palette of 512, which was more capable than the NES but still extremely limited compared to modern rendering. Artists learned to cluster colors, exaggerate contrast, and rely on stylized shading rather than subtle gradients. These techniques created a visual language that is still recognizable today. Constraints forced clarity and clarity created identity.
Even the display itself shaped the art. Games were built for CRT televisions, which softened pixels through phosphor glow and scanline blending. Developers often relied on this effect intentionally. Dither patterns in games like Sonic the Hedgehog would visually blend into smoother gradients on a CRT display, even though the raw pixels looked coarse when viewed on a modern monitor.
None of this was optional. Hardware forced developers into a very small box. But inside that box, they found ways to produce some of the most memorable visual identities in gaming.
The limitations didn’t weaken the art, instead they defined it.
Retro Game Engine and Intentional Constraints
As you know, I’ve been writing my own custom game engine, inspired by retro games on the 90s/early 2000s. But Retro Game Engine is not simply nostalgia, its intentionally constrained.
That idea of intentional constraint is part of the reason RetroEngine exists at all.
Modern engines like Unreal and Unity are extraordinary pieces of software. They are designed to support almost any genre, rendering style, or workflow imaginable. That flexibility is a massive strength, but it also means developers can easily wander into directions that don’t actually serve the project they’re building.
RetroEngine takes a very different approach.
Instead of trying to be a universal tool, the engine is built around a single core assumption: the display matters.
The rendering pipeline begins with the idea that the final image will pass through a simulated CRT display stage. Every frame rendered by the engine is treated as if it will ultimately be drawn by an electron beam scanning across phosphor. This means the renderer focuses on producing images that work well with scanlines, phosphor persistence, and analog color blending.
That constraint immediately shapes the rest of the architecture.
Lighting systems are designed to remain readable under CRT-style color quantization. Sprite and mesh pipelines emphasize bold shapes and strong contrast. Even debugging tools in the engine, like the grid overlays and scene visualization systems, exist partly to help developers maintain spatial clarity and composition.
Instead of building an infinite set of rendering features, the engine focuses on a narrower goal: producing imagery that feels correct for this display model.
In practice this has an interesting side effect. When working inside Retro Game Engine, it becomes much harder to accidentally drift into aesthetics that don’t fit the intended style. The engine itself gently pushes developers toward visuals that work well with the simulated hardware.
In other words, the constraint is doing creative work.
Retro Game Engine isn’t trying to compete with modern engines as a multi-tool. It’s closer to a purpose-built instrument…a tool designed to do one thing extremely well (and ignore everything else).
Looking Ahead
The strange thing about constraints is that they often feel uncomfortable at first.
Artists want more control. Engineers want more capability. Tools grow larger, more flexible, more powerful. And for a while, that feels like progress.
But eventually something starts to break down. The work slows. Identity fades. Teams spend more time deciding how to build something than actually building it.
That’s when the shape of the box starts to matter.
The retro games many of us grew up with didn’t have a choice about limitations. Hardware forced them into that box. Today we have the luxury of choosing our constraints instead of inheriting them.
And I suspect more developers will start doing exactly that.
Because once you experience what it feels like to build inside the right set of limitations, something surprising happens. The box stops feeling like a restriction.
It starts feeling like a direction. And good work always needs a direction. What do you think? Do you find more clarity and identity from limitations, self-imposed or otherwise? Share your thoughts below!
Sounds so familiar to a former Houdini TD...