Dialogue Box and Text Display UI Systems

Dialogue Box Anatomy

The standard dialogue box has four components: the speaker name, the character portrait, the text body, and the advance indicator. The speaker name appears at the top of the box, typically in a smaller panel or tab that visually connects to the main box. The character portrait, a small illustration of the speaking character, appears to the left or right of the text. The text body fills the main area with the current line of dialogue. The advance indicator, usually a small bouncing arrow or flashing icon at the bottom-right, signals that the text is complete and the player can proceed.

Box sizing depends on the game's text volume. Games with short, snappy dialogue (1 to 2 sentences per box) can use narrow, bottom-anchored boxes that cover 15 to 20% of the screen height. Games with longer narrative passages need taller boxes or scrollable text areas. The box should never cover more than 30 to 35% of the screen vertically, because the player needs to see the game world behind the dialogue to maintain spatial context.

Position conventions place dialogue boxes at the bottom of the screen. This convention comes from console RPGs and visual novels, where the bottom position leaves the characters and environment visible in the upper portion. Some games use speech bubbles positioned near the speaking character instead, which works well for games with visible characters in the scene. Top-of-screen dialogue boxes are less common but can work for narrator text or system messages that are distinct from character speech.

The visual style of the dialogue box should match the game's overall aesthetic. A fantasy RPG might use a wooden-framed, parchment-textured box. A sci-fi game might use a holographic panel with glowing edges. A minimalist puzzle game might use a simple semi-transparent rectangle. Whatever the style, the box must maintain text readability through high contrast between the text color and the box background, regardless of what the game world shows behind it.

The Typewriter Effect

The typewriter effect displays text one character at a time, simulating the text being typed or spoken in real time. This is the standard text delivery method in game dialogue because it controls reading pace, creates dramatic timing, and makes the dialogue feel more like a conversation than a text dump. Almost every narrative game uses this effect, and players expect it.

Character display speed should be adjustable. The default speed of 30 to 50 milliseconds per character works for most dialogue. Punctuation marks (periods, commas, exclamation points) should insert longer pauses, typically 150 to 300ms, to create natural speech rhythm. Ellipses should have even longer pauses between dots to create a dramatic hesitation effect. These timing variations transform a mechanical character-by-character display into something that feels like natural speech pacing.

Players must be able to skip the typewriter effect. The standard behavior is: clicking or pressing a key during typewriter playback instantly displays the complete text. Clicking or pressing again after the text is fully displayed advances to the next dialogue line. This two-stage interaction (fast-display, then advance) lets impatient players read at their own pace while preserving the typewriter effect for players who enjoy it.

Implementation in HTML/CSS uses a JavaScript interval that adds one character at a time to the element's textContent. For styled text (bold, italic, colored words within dialogue), the implementation must track character position within the raw text while respecting HTML tag boundaries. Adding characters inside an HTML element requires building the visible string with proper tag closure at each step, which is more complex than simple character-by-character appending.

Canvas-based typewriter effects measure and draw text directly. The implementation maintains a character count that increments each frame (or on a timer), and the draw call renders only the substring up to that count. Canvas text rendering handles this naturally through the text parameter of fillText. Font styling changes within the dialogue (bold words, colored names) require splitting the text into styled segments and drawing each segment separately with the appropriate font settings.

Character Portraits and Speaker Identification

When multiple characters participate in a conversation, the player must immediately know who is speaking each line. Character portraits are the most effective speaker identification method because they provide visual recognition faster than reading a name label. A 64 to 128 pixel portrait showing the character's face, positioned to the left of the dialogue text, lets the player identify the speaker with a peripheral glance.

Portrait variations add emotional context. A character might have 4 to 8 portrait expressions: neutral, happy, angry, sad, surprised, thinking, and scared. Switching the portrait to match the dialogue's emotional tone reinforces the text's meaning and creates a more engaging conversation experience. A character saying "That was incredible!" with an excited portrait conveys more than the text alone. Storing portraits as a sprite sheet or a set of named image files allows switching expressions by changing the displayed image region.

The speaker name label provides redundancy for players who cannot distinguish characters by portrait alone. It also identifies characters the player has not met before, whose portraits would be unfamiliar. The name label typically appears above the dialogue box in a small tab or banner, styled consistently with the box design. Color-coding names by character (blue for the protagonist, red for antagonists, green for allies) adds another quick-identification layer.

For games with many characters or player-named characters, dynamic name colors help track conversations. Assigning each character a consistent color throughout the game creates a visual shorthand. When the player sees text in blue, they know it is the protagonist without reading the name. This is especially useful in group conversations with rapid back-and-forth exchanges.

Speech bubbles are an alternative to portrait-based dialogue boxes. Instead of a fixed box at the screen bottom, speech bubbles appear near the speaking character in the game world. This approach works well for games with visible characters where the spatial relationship between speakers matters. Implementation requires converting world-space character positions to screen-space coordinates and positioning the bubble DOM element or canvas drawing at those coordinates, with logic to prevent bubbles from overlapping or extending off-screen.

