A player who finishes your twelve-hour shooter will hear your reload callout more times than any line in your main story. They will hear a guard's "must have been the wind" more often than your protagonist's name. These lines — barks — are the most-heard writing in your game, and on most small teams they are written last, in a rush, by whoever has an afternoon free.
That is backwards. Barks are the cheapest narrative system you can build: no branching, no camera work, no scene setup. A few hundred short lines carry telegraphing, characterization and world texture across your entire runtime. They are also the fastest way to make a good game feel cheap, because repetition exposes every weakness in a line. Here is how to design the system before you write a word of it.
What a bark actually is
A bark is a short line triggered by game state, spoken without taking control from the player. Left 4 Dead's survivors shouting "Reloading!" are barks. So is a Dishonored guard's idle muttering, or an XCOM soldier's confirmation on a move order. The defining traits:
- Non-blocking. The game does not stop. No input is required.
- State-triggered. It fires on a condition, not on a node in a conversation.
- Interruptible. It can be cut off, dropped, or replaced by something more urgent.
Barks do three jobs at once, and it's worth knowing which one each line is for:
- Information. Telegraphing an attack, confirming an order, signalling a state the player can't see.
- Characterization. Who this person is, in two seconds, two hundred times.
- Texture. Proof the world runs when the player isn't looking.
Information barks are gameplay features that happen to be voiced. Treat them like a HUD element: if the grenade warning doesn't land every time, that's a bug, not a writing problem.
Start from triggers, not lines
The common failure is to open a document and start writing funny guard dialogue. Instead, build the trigger table first. One row per condition the game can detect, with the job, the priority and how many variants it needs.
| Trigger | Speaker | Job | Priority | Variants | Cooldown |
|---|---|---|---|---|---|
| Enemy throws grenade | Thrower | Information | 1 (critical) | 4 | none |
| Player spotted, first time | Nearest guard | Information | 1 | 6 | 10s |
| Ally reloading | Ally | Information | 2 | 5 | 8s |
| Search lost player | Searcher | Information | 2 | 8 | 20s |
| Ally downed | Any ally | Characterization | 2 | 6 | none |
| Enemy killed by player | Nearest witness | Characterization | 3 | 10 | 15s |
| Idle patrol, no threat | Patroller | Texture | 4 | 14 | 90s |
| Weather change | Any NPC | Texture | 4 | 6 | 300s |
Two things fall out of the table immediately. First, variant counts are not uniform: a grenade warning needs four lines because the player hears it rarely and must understand it instantly, while idle patrol chatter needs fourteen because the player will stand in a corridor listening to it. Second, the table gives you your budget before you commission any audio.
Keep this table where the whole team reads it, not in a writer's private file. Bark banks belong next to your conversation trees — in GameDesignerX's dialogue module or anywhere else — so localization exports every string in one pass instead of finding 300 orphaned audio lines three weeks before cert.
The three rules that stop repetition
1. Priority tiers, with hard pre-emption
Give every bark a tier from 1 to 4. Tier 1 interrupts anything; tier 4 is dropped the moment anything else wants the channel. The rule: a new bark plays only if its tier is lower-numbered than what's currently playing, or nothing is. A guard's joke about his pension never steps on a grenade warning.
2. Cooldowns at three scopes
- Global floor: no two barks within 1.5–2 seconds, regardless of source. Without this, a four-enemy fight becomes noise.
- Per-trigger cooldown: the value in your table. Prevents a single event spamming on re-entry.
- Per-line lockout: once a specific line plays, lock that exact line for 90–180 seconds of play time, even if the trigger fires again.
The per-line lockout is the one teams skip, and it's the one that matters most. It is what stops the same five words landing twice in ten seconds.
3. Shuffle bags, never random()
Plain random selection from six variants repeats the same line back-to-back one time in six. Instead shuffle the bag, play through it in order, reshuffle when empty, and never let the last line of the old bag open the new one. Players hear the difference instantly, though both methods are "random".
Budget before you book a booth
Do the multiplication early. The table above holds 59 variants across eight triggers. Multiply by the number of distinct voices that need their own set:
| Speakers | Lines | At ~2.5s each | Localized ×6 |
|---|---|---|---|
| 1 | 59 | ~2.5 min | 354 lines |
| 4 | 236 | ~10 min | 1,416 lines |
| 9 | 531 | ~22 min | 3,186 lines |
Nine enemy types with individual voices is a different project from four. Two ways out: share a bank across speakers and vary only the delivery, or go text-only with a distinct typographic treatment. Both are legitimate; choosing by accident is not.
Writing lines that survive 200 plays
- Eight words or fewer. Roughly two seconds. Long barks get interrupted, and the payload lands in the half nobody heard.
- Front-load the payload. "Grenade — move!" beats "You might want to get out of the way, there's a grenade."
- Subtext, not punchlines. A joke dies on the third hearing. A line that implies something about the speaker's life survives re-hearing.
- No story state unless gated. A guard who mentions the missing prince is wrong in every chapter but one. Either gate the bank by chapter or write around it.
- Vocabulary ladders per faction. Conscripts say "boss", officers say "sir", cultists say nothing recognisable. The player should identify the speaker type with their eyes closed.
- Write the fallback. Every information trigger needs one neutral line that is always valid. That's what plays when the gated banks are empty.
The speaker queue and overlap
One voice at a time is the safe default for a small team. Build a queue with a maximum age — 1 to 2 seconds — and discard stale entries rather than playing them late. A "reloading" callout that arrives after the reload finished is worse than silence: it teaches the player that callouts can't be trusted.
In co-op, dedupe by event rather than by listener — four players should hear one callout, not four. Subtitle barks separately from cinematic dialogue with the speaker name shown; it's a cheap accessibility win that also makes your playtests readable.
Instrument it, then fix the top of the list
Log one event per bark: line id, trigger, play time, and whether it was pre-empted. After a two-hour session you have a ranked list of your most-played lines. The top five need more variants; anything that never fired has a broken trigger. Pre-emption counts are how you find information barks being eaten by texture chatter — near-invisible in play, obvious in data. Park those session logs next to the observations from the same build, in the playtesting module or wherever your notes live.
Pre-ship checklist
- Every trigger has a tier, a cooldown and a fallback line
- Per-line lockout implemented and tuned above 90 seconds
- Selection uses shuffle bags with no bag-boundary repeats
- Tier 1 barks pre-empt all lower tiers, verified in a crowded fight
- Queue drops entries older than 2 seconds
- All lines subtitled with speaker attribution
- Music and ambience duck under tier 1 and 2 barks
- Line count and localization multiplier signed off against budget
- Story-gated banks checked for each chapter
- Top-10 most-played lines from the last playtest have four or more variants
Barks are the only writing in your game that competes with itself. Design the system that serves them, and 300 short lines will do the work of a cutscene you'll never have time to build.