Barks & Ambient Dialogue: Writing Repeated Lines | Skrib

Every other kind of writing is judged on first contact. A first line, a first scene, a first impression.

A bark is judged on the fortieth hearing.

That single inversion accounts for almost everything strange about the discipline. A line that lands beautifully once and grates by the tenth repeat has failed. A line nobody notices the first time and still tolerates at fifty has succeeded. You are not optimising for impact. You are optimising for durability, and the two pull in opposite directions.

Which is why barks are so often written badly by good writers. Every instinct a writer has - be specific, be memorable, be funny - actively shortens a line’s usable life.

It’s one of the narrative channels mapped in our video game writer’s handbook.

What is a bark?

A bark is a short, non-branching line of dialogue triggered automatically by a game state - an enemy spotting the player, a companion reacting to a location, a merchant noticing someone browsing. Barks aren’t chosen by the player and don’t advance a conversation. They deliver feedback, characterisation and world texture continuously, at near-zero cost to the player’s attention.

Ambient dialogue is the broader term, covering background conversations between NPCs that the player overhears rather than triggers.

Wit is a liability

The hardest thing to accept about the form.

A joke has a half-life, and it’s short. The funnier a bark is, the more distinctive its rhythm, the faster the player learns it - and once learned, a joke isn’t a joke, it’s a sound the game makes.

The most famous example in the medium is a guard’s remark about an old knee injury: a perfectly good line, in too small a pool, on too common a trigger. It stopped being characterisation, became a meme, and ended up as shorthand for repetitive game dialogue generally.

Plain lines outlast clever ones. A guard saying something unremarkable about the weather can fire two hundred times and remain furniture. A guard with a memorable comic observation becomes a running joke about your game.

This doesn’t mean barks should be bland. It means distinctiveness must be rationed - reserved for large pools, rare triggers, or moments where you want the player to remember. Spend personality where it can survive the frequency.

Four jobs, four sets of rules

Knowing which job a bark is doing determines almost every decision about it.

Feedback barks are functional first and creative second. A line telling the player an enemy has spotted them is a UI element that happens to be spoken. If a player misses it, they take damage they couldn’t anticipate, and no amount of good writing compensates.

Characterisation barks are the ones that wear out, because personality is exactly the quality repetition destroys. They need the largest pools and the rarest triggers.

Texture barks are the most forgiving. Background chatter the player half-hears can repeat far more than anything directed at them.

The feedback bark has a hard deadline

A technical constraint that changes how you write the sentence.

A combat feedback bark must be understood within roughly half a second, under gunfire, possibly overlapping another line. That’s not a stylistic preference - it’s the window before the information becomes useless.

Front-load the information word.

Grenade!

not

Watch out, he’s throwing a grenade over here!

By the time the second version reaches its noun, the grenade has landed. The first word carries the payload; everything after it is optional.

Practical rules for feedback barks:

• Under two seconds, ideally under one

• Noun first, qualifiers after

• No subordinate clauses - the player is parsing at a fraction of normal attention

• Distinct from each other acoustically, not just semantically, so the pool doesn’t blur

• Survivable when clipped, because they will be interrupted

The unit is the pool, not the line

The production insight that reorganises the work.

You never write a bark. You write a pool - a set of variations for a single trigger, from which the game selects. Perceived repetition is a function of two numbers:

How often the trigger fires ÷ how many lines are in the pool.

Which means a mediocre line in a pool of twenty outperforms an excellent line in a pool of three, every time. The writing task is set design, and the most common failure in the discipline is writing three great lines where fifteen adequate ones were needed.

Varying a pool properly means varying more than words. Fifteen lines that all follow the same syntactic shape read as one line with substitutions. Vary:

• Sentence length - some one-word, some a short clause

• Register - some formal, some clipped, some muttered

• Direction - some to the player, some to a colleague, some to themselves

• Emotional temperature - irritated, bored, alarmed

• Whether they’re a complete thought at all - trailing off is a legitimate variant

Pool sizing

Rough working guidance. Actual numbers depend on session length and how often a system fires.

Two adjustments worth making. Weight the pool so common variants fire more often and distinctive ones surface rarely, which extends the life of the good lines. And suppress recent repeats - even a large pool feels small if the same line can fire twice in a row.

Triggers, priority and overlap

Barks are a systems problem as much as a writing one, and writers who understand the system write better lines.

Priority. When two barks want to fire, one wins. Feedback should always outrank texture - a witty observation that suppresses an enemy-spotted line is a bug with a nice line in it.

Cooldowns. Most systems enforce a minimum gap. Knowing yours tells you how much of your pool will ever be heard.

Overlap. Two barks can fire simultaneously from different speakers. Write them so any combination is survivable - no line should depend on being heard in isolation, and no two lines should combine into an accidental joke.

