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. Post it to the submissions forum. A bot checks that it parses and reports back, usually within a minute.
5. Revise. Two other writers read it and comment, then a maintainer accepts or declines with reasons.
6. Ship. On acceptance the bot opens a pull request, and a human merges it. 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 do not know 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?

If you would rather work on the engine

That track is a normal clone, branch and pull request, and it is documented in CONTRIBUTING.md in the repository. Please do not submit a fragment that way, though: the Discord route is what records your authorship and your acceptance of the terms, and a pull request skips both.