Building a Procedural Murder-Mystery Game That Still Has to Make Sense

Sun, 20 Sep 2026 03:50:17 +0000

Building Casefile: Sixty Seconds — From Murder-Mystery Prototype to Launch Sprint

I’ve been spending a lot of my development time lately on a new Vasken Interactive Studios project called Casefile: Sixty Seconds, and it’s finally starting to feel less like a prototype and more like an actual game.

The basic idea is a procedural mystery game built around a simple loop:

Briefing → Investigation → Accusation → Results

Players examine suspects and evidence, look for contradictions, and decide who is responsible. The goal was to make cases short enough to play in a few minutes without turning the deduction itself into guesswork.

One of the biggest development challenges has been procedural generation. Randomizing names, suspects, evidence, motives, and relationships is easy enough. Randomizing them while still producing a case that is logically solvable is another matter entirely.

So the generator now performs structural validation before a case reaches the player. I recently ran 1,000 generated-case tests, and all 1,000 passed validation. That was one of those development milestones that doesn’t look flashy in a screenshot, but it felt pretty damn good.

The current build includes:

Three handcrafted Pinecrest cases alongside procedural Dispatch cases
Six difficulty levels, from Rookie through Black File
XP, streaks, case archives, personal scores, and Clue Tokens
Daily Case and leaderboard-oriented competition systems
A Case Rush mode where the clock actually becomes part of the pressure
A Supply Desk with a small launch-focused purchase catalog rather than a giant monetization ladder
A progression system that lets players unlock higher difficulty tiers through play, with an optional Investigator Access Pack

The monetization philosophy has been another interesting design problem. I don’t want the game built around constantly interrupting the player or selling them the answer. The current plan is limited to optional rewarded ads, controlled interstitials between cases, Remove Ads, a small Clue Token pack, and the $9.99 Investigator Access Pack.

Most of the core game systems are now working. The remaining launch work is the less glamorous but absolutely necessary stuff: production art, tutorial polish, audio and feedback, mobile layout cleanup, Android packaging, Google Play Billing, leaderboards, privacy/compliance work, and final QA.

That means I’m currently in the dangerous stage of development where the game is functional enough to make you think, “I’m almost done,” while the launch checklist quietly laughs at you from the corner.

Still, seeing the investigation loop, procedural generation, progression, scoring, and case systems finally working together has been a great milestone.

Casefile: Sixty Seconds started as a fairly small idea: three suspects, a handful of clues, one contradiction, make the accusation.

It has turned into a considerably deeper system than I originally expected.

And apparently I have not yet learned my lesson about the phrase “This should be a simple app.”

— Wendell Wilhelm
Founder, Vasken Interactive Studios LLC

Procedural Generation Is A Rules Problem, Not A Randomness Problem

Fri, 21 Aug 2026 13:17:26 +0000

Most procedural generation threads turn into algorithm shopping lists, and the algorithm is rarely what went wrong. This is a writeup on the part that actually decides output quality, which is the structure you wrap around the random number generator.

Randomness Is Not Generation

A random number generator placing blocks at arbitrary positions produces visual noise. A procedural system that builds elevation from noise, runs erosion over it, assigns biomes from moisture and temperature gradients, then places vegetation by ecological rule produces something a player reads as a landscape.

The difference is that the rules encode design intent and the randomness only supplies variety inside them. When generated output feels wrong, the fix is almost always a missing constraint rather than a better noise function.

The Trade Has Not Changed Since 1984

Rogue generated dungeon layouts in 1980 so that each run was a new arrangement of rooms, corridors and monsters. Elite fit an entire galaxy of star systems into a few kilobytes in 1984 using mathematical seeds.

Both are the same bargain you make today: spend computation to save storage. What has grown is the pipeline, from a single RNG call to layered systems combining noise, grammars, constraint solvers and now models.

Determinism Is A Debugging Feature

The thing teams skip until it hurts is reproducibility. If a player reports that the world at seed 8815 was unwinnable and you cannot load exactly that world, you are debugging by guesswork.

That means every source of randomness has to run through the seeded generator, including the ones that sneak in later: hash iteration order, floating point differences across platforms, anything reading the wall clock. One unseeded call and the seed stops meaning anything.

Where Hand Built Content Still Wins

Generated content has a distribution and the bad tail ships too. Hand built content has no tail. That is why most shipped games run a hybrid: generated layouts assembled from hand made rooms, or a generated world with authored regions dropped into it, so the pieces are always good even when the arrangement is new.

Pacing is the other thing generators do not know. A generator cannot tell that the corridor before the boss should feel long.