Blog

Why generated game dialogue falls apart as a conversation

9 min read

Generated dialogue reads fine line by line and collapses as a conversation. The missing pieces are state, stakes and memory. Barks are the honest sweet spot.

The line is fine. The conversation is not.

Take any generated block of game dialogue and read a single line out of it. It will be fine. The register will match the setting, the character will sound roughly like the description you gave, the grammar will be clean, and the line will be about the right length for a subtitle.

Now read the whole exchange in order. Something goes wrong around the third or fourth beat. Nobody wants anything. Nobody refuses anything. Every reply agrees with the previous line and adds a small amount of colour. The scene has no shape, it just continues until it stops.

This is the most consistent failure in generated dialogue, and it is easy to misdiagnose. It looks like a prose quality problem, so people respond by asking for better prose. Better prose does not fix it, because the problem is not in the sentences. It is in what the sentences are attached to.

A conversation in a game is not a sequence of good lines. It is a structure with three things underneath it: state, stakes, and memory. Generated dialogue arrives with none of the three, and every symptom traces back to one of them.

No state: nothing is being tracked

State is what the game knows at the moment the line is delivered. Where the player is, what they are carrying, who is dead, which door is open, how much health is left, what time it is, whether the alarm is raised.

Good game dialogue is soaked in state. When a character in Deus Ex comments that you came in through the vents, that line exists because the game recorded which route you took. When a companion in Dragon Age reacts to your armour, something checked your equipment slot. The line feels alive because it is a function of the world, not a fixed string.

A generated exchange has no idea any of that exists. It cannot condition on your route because nobody told it there was a route. So it writes lines that are true in every possible playthrough, which means they are specific to none of them. That is where the smooth, agreeable, slightly hollow tone comes from.

You can partly fix this, and the fix is not a longer description of the character. It is deciding which state your game exposes to dialogue at all. Once a character can ask the game five real questions about the player, generated lines get dramatically better, because they finally have something to be about.

No stakes: nobody in the scene wants anything

A scene works when two parties want different things and only one can have it. That is not a literary flourish, it is the load-bearing structure. Remove it and you get people exchanging information politely.

Disco Elysium is the extreme case in the other direction. Almost every conversation is a negotiation where someone is hiding something, protecting something, or trying to get you to do something. Even the internal voices argue with each other. You feel the pressure in every exchange because the pressure is designed in.

Generated dialogue defaults to cooperation, and there is a reason for that beyond training tendencies. Conflict requires knowing what each side would refuse, and refusal is a design decision about the character. If you have not decided what a character will not do, no writer, human or otherwise, can write them refusing.

The practical move is to write the wants before you generate the words. One line each: what this character wants from the player, what they will not give up, and what they are afraid the player will find out. With those three facts fixed, generated dialogue improves out of all recognition, because the scene now has an engine.

No memory: the scene forgets the game

The third gap is the one players notice fastest. A character talks to you as if you had just arrived, immediately after you burned down their village, rescued their brother, or spent nine hours as their travelling companion.

Memory in games is not the same thing as a conversation history. It is a set of durable flags the game keeps and dialogue reads. Mass Effect keeps them across whole games. Undertale keeps them across whole save files, which is why its characters can react to what you did before you reset.

Generated dialogue has whatever you put in front of it. If you supply a long history, it will use some of it, unevenly, and will not know which parts matter. Human writers face the same problem and solve it by reducing history to a small number of flags that the writing branches on. Betrayed or not. Spared or not. Paid or not.

That reduction is the actual craft. Choosing the six facts about the player that your characters are allowed to remember is worth more than any amount of generated text, because it is what turns text into a relationship.

Three formats, three very different problems

It helps to stop talking about game dialogue as one thing. There are at least three formats and they fail in different ways.

Barks are the short reactive lines characters say during play. Guards noticing a noise. A squadmate calling a flank. A shopkeeper greeting you. They are one or two lines, they fire from a trigger, and they are not a conversation.

