Wildermyth’s Real Procedural Character Trick: Design Against the Pitfalls, Not Just for the Arc
Most discussions of procedural characters start with the same question: how do you generate a person? Wildermyth’s developers asked a sharper one. At the 2022 Independent Games Summit, Worldwalker Games’ Nate Austin gave a talk titled “Getting Players Emotionally Invested in Procedural Characters in ‘Wildermyth.'” The abstract frames the whole game around a single target: “each aspect of the game bends towards this one goal, of creating memorable, relatable, even iconic heroes, and encouraging the player to love them.”
That’s the ambition. But the sentence I keep returning to is the next one. “Almost equally important,” the abstract says, “is avoiding the pitfalls, such as breach of trust, acting out of character, or rage quits.”
For a solo developer or a two-person team, that second sentence is the useful one. Generating more story is expensive. Preventing the moments where a generated character stops reading as a person is comparatively cheap — and it protects everything else the system is trying to build.
What the sources actually say, and what they don’t
I want to be careful here, because the temptation with a game this good is to reverse-engineer a system from the outside and present the guess as fact. The GDC Vault page I can read is an abstract, not a transcript. It states that the talk covers “specific techniques used, including how our procedural narrative system works,” and that it walks through examples of overcoming each pitfall. The talk itself is gated. So I can cite the stated goal and the named failure modes. I cannot describe the event data model, the arc-selection logic, or the tuning constants, because the retrieved source doesn’t contain them.
What the official site does give us is the design’s public promise. Wildermyth is described as “a character-driven, procedurally-generated tactical RPC, designed to help you tell your wildest stories.” Heroes “age, transform, fall in love disagree, and make harrowing sacrifices.” Each one “brings their own organic history and personality with them, but your choices and combat skills are what decide their paths and outcomes.”
Read those two sources together and a shape emerges. The game promises characters who persist as themselves while changing dramatically. The talk names the ways that promise breaks. That’s not a coincidence; it’s a design brief.
The pitfall list is a checklist, not a footnote
Take the three named failures seriously and each one becomes a testable rule for a small team.
Breach of trust. A generated character does something the player’s accumulated model of them says they would never do. The event might be dramatic and well-written, and it still lands as a bug. For a small team, the cheapest defense is a negative-space document: for each hero archetype or trait, write down what they will not do, and make the event system respect it. That document costs an afternoon. Retrofitting trust back into a shipped game costs a patch cycle.
Acting out of character. This is the softer cousin of breach of trust — not a betrayal of the player, but a drift. A cowardly hero charges; a loyal one abandons a friend for no traceable reason. The fix is usually not more authored content but a consistency check: does the event’s outcome contradict a flag the character already carries? If yes, either gate the event or write a transition that earns the change.
Rage quits. The abstract lists this alongside narrative failures, which is instructive. A rage quit can come from a story beat that feels unfair, not just from difficulty. Procedural systems are especially prone to this because the player can’t tell whether the outcome was authored or rolled. If a beloved hero dies to what looks like a random number, the player doesn’t blame the dice; they blame the game’s judgment.
Legibility is the mechanic
Here’s the argument I’d make from these sources, clearly labeled as interpretation rather than reported fact: the difference between a procedural arc that reads as literature and one that reads as noise is rarely the event itself. It’s whether the player can trace why it happened.
Consider a hypothetical — invented to illustrate the principle, not drawn from any playthrough. A hero betrays the party. In version A, the betrayal fires from a random roll after a certain number of chapters. In version B, the same betrayal fires because a tracked relationship value crossed a threshold the player has been watching erode for hours. The event text could be identical. Version A reads as the system malfunctioning. Version B reads as the payoff of a story the player helped write.
This is why the site’s phrasing matters: heroes have “organic history and personality,” but “your choices and combat skills are what decide their paths and outcomes.” The promise isn’t that characters are autonomous. It’s that their changes are attributable. A transformation, a rivalry, a sacrifice — each needs a visible cause the player can point to. When the cause is invisible, the same event becomes the pitfall the talk warns about.
Why this matters more for small teams than big ones
A studio with a narrative team can afford to author enough bespoke content that the seams rarely show. A solo developer can’t. What a solo developer can afford is constraint. Consistency rules — what a character will never do, which events are gated behind which flags, how the game signals that a change was earned — are cheap to write, cheap to audit, and they compound. Every rule you add narrows the space of incoherent outcomes.
There’s a version of this advice that’s just “write better characters,” which is useless. The Wildermyth abstract is more specific than that. It treats the pitfalls as engineering targets: breach of trust, out-of-character behavior, and rage quits are states the system can enter, and states can be tested for. That’s the reusable pattern. Before you build the arc generator, build the list of ways a generated person can stop feeling like a person — and make each one a rule the generator has to pass.
What this lens doesn’t tell you
I’d be overclaiming if I said this explains how Wildermyth’s arcs actually work. The abstract tells us the talk covers the procedural narrative system; it doesn’t tell us the system’s structure, its data model, or how the team tuned it. It also doesn’t establish that the approach produced measurable emotional investment or commercial success — those are separate questions the retrieved sources don’t answer.
What the sources do support is narrower and still useful: the team publicly framed emotional investment as the goal every aspect bends toward, and publicly framed pitfall avoidance as almost equally important. For anyone building procedural characters on a small budget, that ordering is the takeaway. The arc is the visible part. The consistency rules are the load-bearing part.
FAQ
Did Wildermyth’s developers say the pitfall list was more important than the techniques?
No. The abstract says avoiding pitfalls is “almost equally important” to the techniques for building attachment. It doesn’t rank them above the techniques. My argument that the pitfall list is the more actionable starting point for a small team is interpretation, not a claim about the team’s priorities.
Can I read the full GDC talk?
The session is listed on GDC Vault, and the page notes that free users get access to a portion of recent content. The retrieved page is the abstract; the full talk’s content isn’t reproduced here, so any claim about its specific examples or slides would go beyond what I can verify.
Does this apply to non-fantasy games?
The pitfall categories — breach of trust, acting out of character, rage quits — are about the player’s model of a generated character, not about genre. A sci-fi crew sim or a procedural detective game faces the same failure states. The specific rules you’d write would differ; the checklist structure wouldn’t.
