Catching ludonarrative dissonance at design time, not after the vertical slice

The term gets used loosely, so start with the version that is actually actionable: the game asserts something about its protagonist or its world, and the verbs it hands the player contradict it. The famous examples are all the same shape — a character written as reluctant who is mechanically rewarded for killing hundreds; a story about scarcity in a game where resources are abundant; a companion the writing insists you care about and the systems treat as a follower slot.

Why it is normally found late

It surfaces in playtesting because that is the first time the two halves are in the same room. Narrative and systems are usually written in parallel by different people from different documents. Nothing in either document is wrong on its own. The contradiction only exists in the join, and the join does not exist as an artifact anywhere — until the build.

By then it is expensive in the specific way that hurts most: fixing it means changing either the systems (weeks of work already balanced) or the story (already recorded, already animated). Teams almost always pick a third option, which is to live with it.

The structural version of the problem

Ludonarrative dissonance is not a writing problem discovered in play; it is a structural gap between the beat sheet and the mechanic list, and it can be found at design time by requiring every beat to name the mechanic that carries it. A beat that cannot name one is a moment where the story is happening to a player who is not doing anything — and that is exactly the moment players describe as the game telling them one thing while making them do another.

That reframing is the whole trick. “Does the story fit the game” is a question of taste that two people can disagree on forever. “Which mechanic carries this beat” is a question with a name as an answer, or no answer at all.

What to do with it

You do not need a tool to apply this. Take your beat sheet and add one column: the mechanic the player uses in this beat. Then look at what happens:

• Beats with no mechanic. Either the beat is a cutscene — fine, but count them, and notice when three land in a row — or the beat is asserting something the player never enacts.
• Mechanics that appear in no beat. A verb the game teaches and then never makes narratively meaningful. This is the quieter failure and often the more expensive one, because someone built it.
• Beats bound to a mechanic that contradicts them. The reluctant protagonist bound to the combat loop. Writing the binding down is what makes this visible; in prose it hides.

The third case is the one people expect. In practice the first two are more common and much easier to fix, because they are found before either half is finished.

Making it a constraint rather than a checklist

A checklist gets run once. The reason we enforce the binding in the schema — a beat without a mechanic is a validation error, not a warning — is that the contradiction does not appear when the beat sheet is written. It appears three revisions later, when the middle act got restructured and two beats quietly lost their verbs.

That is the argument for making it a constraint rather than a discipline: not that people are careless, but that the failure is introduced by editing, and editing never stops.

What this does not catch

Plenty. A beat can name a mechanic and still be dishonest about it — “the player negotiates” when the negotiation is a dialogue menu with one real option. Structural checks confirm the binding exists; whether it is a real binding is a judgement, and it stays a human one.

What the structure buys you is that the judgement gets made on twenty questionable bindings you can see, instead of on a build where the problem is felt but not located.