Dialogue is a state and presentation problem

740. Lesson identity

Module

2.8 — Interactive narrative

Lesson

Dialogue is a state and presentation problem

Academic type

Systems

Order

Lesson 1 in the module

Estimated time

30–40 minutes, including practice

This lesson separates narrative content, available choices, presentation modes, and consequences. Its assessed output is a dialogue-state diagram plus a transition table or structured text equivalent that another developer—or an AI coding partner—could implement without guessing at missing rules.

741. Learning objective

After this lesson, you can produce a dialogue-state specification that coordinates narrative transitions and presentation modes while identifying conditions, consequences, destinations, and authoritative system ownership.

742. Why this matters

A conversation is not only a sequence of lines. It decides what content is active, what the player may select, which interaction mode is available, and what requests or events follow a selection. If those concerns are collapsed into one script or screen, a content edit can alter progression, an interface can accidentally become the source of world truth, or input can remain in the wrong mode after dialogue closes.

Separating the concerns makes the behavior traceable and gives implementation work explicit boundaries.

743. Prior knowledge

You should be able to identify system ownership and event boundaries from module 2.7. In particular, distinguish a system that requests or announces a change from the authoritative system that validates and records the resulting fact.

744. Four concerns, two coordinated tracks

Dialogue design must account for four concerns:

1. Narrative content: Authored lines, speaker, tone, and text associated with a dialogue state.
2. Dialogue choices: Selectable options and the conditions that make each option available or unavailable.
3. Presentation mode: The interface and input state, such as exploration, dialogue display, choice selection, or closing.
4. Consequences: Requests, events, or confirmed changes associated with a selected choice.

These concerns do not form a single sequence with presentation at the end. Model them as two coordinated tracks.

Track A: dialogue transition

current dialogue state
  -> determine valid choices
  -> player selects a valid choice
  -> request or emit the stated consequence
  -> follow the declared completion policy
  -> enter the next dialogue state, a failure state, or exit

Track B: presentation mode

exploration
  -> dialogue display
  -> choice selection
  -> response display or closing
  -> exploration

The tracks synchronize at explicit points:

Narrative state and presentation mode are coordinated but distinct. The same narrative state may be presented first as a line display and then as a choice-selection mode. Likewise, a closing presentation mode may remain active while the dialogue system finishes its exit transition.

745. Authority and consequence-completion policy

The dialogue system controls conversation transitions. It may emit an event or send a request, but the relevant domain system remains the authoritative source for durable world facts. The interface presents current state and collects input; it does not create world truth.

A diagram must state what completion means for each consequence-bearing transition. Choose one of these policies rather than implying that all consequences complete synchronously:

• Advance after emission: The dialogue advances once it emits a notification whose later handling does not affect the conversation path.
• Wait for authoritative confirmation: The dialogue remains pending until the receiving system confirms that the requested change was accepted.
• Follow explicit success and failure paths: The receiving system may accept or reject the request, and the dialogue names a destination for each result.

An event, a request, and a confirmed state change have different completion semantics. This lesson requires the policy to be named; Lesson 2 will define the detailed consequence contract and receiving systems.

746. Concrete example

Consider an invented conversation between the player and a dock worker named Mara. It is only a systems example and is not connected to a documented project event.

For this example, route_discussed uses wait for authoritative confirmation.

Dialogue-transition track

state: greeting
  content: Mara asks whether the player has a delivery question
  valid choices:
    ask_about_route
      condition: heard_rumor = true
      consequence: request route_discussed
      policy: wait for authoritative confirmation
      success destination: route_answer
      failure destination: greeting_with_feedback
    end_conversation
      condition: always
      consequence: none
      destination: exit

state: route_answer
  content: Mara gives a cautious answer
  valid choice:
    acknowledge
      condition: always
      consequence: emit conversation_completed
      policy: advance after emission
      destination: exit

Presentation-mode track

