# FOnline: Dead Desert — Storyteller Guide

Your team can write NPC conversations and plan quests and jobs at the main website’s **/storyteller/** address. Open it in your browser; you don’t need access to the game server. The standalone kit still works offline through **Workshop.html**.

The workshop lets you write branching dialogue, click through a conversation, save an editable draft, and export a readable handoff. It checks missing pages, broken links, unreachable pages, and conversations with no exit. Once a developer assigns a dialogue ID, it can also export the game's dialogue files.

**Dialogue is supported; a quest's gameplay still needs server scripting.** Writing “give the player a reward” in the workshop records an instruction for the developer. It does not award items, start a mission, or change the live server. The preview follows text choices, not eligibility conditions. Use-trained skills, faction checks, combat, inventory and rewards are not simulated.

## What to use

| You want to add… | Choose… | How it behaves |
| --- | --- | --- |
| A person with rumors, background or conversation | NPC conversation | Dialogue branches; no mission required |
| A story with a beginning and ending | One-time quest | Proposed completion once per character |
| Work a player can do again | Repeatable job | Proposed repeat after a real-world cooldown |

These are team conventions. The existing server calls the medic's repeatable work a “mission”; the name alone does not determine whether it repeats. We are providing job-writing tools here, not adding new jobs to the live world.

## 1. Make an NPC conversation

1. Open the website’s **/storyteller/** page (or **Workshop.html** in the offline kit). The Mara conversation is already loaded as an example.
2. Give your draft a file name, such as `story_watchkeeper`. Use lowercase letters, numbers and underscores. Each draft needs its own name.
3. Fill in the NPC's name and observation description. Describe what a player can see, rather than secret information.
4. Leave **Dialogue ID** blank. A developer assigns an unused ID when the draft is ready for integration.
5. Write the opening NPC text on the first conversation page. Keep it to a few sentences.
6. Add the player's replies. For each reply, enter another page name in **Next page**, or enter `END` to close the conversation.
7. Click **Add a conversation page** for each new branch. Give the page a unique name, such as `rumors`, and write the NPC's response there.
8. Connect each new page to a reply. Every page must be reachable from the opening, and every branch must have a route to `END`.
9. Click **Check draft and start preview**. Click every reply, including backtracking and goodbye choices. Correct any errors shown at the bottom.
10. Click **Save draft JSON**, then **Export readable handoff**. Send both files to the developer. Reopen the JSON with **Open a saved draft** when you want to edit it again.

Example conversation:

```text
welcome
Mara: Keep your eyes on the road. Most trouble reaches the Hub on two feet.
  “What have you seen out there?” → rumors
  “I will keep that in mind.” → END

rumors
Mara: A caravan missed its arrival yesterday. Could be a broken wheel.
  “Where was it coming from?” → road
  “Back to my other questions.” → welcome

road
Mara: The western road. Ask around before you go looking.
  “Thanks for the warning.” → END
```

Page names are labels for your team. Players see the NPC text and player replies.

## 2. Make a one-time quest

1. Save any current draft, then click **Quest example**. It is a proposal, not an existing quest.
2. Change the file name and title. Pick a specific story: who needs help, why it matters, and what the player discovers.
3. Fill in **Who offers it?** and **Where does it happen?** Name the NPC and map. If the place does not exist yet, say that. You do not need to guess map coordinates.
4. Write the acceptance requirements. For example: “Alive, near Mara, has not completed this quest, and does not already have it active.” State any earlier quest, faction or skill requirements.
5. Write the objectives, one per line. Each line should tell the player what to do next and where to go. These become the proposed HUD and Pip-Boy reminders.
6. Explain how completion is proven. Choose an actual event: speaking to a named NPC, investigating a marked object, visiting a location, handing over items, or defeating a specific target. Specify whether collected items are physical inventory or personal mission progress.
7. Propose rewards with exact quantities. For example: “50 NCR dollars, 100 XP.” A developer confirms item prototypes and checks the economy before release.
8. Explain recovery: what happens if the player disconnects, passes out, loses an item, leaves a party, or cannot carry the reward. Default to retaining earned progress and allowing a later hand-in.
9. Write the dialogue: offer, acceptance, in-progress response, completion and after-completion response. Put visibility conditions and gameplay actions in the reply's **developer note**, such as “Only show when ready to hand in; award once.”
10. Preview the conversation and export the JSON and readable handoff. The developer connects the steps, saved state, conditions and rewards. Test the playable version before release.

An example objective sequence:

```text
Speak to Mara at the Hub entrance about the missing caravan.
Investigate the abandoned caravan marker in the Outskirts.
Return to Mara at the Hub entrance with what you learned.
```

Avoid vague reminders like “Continue the investigation.” Name the next person or place. Keep reminders under 250 characters; shorter is easier to read on the HUD.

## 3. Make a repeatable job

1. Save any current draft, then click **Job example**.
2. Fill in the same mission fields as a quest, keeping the task short and repeatable.
3. Set **Repeat-job cooldown** in real-world minutes. For example, `60` means one hour. The proposed cooldown starts after successful payment, not after accepting the job.
4. Specify who can take it: one active copy per character, cooldown finished, alive and near the giver. Add other requirements only when needed.
5. Decide whether the work uses shared items or personal progress. If it uses ordinary items, state exactly which items are consumed and whether previously collected items count.
6. Write dialogue for accepting, checking progress, handing in and waiting for the next job. Record the conditions and actions in developer notes.
7. State what resets after payment. Completed work must not be paid twice. Interrupted work and a failed reward delivery should retain progress.
8. Save, preview, export and hand off, then test the implemented version.

Example job proposal:

```text
Name: Supplies for the Road
Giver: Mara at the Hub entrance
Task: Hand over two ordinary water flasks.
Items: Existing flasks count; consume exactly two on successful payment.
Reward: Proposed 50 NCR dollars and 100 XP; needs economy review.
Repeat: 60 real-world minutes after payment.
Recovery: Keep the job and supplies if payment cannot be delivered.
```

A line in dialogue that says “I have finished” is a request to the server. It is not proof that the player completed the work.

## 4. Hand your work to the developer

Send the **draft JSON** and **readable handoff** together. Include any map screenshot or placement notes you have. Tell the developer whether this is a new NPC or a change to an existing one.

For new NPCs, also describe appearance, approximate placement, whether they stand still, and whether they offer barter. Choose an existing appearance first so missing animations do not hold up the story.

After receiving an assigned dialogue ID, enter it in the workshop and export the game files. The three downloads are a `.fodlg` conversation, a `dialogs.lst` fragment and an `FODLG.MSG` fragment. They are draft inputs for integration. Exporting does not install anything. Browser download settings may require allowing multiple files. If a download is blocked, expand the copyable export beneath the buttons, copy its text, and save it with the displayed file name.

Developer notes are included in the handoff, but are deliberately not converted into executable scripts. A quest dialogue must not be released until those actions and conditions have been connected.

## 5. Test the playable version together

Use a disposable test character. Check these once the developer has installed the draft on a test copy:

- Speak appears in the NPC interaction menu; every branch and goodbye works.
- Acceptance updates the HUD and Pip-Boy with the next useful instruction.
- Wrong items, the wrong target or an unfinished task cannot produce a reward.
- Progress survives logout and server restart.
- Passing out does not make the story impossible to finish.
- Handing in twice cannot award twice; a full inventory retains completed work.
- Another player cannot finish or erase your personal progress accidentally.
- A one-time quest stays completed; a job repeats only after its cooldown.

## Writing tips

- Give each NPC a motive, a distinctive attitude and something useful to say.
- Keep most speeches to two or three sentences; split longer explanations into questions.
- Offer a polite exit. Let players decline without trapping the conversation.
- Use visible landmarks in directions. Have a developer confirm the route before release.
- Agree on item names and quantities before polishing hand-in dialogue.
- Keep drafts in your own folders or use different file names to avoid overwriting another writer's work.
- Save often. This workshop has no automatic persistence; the downloaded JSON is your editable copy.

For the game's actual file locations and scripting conventions, see **DEVELOPER-HANDOFF.md**. Storytellers can work entirely in the workshop and leave those integration steps to the developer.