The most common mistake when adding a typewriter effect to a dialogue system is to play a blip for every character that appears on screen. It sounds like the obvious approach. The text appears one character at a time, so the sound should play one character at a time too. On paper, the two are synchronized. In practice, the result is a buzzing stream of noise that obscures the text rather than supporting it, and the player turns the dialogue volume down within the first conversation.
The problem is arithmetic. A typewriter effect that reveals text at a comfortable reading pace shows around 30 to 60 characters per second. A blip that plays on every character is therefore playing 30 to 60 times per second, which is well above the rate at which the ear can distinguish individual events. The result is not a series of blips; it is a continuous tone that happens to have the pitch of a blip. This is why the typewriter blip needs a different design than any other blip in the game, and why the parameter ranges that work for a standard UI blip do not work here without modification.
The blip sound design guide covers the parameter ranges that produce a clean blip for a single trigger. This article is about what happens when that blip is triggered dozens of times per second, and what has to change about the design and the code to make it work as a continuous dialogue texture rather than a series of discrete events.
Why does the typewriter effect need a blip at all?
The typewriter effect is a visual technique that mimics the process of text being written rather than appearing whole. It serves two purposes in a dialogue system. The first is pacing. A line of text that appears instantly is read at whatever speed the player chooses. A line that reveals one character at a time imposes a reading rhythm on the player, which gives the dialogue a sense of voice and pace that a static text box cannot provide.
The second purpose is to signal that the text is still being produced. When the effect is running, the player knows the character is still speaking and the line is not finished. When the effect stops, the player knows the line is complete and can either advance or wait for the next one. This signaling is what makes the effect useful, and the blip sound reinforces it by giving the player an auditory confirmation that the text is still in motion.
The blip is not decoration on top of the effect. It is the audio half of a synchronized signal that tells the player the dialogue is running. Without it, the effect feels incomplete in the same way a game with muted footsteps feels incomplete. The visual is present, but the multi-channel reinforcement is missing.
How often should the typewriter blip actually play?
The rate at which the blip plays determines whether the effect works. Too fast and the blips merge into a continuous tone. Too slow and the effect feels disconnected from the text. The rate that works for most dialogue is one blip every two to four characters, which produces a blip rate of roughly 10 to 20 per second at normal reading speed.
| Text reveal speed | Blip frequency | Blips per second | Result |
|---|---|---|---|
| 20 chars/sec (slow) | Every 4 chars | 5 per sec | Sparse, deliberate |
| 30 chars/sec (normal) | Every 3 chars | 10 per sec | Balanced |
| 45 chars/sec (fast) | Every 2 chars | 22 per sec | Busy, energetic |
| 60 chars/sec (very fast) | Every 2 chars | 30 per sec | Approaching continuous |
| 60 chars/sec | Every char | 60 per sec | Continuous tone, unusable |
The choice between every-two, every-three, and every-four characters is partly aesthetic and partly tied to the text speed setting the player has chosen. A game that lets the player set the text speed cannot use a fixed every-N rule, because the blip rate would scale with the text speed. The pattern that works is a target blip rate that stays constant while the character skip count adjusts.
The target rate is usually between 8 and 15 blips per second. A game with a normal reading speed of 30 characters per second and a target rate of 10 blips per second uses an every-three-characters rule. A player who changes the text speed to 45 characters per second should have their blip rate adjusted to every-four or every-five characters, so the blip rate stays at 10 per second rather than rising to 15.
There is one exception to the every-N rule. Punctuation and whitespace characters should not trigger blips, even if the character count would normally trigger one. A blip that fires on a space sounds like a stutter, and a blip that fires on a period draws attention to the pause in a way that interrupts the rhythm. The character counter should increment on any character, but the blip should only fire when the current character is alphanumeric.
What makes a typewriter blip different from a standard UI blip?
A standard UI blip plays once when the player clicks a button. It has to be recognizable as a distinct event, because it is confirming that a specific action happened. A typewriter blip plays continuously for several seconds while the text reveals, and it does not have to be recognizable as a distinct event. The two sounds have different design priorities.
The three parameters that change between the two sounds are duration, pitch, and volume.
Duration. A UI blip is typically 50 to 80 milliseconds long. A typewriter blip should be shorter, in the 15 to 30 millisecond range. This is because the blip plays ten to fifteen times per second, and a 60-millisecond blip at that rate overlaps with the next one. The 20-millisecond window is short enough that the blips remain distinct at the target rate, and long enough that the pitch is still perceptible.
Pitch. A UI blip uses a pitch that carries emotional information: a higher blip for a confirmation, a lower one for a cancel. A typewriter blip uses a pitch that is neutral, because it plays so often that any emotional character becomes exhausting. The neutral range for a typewriter blip is 900 to 1300 Hz, which is slightly lower than the 1000 to 1800 Hz range that the Web Audio blip tutorial recommends for standalone UI blips. The lower pitch is easier to listen to over a long conversation.
Volume. A UI blip needs to be audible as a distinct event, so it can afford to sit slightly above the surrounding mix. A typewriter blip needs to sit beneath the mix, because the player is reading text and does not need the sound to compete for attention. The typical level for a typewriter blip is around -18 to -14 dB, which is five to ten decibels below where a UI blip would sit.
The waveform choice is different as well. A typewriter blip should use a sine or triangle wave, never a square wave. The square wave's harmonic content is what makes it feel punchy and digital at low rates, but at high rates those harmonics become fatiguing. A sine wave played fifteen times per second remains comfortable for much longer than a square wave at the same rate. The 8-bit sound design guide covers where the square wave is the right choice, and a typewriter effect at high speed is not one of those cases.
How do you keep the blip from becoming irritating over a long conversation?
A typewriter blip that sounds pleasant for the first ten seconds of dialogue becomes irritating by the second minute. The mechanism is the same one that makes any repeated sound fatiguing: the ear is very good at recognizing a pattern that it has heard recently, and a perfectly identical blip at a perfectly regular rate is the most recognizable pattern of all.
Three techniques reduce the fatigue, and they work best when combined.
Random pitch variation per blip. Each blip should have a slightly different pitch from the previous one. The variation range that works is ±3 to ±5 percent of the base pitch. A base blip at 1000 Hz varies between 950 and 1050 Hz across playbacks. The variation is small enough that the blip still reads as the same sound but large enough that the ear does not predict the next pitch. This is the same variation principle that the variation system guide covers for other sound categories.
Occasional skipped blips. Even with the every-N rule, one blip in every five or six should be skipped entirely. The gaps break the regularity of the pattern and make the sequence less predictable. The implementation is a random check on each blip: if the random value is below 0.15, skip. This produces an average of about one skipped blip in every seven, which is enough to disturb the pattern without making the effect feel sparse.
Slow drift across the conversation. The base pitch can drift up or down by a small amount over the course of a single dialogue line. A 20-percent drift over a five-second line produces a subtle movement that the ear reads as the character's voice changing rather than as repetition. The drift rate should be slow enough that the pitch change is imperceptible within any two consecutive blips but noticeable across the whole line.
The three techniques together produce a blip sequence that is statistically identical in pitch range and rate to the naive version, but is perceptually distinct. The difference is not in the parameters of any individual blip; it is in the distribution across the sequence.
How do you give each character their own blip voice?
A game with multiple speaking characters benefits from each one having a slightly different typewriter blip. The difference should be subtle enough that the player does not consciously identify it as a distinct sound, but consistent enough that the character's dialogue has a recognizable tone.
The three dimensions that produce per-character differences are the base pitch, the waveform, and the variation range.
| Character type | Base pitch | Waveform | Variation |
|---|---|---|---|
| Neutral narrator | 1000 Hz | sine | ±3% |
| Young / high-energy | 1400 Hz | triangle | ±5% |
| Older / authoritative | 750 Hz | sine | ±2% |
| Robotic / synthetic | 1100 Hz | square (25% duty) | 0% |
| Whispered / subtle | 1600 Hz | sine, low gain | ±4% |
The robotic voice is the one exception to the variation rule. A robot's blip sounds better without variation, because the lack of variation is itself a character trait. The square wave with a narrow duty cycle reinforces the mechanical character, and the fixed pitch reads as a system that does not have natural fluctuation. The 25-percent duty cycle mentioned in the table is the same parameter that gives retro blips their thin, nasal character in the JSFXR tutorial.
The pitch separation between characters matters as much as the pitch of any individual character. Two characters at 1000 Hz and 1050 Hz sound like the same character with a slight difference. Two characters at 750 Hz and 1400 Hz sound like two distinct voices. The rule of thumb is that adjacent characters should be separated by at least 200 Hz, and a character's blip should be at least 300 Hz away from the narrator's default.
What does the integration look like in code?
The implementation has three parts: a character counter that decides when to trigger a blip, a blip player that applies the per-character parameters, and a synchronization point that pauses the effect when the player advances the dialogue manually.
public class TypewriterEffect : MonoBehaviour
{
[SerializeField] private float charsPerSecond = 30f;
[SerializeField] private int targetBlipRate = 10;
[SerializeField] private AudioSource blipSource;
private int blipCounter = 0;
private int blipSkipInterval;
private float basePitch = 1000f;
private float pitchVariation = 0.04f;
void Start()
{
// Characters per blip = chars/sec divided by blips/sec
blipSkipInterval = Mathf.RoundToInt(
charsPerSecond / targetBlipRate
);
}
public void OnCharacterRevealed(char c)
{
// Only alphanumeric characters can trigger a blip
if (!char.IsLetterOrDigit(c)) return;
blipCounter++;
if (blipCounter < blipSkipInterval) return;
blipCounter = 0;
// 15% chance to skip this blip entirely
if (Random.value < 0.15f) return;
// Random pitch variation within the configured range
float jitter = (Random.value - 0.5f) * 2f * pitchVariation;
float pitch = basePitch * (1f + jitter);
blipSource.pitch = pitch / 1000f;
blipSource.Play();
}
public void SetCharacterPitch(float newBase)
{
basePitch = newBase;
}
}
The blipSkipInterval calculation happens
once at startup, which means the skip count is fixed for
the session. A game that lets the player adjust the text
speed at runtime should recalculate this value when the
speed changes. The OnCharacterRevealed
method is called from the dialogue system once per
character as the text is displayed.
The AudioSource.pitch value in Unity is a
multiplier, not a frequency. A pitch value of 1.0 plays
the clip at its original pitch; 1.1 plays it 10 percent
higher; 0.9 plays it 10 percent lower. The code above
converts the target frequency into this multiplier by
dividing by 1000, which assumes the base blip file was
rendered at 1000 Hz. If the blip file uses a different
base frequency, the divisor should match.
The 15-percent skip chance is applied after the character counter has already selected a candidate blip. This means the effective blip rate is 85 percent of the target, which is intentional. The target rate is the maximum, and the skips bring the average down to a comfortable level.
For games that use middleware instead of the engine's built-in audio, the same logic runs in the game code and posts an event to the middleware. The FMOD Unity integration guide and the Wwise first-week guide cover the event-based approach; the typewriter effect posts the same event on each blip, and the middleware applies the pitch and gain parameters through RTPCs.
How does the typewriter blip interact with a voice acting track?
Many games with a typewriter effect also have voice acting for the same dialogue lines. The blips and the voice are both producing audio for the same words, and the interaction between the two determines whether the effect feels polished or cluttered.
The rule that works is: if the line has voice acting, the typewriter blip plays at reduced volume or does not play at all. A voice that says the words while a stream of blips plays underneath it produces two competing audio tracks for the same content. The voice is the primary signal; the blips are a secondary confirmation that the text is being revealed.
The specific implementation is a volume duck on the blip bus when the voice track is active. The ducking and sidechain compression guide covers the general technique; the typewriter case is a specific application where the duck depth is large (the blips reduce by 12 to 18 dB) and the release is slow (over two to three seconds, so the blips do not come back at full volume between voice lines).
The alternative approach is to disable the blips entirely when the line is voiced. This produces a cleaner mix but loses the visual-audio synchronization that the blips provide. Many games use a compromise: the blips play at 30 percent volume during voiced lines and at full volume during unvoiced lines, so the effect is present in both cases but is more prominent when there is no voice competing with it.
The choice between the three approaches — full blips, reduced blips, no blips during voiced lines — depends on the game's overall audio design and the density of the voice acting. A game with sparse voice acting benefits from keeping the blips at full volume, because the voice is not often present to compete. A game where every line is voiced benefits from disabling the blips, because the voice is always the primary signal and the blips are redundant.
What does a working typewriter effect actually sound like?
The test for a typewriter blip is not whether it sounds good in isolation. It is whether it sounds good after the player has listened to three minutes of dialogue without thinking about it. This is a different test than the one used for UI blips, because the typewriter blip is not evaluated as a series of distinct events; it is evaluated as a continuous texture.
The practical test is to play a dialogue scene with the text speed set to the game's default and listen to the blips for the entire scene. If at any point the player becomes consciously aware of the blips as a repeating pattern, the effect is not working. If the blips feel like a continuous accompaniment that the player only notices when it stops, the effect is working.
The second test is to listen with the volume turned down to the level the player would actually use. A typewriter blip that sounds fine at full volume can be inaudible at normal play volume, which means the player never hears the effect at all. The blip should be audible at the volume the player typically uses for dialogue, not just at the maximum.
The third test is to disable the blips entirely and play the same scene again. If the scene feels complete without them, the blips are not adding value. If the scene feels like something is missing, the blips are doing their job. This is a useful test because it forces the designer to consider whether the effect is actually contributing to the player experience, or whether it is present only because the design document included it.
A typewriter blip is a small detail in the overall audio of a game. But it plays every time the player reads a line of dialogue, which means it accumulates into one of the most frequently heard sounds in the entire game. The design effort that goes into the individual blip is small, but the time savings in the eventual playtest cycle is significant. A blip that survives a long conversation without fatigue is a blip that the team will not have to redo in the last month of production, when every other sound in the game is also being tuned.
Generate Blip Variations for a Typewriter Effect
Open the SfxMaker blip generator and create the base blip files for your dialogue system. Generate one blip per speaking character at the pitch and waveform ranges listed in this article, then apply the per-blip pitch variation in the game code rather than baking it into the files.
Open Blip Sound Generator →