Two new writers will soon be joining Failbetter, so we’ve taken the opportunity to update and formalise our internal writing guidelines. We felt they might be useful for those with an interest in narrative design, so are sharing them in a short series of blogs.

Below are our internal guidelines for pitching and creating content. Future blogs will give our guidance for content design, and then for writing for Fallen London. We've pruned any bits that made no sense out of context or that linked to internal documentation. Otherwise, this is exactly the same guidance we give to internal writers.

Slack is a team communication platform we use at Failbetter. It eases the burden of internal email and lets us archive discussion and documentation. The content team use it to bounce ideas around while writing.

Writer Guidelines for Fallen London

Stage 1: Pitch

All new content begins as a pitch, a succinct summary of the scope and direction of the piece. Submit it as a Slack post to the Content channel. A pitch should:

give the business case for the content. How does it improve player experience or generate revenue?
outline the content’s theme, story, mechanics, and rewards
include an estimate of size (in storylets or branches)
set deadlines for the midflight, QA and launch stages
indicate what new art will be required (keep this to a minimum). Talk to the art department about deadlines and briefly describe a key scene or image that we can use for marketing materials
flag any dependencies or concerns. Does it require upcoming new tech be completed? Is any of the subject matter sensitive?

Stage 2: Midflight Check

This is our opportunity to make course-corrections before anything’s set in stone. When you hand content over for a midflight check, it should consist of a skeletal version of the entire content in the CMS, including:

any new qualities, with comprehensive quality notes laying out the structure
all storylets, branches, quality requirements and quality changes implemented (so we could play through the structure, even though there’s no content)
story beats noted in that skeleton - just enough to make the fiction clear

All we want at this stage is to see how the story is paced, whether it’s too grindy, and if there are any potential issues. We may ask for an extra midflight check after some prose is completed, to make sure we’re on the same page.

Stage 3: Write the content

Make any changes prompted by the midflight and write the prose.

As you write, raise issues for discussion on the Content channel in Slack. Talk early, talk often, share work, ask for help. Nothing untangles a creative knot as quickly as a conversation with your peers.
As you create new characters, places and lore, add them to the appropriate tab of the content spreadsheet

Stage 4: QA

There are three types of QA: Content, Mechanical, and Design

Content QA will copy-edit your work and give you notes via a Google doc so you can make changes.
Design QA will make sure your piece fits properly into the Fallen London economy and provides a good user-experience.
Mechanical QA will test for bugs and usability.

Pre-Handover Checks

Before handing the content over to QA, you must have played through it yourself, in-game, from beginning to end. You needn’t have tested every permutation, but this run-through will flush out errors that would have required back-and-forth with QA.

Revisit and revise your quality notes to reflect any changes that you have made to the structure or story since the midflight check.

Review Document

A review document summarises the content for QA. It should provide a clear flow for the story, provide hyperlinks to each storylet and quality, and raise anything you want to draw QA’s attention to. Submit it as a Slack post in the Content channel.

Use this opportunity to go back and make sure your quality notes are up to date. The review document should be based on your quality notes, so the better they are, the easier the review document will be.

Comms Brief

While QA are working, write a brief promotional blurb for the content. This will be used as a forum post announcing the content to the community, and Communications will base social media announcements on it. Here’s an example of an announcement post.

The blurb should include:

an evocative summary of the content
its Fate cost (or say that it’s free if there’s no cost)
who it’s suitable for: new or experienced players? Characters with a certain quality?
how a player can find the content; what will they need to play it?

QA Completion

As QA tackle the content, they’ll talk to you about any issues they find. The QA process is collaborative and takes time - assume it’ll take up about a third as much time as the content took to write.

Writers, you’ll be taking your turn on QA, too.

Stage 4: Review The editor of last resort (usually Alexis) will perform a final review of the content to make sure it’s ready to go live. He’ll be looking for consistency, tone, and clarity.

Stage 5: Launch

Confirm with Comms and Chief Narrative Officer when launch will happen.
Remove the content locks and put the content live.
Announce the content on the forums, and let it percolate for a few hours
Monitor the announcement thread and Zendesk, watching for any bugs that slipped through the net.
Let Comms know when it’s safe to do a more general announcement about the new content.
Post the final, updated review notes for the content into the #pandect channel in Slack, which is a record of completed content.

Next: Designing for Fallen London