Branching Choices and Player Decisions

Branching dialogue presents the player with two or more response options that affect the conversation's direction. The choice UI must present options clearly, let the player read and consider each option, and accept the selection without ambiguity. Most games present choices as a vertical list of 2 to 4 options, each occupying its own button or highlighted row.

Choice presentation timing matters. The choices should appear after the preceding NPC dialogue has been fully displayed (after the typewriter effect completes), giving the player time to read the NPC's statement before choosing a response. Presenting choices simultaneously with the NPC's dialogue creates a split-attention problem where the player is trying to read and choose at the same time.

Choice option design requires careful text work. Each option should be short (one sentence, ideally under 15 words) and clearly communicate the tone and intent of the response. "[Friendly] Sure, I would love to help." versus "[Suspicious] What are you not telling me?" versus "[Refuse] That is not my problem." Tone tags in brackets help the player predict the character's delivery without reading the full response text. Some games show only the tone tag and let the full dialogue play after selection, which speeds up the interaction but removes the player's ability to preview exact wording.

Mouse and touch interaction with choices should highlight the option the player is hovering over or touching, using a color change, background highlight, or scale increase. Keyboard and gamepad interaction should allow arrow keys to move a selection indicator between options and Enter or A-button to confirm. The currently selected option should be visually distinct from unselected options, and a confirm action on the selected option should provide feedback (a brief flash or press animation) before transitioning to the next dialogue line.

Choice consequences can be communicated through the UI. Some games show a small icon next to choices that will have significant consequences, like a lock icon for choices that close off other options, a heart icon for relationship-affecting choices, or a skill icon for choices that require a particular attribute. These consequence indicators help the player make informed decisions without spoiling specific outcomes.

Text Formatting and Readability

Dialogue text readability is the most basic requirement and the one most often compromised by visual design ambitions. A beautifully styled dialogue box with unreadable text fails at its primary purpose. Several specific factors determine text readability in game dialogue.

Font choice matters more in dialogue than anywhere else in the game UI. The dialogue font is read in sustained passages, unlike HUD numbers that are glanced at. Serif fonts (like Georgia) provide better readability for long text passages. Sans-serif fonts (like the system font stack or a web-safe font) provide better readability at small sizes and on low-resolution displays. For web games, using the system font stack (system-ui, -apple-system, sans-serif) ensures fast rendering without font file downloads and optimal readability on each platform.

Font size for dialogue text should be at least 16px on desktop and 18px on mobile. Below these sizes, sustained reading becomes fatiguing. Line height should be 1.4 to 1.6 times the font size to create comfortable vertical spacing between lines. Line length should not exceed 60 to 70 characters per line, because longer lines cause the reader's eye to lose its place when returning to the start of the next line. The dialogue box width should be set to enforce this line length rather than stretching to fill the screen.

Text color and background contrast must meet WCAG AA standards at minimum: a contrast ratio of at least 4.5:1 for normal text. White text on a dark, semi-transparent background is the safest choice because it works against any game world backdrop. Dark text on a light background also works but requires the background to be opaque enough to maintain contrast when bright game content is visible behind it. Avoid colored text for body dialogue (save colors for character names and emphasis) because colored text against a colored background often fails contrast requirements.

Inline text effects, bold words for emphasis, colored words for item names or keywords, and italic text for internal thoughts, add visual variety to dialogue without disrupting readability. Implement these as inline HTML elements (<strong>, <em>, <span class="item-name">) so the browser handles their rendering within the text flow. For canvas-rendered text, inline styling requires splitting the text string at style boundaries and rendering each segment with the appropriate font settings, advancing the x-position after each segment.

Dialogue Data Architecture

Dialogue content should live in data files, not in the game's source code. Separating dialogue from code enables non-programmers to write and edit dialogue, supports localization into other languages, and makes it easy to modify conversations without touching game logic. The most common data formats for dialogue are JSON, YAML, and specialized dialogue tools like Yarn Spinner or Twine.

A minimal dialogue data structure stores each conversation as a sequence of nodes. Each node contains: the speaker identifier, the dialogue text, optional portrait expression, optional audio file reference, and either a pointer to the next node or a set of branching choices. Each choice contains the display text and the identifier of the node it leads to. This tree structure supports linear conversations, branching paths, and loops (where a choice can point back to an earlier node).

Dialogue variables enable dynamic text. Inserting the player's name, referencing a quest item, or displaying a numeric value within dialogue text requires a variable substitution system. Store variables in a game state object and replace placeholders (like {playerName} or {goldAmount}) with actual values when rendering each line. This system also supports conditional dialogue, showing different text based on game state, by including condition checks in the dialogue data that evaluate against the variable store.

For web games, JSON is the natural choice for dialogue data because JavaScript parses it natively. A single JSON file per conversation, or a single file containing all conversations indexed by ID, loads efficiently and integrates with any web game framework. Larger narrative games might use a dialogue editing tool that exports to JSON, giving writers a visual interface while maintaining a code-friendly data format.