Contributing Workflow

You do not need git, GitHub, or a development environment. Fragments are written in a plain text file and submitted through Discord, where a bot checks the format and does the repository work for you.

The route

1. Learn the format. Your First Fragment goes from an empty file to a playable scene. It takes about twenty minutes.
2. Register. On the Discord, /register asks you to pick a handle and to accept the Contributor Agreement. Your handle is permanent and public, because it is what credits you, so choose one you are happy to be known by.
3. Draft. Write your .frag in whatever editor you like. Post it in the writing room while it is rough; that is what the room is for.
4. Submit. /submit on the Discord with your .frag attached. The bot opens a private thread, checks the file there, and tells you whether it builds, usually within a minute. No part of this is public.
5. Revise. Post a corrected file into the same thread and it is checked again, as often as you like; most first submissions fail once, and that is the tooling working rather than a verdict. Once it builds, a person reads it and either accepts it, asks for specific changes, or declines with the reason.
6. Ship. A maintainer adds the fragment to the game and records the credit. You are credited in the ledger and in the game.

The format check is about format, not quality. Passing it means your file works, not that the fragment is good. The people are the second half.

Your handle

You claim a handle once, when you register, and it is permanent. It is the key that ties you to your work in the ledger and the credits, which is exactly why it cannot be quietly changed later. A display name can change; a handle cannot.

You never type it into a fragment. Authorship is recorded from your registration when a submission is accepted, so there is nothing to keep consistent and nothing to typo.

The bar

• Outcomes follow the Style Guide: stat budgets, open paths, pronoun-neutral prose.
• Read it once with high stats and once with low. Every if branch, gated choice and inline conditional should be worth reading from both sides.
• # TODO comments mark anything unfinished, honestly. Or park a whole draft branch inside a \* … *\ block comment.
• One fragment, or one tight theme, at a time. Ten open submissions per writer is the cap, and it exists to keep the queue fair rather than to slow you down.

Building on someone else’s fragment

This is the part worth learning early, because it is how the game becomes more than a pile of unrelated scenes, and it needs nobody’s permission.

A played: condition asks whether the player has already seen a particular fragment. So you can write your own fragment that only appears to people who lived through somebody else’s, without touching their file at all.

Say someone wrote youth_thirst, in which a character gets drunk with a friend called Kevin. You want the hangover, years later:

=== early_adulthood_kevin_calls
phase: early-adulthood
title: Kevin Calls
tags: friendship, past
requires: played:youth_thirst

Kevin's name on the screen, after all these years.

> Pick up
  "I know, I know. Long time."
  *effects: HAP+2

> Let it ring out
  You watch it stop. You're not sure why.
  *effects: HAP-2, MOR-1

The requires: line means this fragment is only ever offered to a player who saw youth_thirst. Everyone else never knows it exists.

Three things to know:

• You can find the ids in the Fragment Library, which lists every shipped fragment, what it sets, what it reads, and its full source. It spoils the game, so play first if you care about that.
• A typo is caught, not silent. played:youth_thirs fails the build with a message saying no fragment has that id. Before that check existed, a typo made a fragment permanently unreachable and nothing said a word.
• Prefer this over editing someone’s file. Adding to another author’s fragment unlocks once you have shipped one of your own, and replacing their words needs their agreement. A linked fragment needs neither, and it is usually the better idea anyway, because it is yours.
• If they leave, you do not. Any author can withdraw their work at any time, and a played: check pointing at a withdrawn fragment stays valid but can never be satisfied again. That is ours to fix rather than yours to absorb: the Contributor Agreement makes an orphaned dependency the project’s problem, and it is always solvable, because the characters and variables you leaned on belong to nobody and a replacement can be written. Your fragment is not deleted and not rewritten. Link freely.

You can also read a variable another fragment set, for instance requires: has_pet. Same principle, looser coupling: it fires for anyone who ever acquired a pet, whichever fragment gave them one.

What reviewers look for

Beyond “it builds”: does the fragment fit the game’s voice, do the stats express personality rather than power, do gated paths make both the have and the have-not version of the scene worth reading, and does the first tag place it in a sensible diversity group?

Ideas about the engine

The repository is not public, so there is no fork-and-pull-request route into the engine, the site or the format. There is somewhere better anyway: #feedback on the Discord is for exactly that, and it is as much for the things that already exist and annoy you as for the ones that do not exist yet. Either way, say what you were trying to do rather than what to build. “I wanted to see which fragments use a character and could not” has several possible answers, and one of them may already exist.

What gets built next is mostly whatever is blocking writers, so saying you are blocked is how something moves.