Devlog
We document design decisions, AI system architecture, and playtesting results as Ruinveil takes shape. Every major call we make about the dungeon generator, enemy AI, and player experience gets a post.
Closed Beta Feedback: 40 Players, 200 Hours, What We Fixed
We ran a 40-player closed beta over two weeks. This post summarizes the feedback we received, the bugs we found, and the three design changes we made in response. Adaptive difficulty needed to be less subtle.
Read PostAll Posts
Dynamic Difficulty: Matching the Challenge to the Player
Hard-coded difficulty tiers do not work with a procedural dungeon. Our approach dynamically adjusts room density, enemy aggression, and loot scarcity based on run-level performance signals.
Read Post
Measuring Run Variety: How We Know the AI Is Working
We built internal metrics to track layout uniqueness, enemy set overlap, and encounter repetition across runs. The data tells us when the generator gets lazy before players do.
Read Post
Three People, One Dungeon Engine: Our Toolchain
Bootstrapped studios cannot afford custom tools at every layer. We describe the combination of off-the-shelf and custom infrastructure we built to generate Ruinveil's content at runtime.
Read Post
The Tension Between Combat Feel and Procedural Fairness
A procedurally unfair room can feel intentional in the right context. We explain the heuristics we use to keep our AI generator from producing fights that feel arbitrary versus fights that feel earned.
Read Post
First Playtest Results: What Ruinveil Taught Us
We ran our first structured playtest with 12 external players. The feedback was specific, occasionally brutal, and exactly what we needed. Here is what we learned.
Read Post
Ecology Over Taxonomy: How We Design Enemy Sets
We do not place enemies by type. We place them by role in an ecological context: predators, harassers, sentinels. When the system assembles a room, it thinks about food chains.
Read Post
The Seed System: Guaranteed Uniqueness, Guaranteed Replay
Every Ruinveil run can be replicated from a single seed string. We built this from the start so speedrunners and streamers get value from our procedural system, not frustration.
Read Post
Room Composition Rules: The Grammar Behind the Grid
Each dungeon room obeys placement rules we call a grammar. We explain how that grammar encodes dungeon tension, pacing, and surprise into spatial constraints.
Read Post
Enemy Behavior Trees: How AI Decides to Fight You
Our enemies do not follow scripts. They consult trait-driven behavior trees assembled fresh each run. Here is the architecture behind that decision.
Read Post
How We Generate Dungeons: Our Level Grammar System
Level grammar rules control how rooms chain together. We break down the constraint system that produces layouts that feel hand-designed even when the engine assembles them in 80ms.
Read Post
Why We Started Majestic Mind Games
We built this studio because we kept playing the same dungeon twice. A look at the problem that started Majestic Mind Games and the AI direction we chose to solve it.
Read Post