Attribution. The player often can’t see who spoke. If a line only makes sense when you know the speaker, it needs to identify itself or belong to a character with a distinctive voice.

Interruption. Barks get cut off by combat, other dialogue, or a scene starting. The meaning should survive truncation, which is another argument for front-loading.

Getting these conditions built the way you specified them is a cross-discipline negotiation - Working with Game Designers: Aligning Story Beats with Mechanical Systems covers it.

The VO budget

The commercial reality that constrains everything above.

Every bark is a recorded line, and lines cost money individually - session time, direction, editing, implementation. A pool of twenty barks across twelve characters is 240 recorded lines for one trigger.

Consequences for how you write:

• Pools get cut. Write them in priority order so the top ten survive a reduction.

• Late additions are expensive. A line added after a voice session means a pickup session or a silent bark.

• Reusable is valuable. A line that works for several characters or several triggers earns its recording cost several times over.

• Text-only barks are free. If your game displays subtitles or floating text for some ambient lines, that pool can be far larger.

Localisation multiplies all of it. Every bark is recorded again in every shipped language, which makes pool decisions expensive in a way that isn’t obvious from a spreadsheet - and it makes translation-readiness a first-draft concern rather than a later pass. Localization-Friendly Writing: Formatting Game Scripts for Translation covers what breaks.

Eight rules that survive contact with a build

1. Front-load the information. First word carries the payload.

2. Ration distinctiveness. Personality in large pools and rare triggers only.

3. Avoid referencing changeable state. A line naming a location, quest or item breaks when those change - and they will.

4. Avoid time references. Still and again and finally assume a history the game may not have.

5. Write for overlap. Every combination should be survivable.

6. Vary structure, not just vocabulary. Fifteen lines in one shape is one line.

7. Write the silence. Not every trigger needs a bark. A companion who says nothing when the player does something appalling has said something - this is the same principle that makes silence characterising in companion characters.

8. Read the whole pool aloud in sequence. The only reliable test. Pools that look varied on a spreadsheet frequently sound identical.

Where barks go wrong

Pools too small. The single most common failure and the one players notice first.

Jokes on common triggers. A punchline structure has the shortest half-life of any line type.

Buried information. Feedback that arrives after the event it was warning about.

Stale state references. A bark about a quest the player finished two hours ago.

Nonsense overlaps. Two lines that combine into something unintended.

Wrong priority. Texture suppressing feedback.

No suppression. The same line twice in a row from a pool of twelve, which reads as a pool of one.

Uniform pools. Fifteen variants, one rhythm.

Managing pools without losing the thread

Bark work is the least document-shaped writing in games. It lives in tables - trigger, condition, speaker, priority, cooldown, line, VO reference - and a single system can produce thousands of rows across a dozen characters. The writing happens in a spreadsheet, the trigger logic lives in a design doc, and the character’s voice guide is somewhere else entirely, which is how a pool ends up with fifteen lines that all sound like the same person having the same thought.

Skrib fits that shape better than most writing tools. Bark tables and line lists move in and out as .csv and .xlsx, which is where this material actually lives, and the Plan is a canvas with no page edge where trigger maps, priority orders and each speaker’s voice notes can sit beside the pool you’re writing. The Library keeps every version searchable, which matters when a pool gets rebuilt after a VO cut.

To be clear about what it isn’t: Skrib doesn’t fire triggers, manage cooldowns or connect to an engine. It won’t tell you a bark never plays or that two lines overlap badly - that’s a build problem, found in playtest. It’s where the pool is written and kept legible before it gets there. You can start free.

Frequently asked questions

What is a bark in game writing? A short, non-branching line triggered automatically by a game state - an enemy spotting the player, a companion reacting to a location. Barks aren’t selected by the player and don’t advance a conversation; they deliver feedback, character and world texture continuously.

How many barks do you need for one trigger? It depends on how often the trigger fires. A very high-frequency trigger like enemy detection typically needs fifteen to thirty variants, while something occurring once or twice per playthrough can work with two. Perceived repetition is trigger frequency divided by pool size.

Why do game barks become annoying? Almost always because the pool is too small for how often the trigger fires, and often because the line was distinctive. Memorable phrasing has a short half-life - once a player has learned a line, it stops being characterisation and becomes a sound the game makes.

How long should a combat bark be? Under two seconds, ideally under one, with the key information in the first word. A player has roughly half a second to parse a line under combat conditions, so Grenade! works where a full warning sentence arrives too late to act on.

Should barks be funny? Sparingly, and only in large pools on infrequent triggers. Jokes have the shortest usable life of any line type because a punchline stops functioning the moment it’s predictable.

Where do barks fit in a game’s writing schedule? Usually later than they should. Because every bark is a recorded line, pools are frequently cut when voice budgets tighten - writing them in priority order means the most valuable lines survive the reduction.