Branching dialogue is the tree: the player picks an option, the tree moves to a node, the node offers new options. This is where most role-playing conversation lives, and it is where the state and memory problems bite hardest, because every branch has to be authored and reachable.

Authored scenes are set-piece writing, often with performance, timing and staging attached. This is the most expensive format per minute and the one players quote afterwards.

Generated content has a completely different value in each. Understanding which format you are working in tells you immediately how much help you are actually going to get.

Barks are the honest sweet spot

Barks are where generation genuinely helps, and it is not a small win. A stealth game needs dozens of variants of the guard noticing something, or the repetition becomes comedy within ten minutes. A shooter needs many versions of the same tactical callout. A shop needs greetings that are not identical every visit.

The reason barks work is that every problem listed above disappears. A bark does not need memory because it is over in two seconds. It does not need a conversation arc because it is not a conversation. It needs state, but only one piece of state, which the trigger already carries: the guard is suspicious, the ally is reloading, the player is low on health.

Half-Life 2 and the Left 4 Dead games are worth studying here. Both build enormous perceived character out of short contextual lines fired by system events. Nothing in those lines is a branching negotiation. They are reactions, and reactions scale.

So the honest recommendation is to spend generation on breadth here. Generate forty variants of the same bark, keep the twelve that sound right, throw the rest away. You are not asking the model to design anything. You are asking it to give you variety within a shape you already chose, which is the thing it is genuinely good at.

One caution: barks still need to be checked against the trigger. A line that is perfect for a guard who half-heard something is wrong for a guard who saw a body. Sorting generated barks by which trigger they actually fit is the part that takes real attention.

Branching dialogue: generate the leaves, not the tree

Branching conversation is where enthusiasm usually crashes. Ask for a dialogue tree and you get something that looks like one: options, replies, sub-options, all plausible. Play it and the branches turn out to converge on the same information regardless of what you pick.

That is because a real branch is defined by what it makes unavailable. Choosing to threaten someone should close the door on charming them later. If both paths lead to the same reply, the player made no choice, and players detect this quickly. They start clicking through.

The structural work is deciding the branch points and what each closes off. That is a small amount of work and it is entirely design. Once the shape exists, generation is useful for the leaves: the actual phrasings, the variants of a refusal, the flavour of a specific character delivering a fixed beat.

There is also a real cost to overproduction here. Every branch generated is a branch that has to be reachable, tested, and kept correct when the quest around it changes. A tree with two hundred nodes that nobody can navigate is worse than a tree with twenty that all matter.

Authored scenes stay authored

The scene players quote afterwards is almost always heavily authored, and this is the place where generated text is weakest. The reason is specificity. A memorable exchange usually turns on one strange, exact detail that no reasonable writer would predict.

Think of the details that stick: a small habitual gesture, an odd word choice a character keeps returning to, a joke that pays off two hours later. These are choices made by someone holding the whole game in their head. A generated line is drawn towards the most probable phrasing, which is close to the opposite instinct.

That does not make generation worthless in this format. It is a good sounding board for alternatives when you are stuck on a beat, and a good first pass on the connective tissue between the moments you actually care about.

But treat that output the way you would treat a blocked-out grey box level: it holds the shape, it proves the timing, it lets you play the scene and feel whether it works. It is a strong placeholder and a weak final line, and shipping the placeholder is what makes a game feel like nobody was home.

What to do on Monday

Write down the five facts about the player that your game will remember. Not fifty. Five. Everything else is decoration.

For each speaking character, write one line for what they want, one for what they will not give, and one for what they are hiding. Keep it on one page.

Use generation hard on barks, moderately on branch leaves, and lightly on set pieces. That gradient matches where the value actually is.

Then play it. Read the conversation at speed, in the game, with the pacing and the interface it will ship with. Text that reads well in a document often reads badly at the rate a player actually consumes it, and the only way to find that out is to sit in front of it. You do not need to have written the code to tell whether a conversation is dead on arrival. You just need to have been in it.