There is a moment, familiar to any serious roguelite player, where a dungeon layout clicks into place and you think: this was built for this exact situation. The choke corridor just before the boss chamber. The scattered torchlight that gives you enough visibility to plan but not enough to feel safe. The room where three exit doors open and two of them have been quietly blocked by the level, forcing you toward the encounter the designer actually wanted. That feeling of intentionality in a procedurally generated space is hard to produce. Most games that attempt it fall short in one of two directions: the dungeon feels mechanically random, or it feels like the same scripted template wearing a procedural costume.
That gap is what we are trying to close. This is the first post in our devlog, so it seems right to explain why this studio exists and what problem we think is worth a few years of our lives to work on.
The Dungeon You Have Played Before
Omar, Priya, and I have a combined catalog of roguelite hours that we are not proud to count. The genre is where we all got serious about games as design objects rather than entertainment products. But across that catalog, we kept bumping into the same failure mode: procedural generation that was technically present but experientially absent. You would see the number of possible layouts in a press release and then spend forty hours recognizing the same room shapes, the same enemy cluster patterns, the same bottleneck structure before every boss. The seed was different. The dungeon was the same.
The reason this happens is that most procedural systems in commercial roguelites are not really generating dungeons from principles. They are selecting from large-but-finite libraries of hand-authored room templates and stitching them together with corridor connectors. The variability is real at the data layer. At the spatial-reasoning layer, the player encounters an experience that converges toward predictability after enough runs, because the underlying template vocabulary runs out and patterns repeat.
We do not want to criticize specific games here. The template approach works for what it is, and some studios have pushed it much further than average. We are pointing at a design constraint, not a failure of craft.
What We Decided to Build Instead
Our approach starts from a different place. Instead of a library of room templates, we define a grammar: a set of rules about how spatial relationships between rooms can be constructed, what roles different room types play in a dungeon's tension arc, and what constraints govern the flow from entry to exit. When Ruinveil generates a dungeon, it is not selecting from a menu. It is constructing a layout by applying those rules to a fresh spatial canvas, constrained by the current run's seed and the player's progression state.
The grammar produces rooms that look different each time because they are structurally different each time. The choke corridor before the boss is not placed from a template; it emerges from a rule that says: before any high-density combat zone, the spatial approach should narrow and reduce the player's field of options. The rule fires, and the layout expresses it in a form that has never existed before.
We pair that with an enemy system built on the same principle. Enemies in Ruinveil are not unit types with fixed behavior scripts. They are assembled from trait pools that govern movement patterns, aggression thresholds, threat prioritization, and coordination behavior with nearby enemies. Each run's enemy set is composed from those traits into a coherent ecology: the enemies feel like they belong to the same dungeon because they are assembled to function together, not because they were tagged to the same biome.
Three People, One Studio
Majestic Mind Games is three people. Omar built the engine and the procedural core. Priya designed the enemy behavior and ecology systems and shapes the design layer. I handle the product, the design direction, and hold the vision thread across all of it. We are based in Riyadh and we have been working on Ruinveil since the middle of 2024.
Being a three-person bootstrapped studio puts real constraints on what we can attempt. We cannot afford to build intricate hand-authored content at scale. We have to generate it. That constraint is, honestly, part of why the grammar approach appealed to us: it is a better fit for a small team than a content-heavy pipeline would be. We write rules rather than rooms. The system does the construction work.
That said, writing rules that produce interesting emergent behavior is genuinely difficult. There is a category of constraint problem that looks solvable until you try it and discover that the edge cases compose against each other in ways that produce degenerate layouts. We have not solved all of those problems. We are still finding failure modes in the grammar that only appear after hundreds of generated runs. Some of them are subtle enough that players might not notice, and some of them break the layout in ways that are immediately obvious. Finding those and closing them is ongoing work.
Why Roguelites Specifically
The roguelite format is the right container for this kind of system for a few reasons. The loop structure means players return to the dungeon repeatedly, which puts pressure on the variety system in a way that a linear game never would. If a player completes twelve runs and the layout has visibly converged, the system has failed. The format demands that we actually solve the variety problem, not just approximate it.
The runs-as-stories aspect matters too. A dungeon layout that is generated fresh each run can become part of how a player tells the story of that run to other people. The seed system we built is designed to support that: every run in Ruinveil is fully reproducible from its seed, so when a player describes the dungeon they survived to a friend, the friend can load that exact experience and walk through it. That creates a kind of shareable object that hand-authored content cannot produce in the same way.
Roguelites also have a community that is unusually engaged with the design layer. People who play this genre seriously think about what makes a dungeon work. They notice when a run has a particular spatial quality that cannot be attributed to luck alone. That is the audience we want to make something for.
What This Devlog Will Cover
We are going to write about the specific systems we are building and the specific problems those systems run into. Not promotional summaries of how great the technology is. Real design decisions, real tradeoffs, real cases where we built something and it did not work and we had to think harder about it.
Over the coming months we will go deeper on the level grammar: how the constraint rules are structured, where they break, and how we detect bad layouts before they reach a player. We will write about the enemy trait system and the ecology logic that assembles encounter sets. We will write about the seed architecture and what it required from the underlying generation pipeline. When we run playtests, we will write about what players told us and what it changed.
The goal is not to make this studio look impressive. The goal is to document what it actually looks like to build a system like this with three people and a specific set of design beliefs.
If you are building in this space or just curious about the mechanics behind what you are playing, follow along. We will try to be worth your time.