Here's a thoughtful thread on how pauses between successive lines in scripted dialog can throw off pacing and wreck a performance. So let me share some quick thoughts on how to implement systems without this problem.

https://twitter.com/MikkiHEL/status/1342664226104610828

Mikko mentions that some dialog systems hardcode a consistent delay (say 600ms) between lines. Often this isn't deliberate, it's a consequence of the steps between one line ending and the next beginning being spread across frames, due to scripts passing events. eg:

Frame 1: audio thread sends "line ended" event to script system
Frame 2: script system gets event, looks up next line to play, queues another event on character X
Frame 3: X processes event, queues audio to play
Frame 4: Audio thread handles queued trigger
Frame 5: Sound plays

The above flows naturally from wanting to decouple components, but this is one place you *do* want tight coupling so you can make things happen synchronously. Do this in code rather than script, or at least bake it all into one synchronous script event.

Often, the individual audio clips will have some silence at the beginning before the voice starts. Make sure this is an absolutely consistent length. You could eliminate it altogether too, but sometimes a 250ms lead-in can be useful because...

... most audio systems have a latency on streaming audio. So your dialog system needs to be able to look ahead to know which is the *next* line to play, so you can haul it into memory by playing for a couple frames then pausing it. Consistent lead-in lets you do this in advance.

This also means you'll need to store metadata about dialog - in particular, lines' duration. Some middleware can't tell you how long a sound will be at runtime; you need to work that out in a builder and store it somewhere of your own devising.

If you make dialog sequences their own kind of asset with their own authoring tool (or just use Excel), you can put "this line follows that one" in there along with the delay that *ought* to be between them, making iteration a lot easier. https://twitter.com/MikkiHEL/status/1342668038898921478?s=20

In general, dialog needs to be systemic. Often it's done as designer script, like a massive blueprint, and that rapidly becomes cumbersome. A single system driving all characters, rather than individual components lets you handle (eg) interruptions well. https://twitter.com/MikkiHEL/status/1342665678038454273?s=20

I did a GDC talk a while ago on a simple but flexible way to handle contextual and branching dialog:


Relevant here: each response had a 'delay' parameter that let the writers pace the conversation. It could also be negative, for interruptions etc.