exploration
  -> dialogue display: greeting
  -> choice selection
  -> pending response while route_discussed is evaluated
  -> dialogue display: route_answer OR choice selection with failure feedback
  -> closing
  -> exploration

Transition-table equivalent

The diagram does not make the UI decide whether the route was discussed. The dialogue system sends the declared request, and the relevant authoritative system accepts or rejects it. The transition policy determines whether dialogue advances immediately, waits, or branches on failure.

747. Unavailable choices and accessible presentation

If heard_rumor is false, the route option may be hidden or disabled according to an explicit design decision. If it remains visible but disabled:

• its unavailable state must be perceivable without relying only on color;
• it must be clearly identified as unavailable;
• an explanation should be provided when that supports the intended experience;
• choice navigation must work without pointer-only interaction;
• unavailable controls must not disrupt a logical focus order; and
• when dialogue closes, focus and input must return predictably to an appropriate exploration target.

Every visual diagram must be accompanied by a transition table or structured text list containing the same states, conditions, consequences, destinations, presentation modes, and ownership information.

748. Common mistakes

Treating presentation as the final step

Presentation is active throughout entry, line display, choice selection, response, and closing. It is not a final layer applied only after a consequence.

Combining a line, screen, and world change

An instruction such as “show the route answer and unlock the mission” does not identify timing, authority, failure behavior, or the next input mode.

Assuming emission equals completion

Emitting a notification may permit immediate advancement. Sending a request that can fail may require confirmation and a failure path. The specification must say which policy applies.

Making the UI authoritative

A dialogue panel may display an option, but it should not become the authoritative source for mission, inventory, relationship, or progression facts.

749. Guided practice

Specify this scenario:

The player speaks to a quartermaster. The quartermaster offers a greeting. The player may ask about supplies or leave. The supplies option is available only when supply_token = true. Selecting it sends a record_supplies_discussed request. The relevant authoritative domain system may accept or reject that request. Acceptance moves the conversation to an answer state. Rejection returns to choice selection with feedback. The answer state offers a finish option that emits conversation_completed. Leaving or finishing closes dialogue and restores exploration.

Create both:

1. a two-track diagram showing dialogue transitions and presentation modes; and
2. a transition table or structured text equivalent.

Your specification must include:

• every path from entry through exit;
• content for each dialogue state;
• each dialogue choice and its condition;
• a destination for every possible result;
• each consequence and its completion policy;
• the authoritative system responsible for recording supplies_discussed;
• presentation modes before, during, and after dialogue;
• synchronization points between the two tracks; and
• predictable input and focus restoration on exit.

Decide whether the unavailable supplies option is hidden or disabled. Explain the decision in one sentence. If disabled, specify how its unavailable state is conveyed and how non-pointer navigation behaves.

750. Validation and assessed evidence

Submit the diagram and its transition table for the practical assessment attached to this lesson. Use this compact checklist before submission:

• All entry-to-exit paths are complete.
• Every choice has a condition and destination.
• Every consequence is named, including none where applicable.
• Every consequence-bearing transition states its completion policy.
• Dialogue states and presentation modes appear as separate coordinated tracks.
• Synchronization points are visible.
• The relevant domain system, not the UI, is identified as authoritative for the durable fact.
• The table or structured text provides a complete nonvisual equivalent.
• Unavailable-choice behavior and exit focus restoration are explicit.

751. Key takeaways

• Dialogue transitions and presentation modes are separate tracks that synchronize at declared points.
• Every choice needs an explicit condition, consequence, destination, and completion policy.
• Emitted events, requests, and confirmed writes do not have identical completion semantics.
• The dialogue system controls conversation flow; the relevant domain system is authoritative for durable world facts.
• A transition table makes a diagram inspectable without relying on its visual layout.

752. Next lesson

Next: 2.8 L2 — Design choices without hidden global writes. It will turn one choice into an explicit consequence contract that identifies emitted requests or events, authoritative writes, failure behavior, and receiving systems.

753. Knowledge check