Charakterbögen im Regelsatz

Diese Seite zeigt dir, wie du den Charakterbogen eines Regelsatzes gestaltest: Attribute, Fertigkeiten, Felder und Listen, Live-Zustände, Wundleisten, Abzüge, Rasten und der Text für den Game Master sowie der Gruppenbogen und Fortschrittsuhren. Sie richtet sich an Regelsatz-Autoren. Bevor du anfängst, lies Regelsätze für Game Mode schreiben.

Der Bogen

Alles, was eine Zahl liest, benennt sie über einen Wertverweis: ein Objekt mit genau einem Schlüssel aus const, field, derived, abilityScore, abilityMod, abilityModFromField, skillMod, saveMod, listSum, livePool, liveTrack oder itemStat. Beispiel für einen Pool mit abgeleitetem Maximum: "max": { "derived": "grit_max" }.

Was eine Probe ohne Ausbildung tut. Eine Fertigkeit oder ein Rettungswurf, in dem der Charakter keine Ausbildung hat (seine Stufe ist die erste), wird wie gewohnt gewürfelt, sofern der Regelsatz nichts anderes sagt. Das geschieht mit untrained an der Fertigkeit, am Rettungswurf oder an dem Abschnitt, in dem sie stehen; die eigene Regel der Fertigkeit oder des Rettungswurfs hat Vorrang:

"sections": [{ "id": "labour", "label": "Labour", "untrained": { "by": -1 } }],
"skills": [
  { "id": "dig", "label": "Dig", "ability": "sinew", "section": "labour", "untrained": "refuse" },
  { "id": "listen", "label": "Listen", "ability": "nerve", "untrained": "harder" }
]

Abschnitte an Attributen, Fertigkeiten und Rettungswürfen sowie untrained an beliebiger Stelle brauchen bei einem als Paket ausgelieferten Regelsatz Capability API 1.41.

Eine Fertigkeit oder ein Rettungswurf kann ein cap tragen: einen Wertverweis auf das Höchste, was ihre Probe je ergeben darf – einen Wert, über den sie nicht hinauswachsen kann, oder eine Leiste, die sie niederhält. Gravewatch begrenzt Soothe auf das verbleibende Resolve eines Wächters: "cap": { "livePool": "resolve" }. Die begrenzte Zahl zeigt der Bogen, und mit ihr würfelt jede Probe. Ein Tausch mit with= wird mit der Zahl vor der Begrenzung berechnet und danach erneut begrenzt. Eine solche Obergrenze kann keinen Fertigkeits- oder Rettungswurfmodifikator lesen, ebenso wenig der abgeleitete Wert, den sie liest, oder ein davor deklarierter abgeleiteter Wert. So wird der Bogen weiterhin einmal von oben nach unten berechnet. Capability API 1.39.

hideWhen blendet ein Feld, einen abgeleiteten Wert, eine Liste, einen Pool oder eine einfache Leiste anhand des Werts eines anderen Feldes aus, und zwar auf genau eine von drei Arten: equals einem Wert, notEquals einem Wert (ausgeblendet, sobald das Feld etwas anderes enthält; so drückt man „nur für diese Art Charakter“ aus) oder in einer Liste von Werten. Jeder genannte Wert muss einer sein, den das Feld annehmen kann, sonst könnte die Regel nie zutreffen. Das wird Wert für Wert geprüft; bei notEquals und in gehören dazu auch der Bereich eines Zahlenfelds und die Länge eines Textfelds. Die Regel liest den Wert, den der Bogeneditor zeigt: Ein nicht gesetztes Feld hat den Wert, mit dem ein leerer Bogen beginnt, und ein Enum-Wert, den der Regelsatz nicht mehr anbietet, gilt als Standardwert des Feldes. Die 5e-Datei blendet mit equals Zauberplätze bei Charakteren ohne Zauber aus. Gravewatch hält Lampenöl mit "hideWhen": { "field": "watch", "notEquals": "night" } vom Bogen jedes Wächters fern, der nicht zur Nachtwache gehört. Eine Ebene kann keinen Wert entfernen, mit dem eine dieser Regeln vergleicht. Eine Wundleiste kann nicht ausgeblendet werden, weil Würfe und Kämpfe sie unabhängig von der Anzeige des Bogens lesen. notEquals und in brauchen Capability API 1.39.

Das max einer einfachen Leiste darf statt einer Zahl ein Wertverweis sein; ein Wert des Charakters legt dann fest, wie weit sie reicht: "max": { "field": "willpower_rating" }. min und default bleiben Zahlen. Eine Wundleiste mit benannten Stufen hat ein max gleich der Anzahl ihrer Stufen; eine Leiste mit nummerierten Kästchen ist so lang wie ihr eigenes max (siehe unten „Nummerierte Kästchen“). alwaysShow: true gibt eine Leiste auch auf ihrem Standardwert im Bogenblock des Game Master aus, für einen Wert, der in jedem Zug zählt. Ohne diese Angabe wird eine Leiste auf ihrem Standardwert weggelassen, weil drei Todesrettungswürfe auf null nichts aussagen. Bei einem als Paket ausgelieferten Regelsatz brauchen diese drei Capability API 1.37.

Live-Zustände: Eine Gestalt, eine Haltung, ein Licht

Ein Enum-Feld wird beim Erstellen eines Charakters gewählt und bleibt dann so, und ein Zustand ist nur an oder aus. Ein Live-Zustand ist dagegen ein Wert aus einer geschlossenen Menge, der sich im Spiel ändert: die Gestalt eines Gestaltwandlers, eine Kampfhaltung, wie hell eine Laterne brennt.

"live": {
  "states": [
    {
      "id": "stance",
      "label": "Stance",
      "values": ["guarded", "steady", "reckless"],
      "valueLabels": { "guarded": "Guarded", "steady": "Steady", "reckless": "Reckless" },
      "default": "steady"
    }
  ]
}

Zahlen, die folgen. Ein abgeleiteter Wert mit "op": "enumTable" liefert eine Zahl für jeden Wert eines Enum-Felds oder eines Live-Zustands:

{
  "id": "stance_brawn",
  "label": "Stance on Brawn",
  "op": "enumTable",
  "from": { "liveState": "stance" },
  "table": { "guarded": -1, "reckless": 2 },
  "default": 0
}

Live-Zustände, enumTable und ein Rast-Schritt, der einen state nennt, brauchen bei einem als Paket ausgelieferten Regelsatz Capability API 1.42.

Wundleisten: Gesundheit als Leiste statt als Zahl

Viele Systeme zählen überhaupt keine Trefferpunkte. Sie haben eine Spalte aus Kästchen, jedes schlimmer als das vorige, und bei einer Verletzung wird eines markiert. Gib einem Eintrag in live.tracks die Angabe kinds und entweder benannte levels oder nummerierte boxes (siehe unten); damit wird aus einer Zahl auf einer Skala eine solche Leiste:

Welche Form braucht dein System? Ein Pool erfasst, WIE VIEL Schaden ankam. Eine Leiste erfasst die Menge UND die Art jeder einzelnen Verletzung. Wenn dein System zwischen Schlagschaden, tödlichem und schwer heilbarem Schaden unterscheidet und die Art nach dem Treffer weiter wichtig ist – weil schwer heilbarer Schaden langsamer heilt, nicht absorbiert werden kann oder schließlich tötet –, muss diese Art nach dem Wurf irgendwo gespeichert bleiben. Das kann nur eine Markierung. Ein Punktepool kann es nicht: Nach dem Abzug bleibt nur eine kleinere Zahl, und der Bogen weiß nicht mehr, welche Punkte welche Art hatten. Deshalb wird combat.damageKinds bei Gesundheit als Pool abgelehnt, statt still ignoriert. Ein Pool kann weiterhin damageTypes haben, gegen die ein Gegner resistent oder immun ist. Dabei geht es um die Menge des ankommenden Schadens, nicht um die Art der danach verbleibenden Wunde.

{
  "id": "harm",
  "label": "Harm",
  "min": 0,
  "max": 4,
  "levels": [
    { "label": "Scuffed", "penalty": 0 },
    { "label": "Winded", "penalty": -1 },
    { "label": "Bleeding", "penalty": -3 },
    { "label": "Down", "penalty": -99 }
  ],
  "kinds": [
    { "id": "knock", "label": "K", "severity": 0 },
    { "id": "tear", "label": "T", "severity": 1 }
  ]
}

Die genauen Regeln, denn eine ungenaue Auslegung führt zur falschen Leiste:

Im Spiel markieren. Der Game Master schreibt [sheet: op="damage" track="harm" kind="knock" amount="1"] und heilt mit negativem amount. Bei einer Leiste, die nach Kästchen gefüllt wird, ergänzt er box="3" für das Kästchen, auf das der Treffer fällt. Die Pool-Form von damage, die stattdessen pool= nennt, bleibt unverändert. Der einfache track-Befehl wird für Wundleisten abgelehnt: Eine bloße Zahl kann die Art der neuen Markierungen nicht nennen. Spieler können Kästchen auch von Hand auf dem Bogen markieren und leeren, wie es solche Systeme vorsehen.

Auch ein Kampf kann eine Wundleiste markieren. Verweise mit combat.health auf die Leiste statt auf einen Pool. Ein ankommender Treffer markiert dann so viele Kästchen, wie combat.damageKinds.marks vorgibt, und verwendet die Art, auf die dieser Block den Schadenstyp abbildet. Ein Charakter mit voller Leiste geht zu Boden; das liest deine Sterberegel. Bei einer Leiste, die nach Kästchen gefüllt wird, nennt per-point-Schaden das Kästchen, auf das er fällt, und per-blow zielt auf das erste. Ein Treffer, den kein Kästchen mehr aufnehmen kann, schickt den Charakter zu Boden – genau das bedeutet Ausgeschaltetsein in den Systemen mit einer solchen Leiste. Heilung entfernt eine Markierung, die leichteste, gleich welcher Art. Temporäre Punkte werden abgelehnt, weil eine Leiste keinen Puffer dafür hat. Die Engine liest eine Leiste als ihre VERBLEIBENDEN Stufen. Alles andere am Kampf – zu Boden gehen, wiederbelebt werden, Protokoll und Rückblick – bleibt dadurch unverändert.

Eine Rast kann eine Wundleiste heilen. Ein Wiederherstellungsschritt mit "to" reduziert sie einschließlich Überlauf auf so viele Markierungen. Ein Schritt mit NEGATIVEM "by" entfernt die genannte Anzahl, zuerst den Überlauf; "by": { "const": -2 } entfernt also zwei. Ein Schritt, der zusätzlich eine kind nennt, entfernt nur Markierungen dieser Art: „Catch your breath“ in Gravewatch ist { "track": "harm", "kind": "knock", "to": "min" }; das heilt die Knock-Markierungen und lässt die Tear-Markierungen stehen. Ein Schritt, der Markierungen HINZUFÜGEN würde, tut nichts, weil eine Rast keinen Schaden markiert. Das gilt auch für ein positives "by": Es wird kommentarlos übersprungen. Schreib also das Minuszeichen.

Nummerierte Kästchen statt benannter Stufen

Ist eine Leiste so lang, wie ein Charakter zäh ist, gib ihr boxes statt levels. Sie hat so viele Kästchen wie ihr eigenes max, höchstens 64. Dieser Wert darf vom Bogen berechnet werden, aber nie den Live-Zustand lesen:

{
  "id": "strain",
  "label": "Strain",
  "min": 0,
  "max": { "derived": "strain_boxes" },
  "boxes": {
    "penalty": {
      "by": "remaining",
      "table": [
        [0, -1],
        [1, 0]
      ]
    }
  },
  "kinds": [{ "id": "strain", "label": "S", "severity": 0 }],
  "fill": "indexed",
  "onFull": "refuse"
}

Füllen nach Kästchen und Leisten, die ablehnen

Stufen, die eine Liste hinzufügt

"extra": { "list": "scars", "countColumn": "levels", "penaltyColumn": "penalty" } an einer Leiste mit benannten Stufen lässt eine Liste auf dem Bogen sie je Charakter verlängern. Jede Zeile fügt der Reihe nach ihre Anzahl an Stufen (höchstens 16) mit ihrem Abzug hinzu, und zwar hinter der letzten Stufe, deren Abzug mindestens genauso gut ist. Stimmen die Abzüge überein, werden die neuen Stufen nach dieser Stufe benannt, sonst nach ihrem Abzug. Die Narben in Gravewatch funktionieren so. Eine vom Bogen ausgeblendete Liste fügt nichts hinzu. Wird eine Zeile gelöscht, während ihre Stufen markiert sind, bleiben die nicht mehr passenden Markierungen als Überlauf erhalten: Schaden wird nicht durch Bearbeiten des Bogens rückgängig gemacht.

boxes, fill, onFull, extra und die kind eines Rast-Schritts brauchen bei einem als Paket ausgelieferten Regelsatz Capability API 1.40.

Der Abzug auf deine Würfe

resolution.penaltyFrom nennt die Wundleiste, deren Abzug für jede Probe dieses Regelsatzes gilt. Die Angabe wird deklariert, nicht vorausgesetzt. Ohne sie würfelt ein Regelsatz daher genauso wie vor der Einführung von Wundleisten.

Was der Abzug BEWIRKT, bestimmt wie beim eigenen Bogenwert die Auflösungsart:

Die genannte Leiste muss eine Wundleiste sein. Eine einfache Zahlenleiste hat keinen anzuwendenden Abzug; ein Verweis darauf wird beim Import abgelehnt. Das Ergebnis nennt den angewendeten Abzug, damit Spieler die kleinere Würfelanzahl nachvollziehen können. Auch der Bogenblock des Game Master zeigt die Stufe und ihren Abzug.

Modifikatoren vom Bogen

Manche Zahlen auf einem Bogen fahren bei jedem Wurf mit, den sie betreffen: ein schwerer Rucksack bei jedem Klettern, ein Rüstungsabzug bei jedem Schleichen, ein Segen bei allem. resolution.adjust drückt das bei beiden Auflösungsarten aus:

"adjust": [{ "value": { "derived": "burdened" }, "abilities": ["brawn"] }]

Das Ergebnis nennt, was der Bogen hinzugefügt hat (adjust="-2" im Datensatz und eine Zeile auf der Würfelkarte), damit Spieler nachvollziehen können, warum ein Wurf so ausgefallen ist. Bei einem als Paket ausgelieferten Regelsatz braucht das Capability API 1.38.

Rasten

Eine Rast ist eine Liste von Wiederherstellungsschritten und zu entfernenden Dingen. Jeder Schritt nennt genau ein Ziel (pool, poolGroup, listPools, track oder state) und setzt es entweder auf einen Wert ("to": "max", "to": "min" oder eine Zahl) oder verändert es ("by": { "const": 1 } oder "by": { "fractionOfMax": 0.5 }). Ein Schritt für eine Wundleiste kann sie nur heilen, sein by ist daher negativ; siehe oben. Ein Schritt für einen Live-Zustand setzt ihn nur, und zwar auf "default" oder einen seiner Werte. Ein poolGroup-Schritt mit fractionOfMax verändert jeden Pool der Gruppe um seinen eigenen Anteil. Mit "shared": true (Capability API 1.77) wird der Anteil stattdessen aus dem Maximum der ganzen Gruppe berechnet und in der Reihenfolge, in der der Bogen die Pools auflistet, auf die Pools der Gruppe verteilt, jeder bis zu dem, was ihm fehlt. Die lange Rast in 5e, „die Hälfte der Gesamtzahl der“ Trefferwürfel des Charakters, gehalten in einem Pool pro Würfeltyp, ist { "poolGroup": "hit_dice", "by": { "fractionOfMax": 0.5, "round": "down", "min": 1 }, "shared": true }.

Text für den Game Master

Vollständige Regelreferenz für den Game Master

Das optionale gmReference auf der obersten Ebene enthält die vollständige Regelreferenz deines Regelsatzes für den Game Master, bis zu 16.000 Zeichen. Schreib ausführliche Entscheidungsregeln hierher und lass die kurzen Anweisungen zu Proben und Ressourcen in gm.checkGuidance und gm.sheetGuidance. Für diese Felder und für gm.worldGuidance gelten weiterhin ihre Grenzen von 1.500 Zeichen; auch der Anleitungstext von Ebenen behält seine bisherigen Grenzen.

"gmReference": "When a journey crosses hostile country, judge supplies, shelter and exposure before the next leg. A failed navigation check costs time rather than silently moving the party to its destination."

Die Referenz erscheint unter Game Master rules reference im stabilen Systemprompt, einmal pro Anfrage. Sie wird nie in die Erinnerung des jeweiligen Zuges kopiert. Wie anderer promptsichere Text muss sie eine einzige Zeile sein, ohne Steuerzeichen, eckige Klammern oder Makro-Klammern ({{ und }}). Überschreitet die Anfrage nach den üblichen Anpassungen an Verlauf und Antwortbudget noch immer die Kontextgrenze, wird die Referenz mit einer markierten Kürzung gekürzt, bevor Kernanweisungen gekürzt werden. Lass sie weg, um die bisherigen Prompts beizubehalten. Ein Paket, das sie verwendet, muss im Manifest schemaVersion: 2 und capabilityApi: { "major": 1, "minor": 145 } oder neuer deklarieren.

Fortschrittsuhren für Gruppe und Szene (clocks)

Capability API 1.143 ergänzt ein optionales clocks-Objekt auf der obersten Ebene. Lass es weg, damit die Uhrbefehle ausgeschaltet bleiben. Das Objekt ist streng: Nur diese drei Schlüssel werden angenommen.

"clocks": {
  "sizes": [4, 6, 8],
  "max": 8,
  "text": "Create clocks for looming threats and long projects. Tick them when the fiction advances."
}

sizes erlaubt ein bis sechs verschiedene ganzzahlige Segmentanzahlen, jede von 2 bis 12; der Standard ist [4, 6, 8]. max ist die Höchstzahl gleichzeitig geführter Uhren, von 1 bis 12, standardmäßig 8. Das optionale text ist eine promptsichere Zeile mit bis zu 400 Zeichen, die erklärt, wann der GM Uhren anlegen und vorrücken soll. Ein leeres Objekt schaltet die Standardwerte ein.

Uhren gehören zur Gruppe beziehungsweise zur Szene, nicht zu einem Charakter. Die Erinnerung des GM nennt in jedem Zug ihre Namen und ihren Füllstand und bringt ihm diese Befehle bei:

Namen sind einzelne Zeilen mit 1–100 Zeichen ohne doppelte Anführungszeichen, eckige Klammern, Steuerzeichen oder Makro-Klammern. Jedes Tag verlangt genau eine Aktion. Befehle werden in der Reihenfolge der Antwort angewendet; eine Uhr kann also in derselben Antwort angelegt und vorgerückt werden. Die Engine schreibt jedes Tag mit result="ok" now="4/6" (oder now="cleared") oder mit result="refused" reason="..." neu. Vom Modell gelieferte Ergebnisattribute werden verworfen. Unbekannte Uhren und fehlerhafte Anfragen werden abgelehnt; pro Antwort werden höchstens 40 Befehle angewendet.

Game Mode zeigt neben dem Gruppenstatus einen segmentierten Kreis, den Namen und den Füllstand. Die Tags bleiben als Belege in der gespeicherten Antwort und werden in der Erzählung ausgeblendet. Uhren werden in jedem Snapshot des Spielzustands als rulesetClocks gespeichert; fehlende Daten bedeuten, dass es keine Uhren gibt. Eine neu generierte Antwort beginnt beim vorherigen Snapshot, ein Fortsetzen beim aktuellen, und das Auswählen oder Entfernen von Swipes oder Nachrichten stellt die Uhren zusammen mit dem Rest dieses Snapshots wieder her.

Gruppenbogen: Eine Crew, ein Schiff oder gemeinsame Story Points

Capability API 1.144 ergänzt neben sheet ein optionales party auf der obersten Ebene. Es enthält einen gemeinsamen Bogen pro Spiel, etwa eine Crew in Blades, ein Schiff in Lasers & Feelings oder die Story Points von Genesys:

"party": {
  "label": "Crew",
  "fields": [
    { "id": "heat", "label": "Heat", "type": "number", "min": 0, "max": 9, "default": 0 },
    { "id": "vault", "label": "Vault capacity", "type": "number", "min": 0, "max": 16, "default": 8 },
    { "id": "upgrades", "label": "Upgrades", "type": "text", "maxLength": 400 }
  ],
  "pools": [{ "id": "coin", "label": "Coin", "max": { "field": "vault" }, "start": "empty" }],
  "advancement": { "fields": ["heat", "vault", "upgrades"], "text": "Record heat after a score." },
  "text": "Coin belongs to the crew."
}

fields verwendet dasselbe Feldschema wie sheet.fields, pools das von sheet.live.pools, einschließlich start, group, hideWhen und allowTemp. Mindestens ein Feld oder ein Pool ist nötig, und ihre IDs müssen innerhalb des Gruppenbogens eindeutig sein. IDs von Charakter und Gruppe dürfen übereinstimmen. Gruppenbögen haben in dieser Nebenversion keine Abschnitte, Listen, Attribute, abgeleiteten Werte oder Migrationen des Charakterbogens. Das max eines Pools liest eine Konstante oder ein Zahlenfeld der Gruppe. Formeln eines Charakters können keine Gruppenwerte lesen, und Formeln der Gruppe keine Charakterwerte. Auch hideWhen nennt nur Felder der Gruppe.

advancement.fields nennt Zahlen-, Text- oder Langtextfelder, die der GM dauerhaft ändern darf. advancement.text und text nehmen je eine promptsichere Zeile mit höchstens 400 Zeichen. Das optionale summary verwendet gm.sheetSummary wieder: Seine fields wählen Felder der Gruppe aus; derived und lists müssen leer sein. Ohne Zusammenfassung werden alle sichtbaren Felder der Gruppe gezeigt. Pools erscheinen immer.

[sheet: sheet="party" op="restore" pool="coin" amount="3"]
[sheet: sheet="party" op="spend" pool="coin" amount="2"]
[sheet: sheet="party" op="advance" field="heat" by="2"]
[sheet: sheet="party" op="advance" field="upgrades" to="Hidden vault"]

sheet="party" wählt den gemeinsamen Bogen; lass who weg. Das bisherige who="party" gilt weiterhin für jeden Charakter und ändert nie den gemeinsamen Bogen. Diese Nebenversion erlaubt auf dem Gruppenbogen spend, restore und advance für Felder. Unbekannte Bögen, nicht unterstützte Operationen, nicht ausreichende Pools, nicht deklarierter Fortschritt und ungültige Werte werden abgelehnt und mit dem Ergebnis der Engine neu geschrieben. Gruppenpools folgen derselben Rechnung aus aktuellem Wert und Maximum und denselben Standardwerten wie Charakterpools.

Der GM erhält in jedem Zug neben den Bogenblöcken der Charaktere die Beschriftung, die Felder und die Pools der Gruppe. Game Mode bietet neben den Charakterporträts einen einklappbaren, schreibgeschützten Gruppenbogen in derselben Bogendarstellung an. Dauerhafte Werte liegen einmal in den Chat-Metadaten (gamePartySheet), neben gameCharacterCards, und teilen sich die Belege für Fortschritte. Live-Pools verwenden den reservierten Eintrag $party von rulesetLive; normalisierte Charakternamen können nicht mit ihm kollidieren. Neu generieren setzt vor der Antwort an, und das Auswählen oder Löschen eines Swipes stellt über den bestehenden Verlauf sowohl dauerhafte als auch Live-Werte wieder her. Regelsätze ohne party verhalten sich wie bisher.

Gemeinsame Gruppenerstellung (Capability API 1.163). Ein Gruppenbogen darf lists tragen (bis zu 12, geschrieben wie die Listen des Charakterbogens), einen eigenen geführten builder und fromMembers: bis zu 8 Zahlenfelder der Gruppe, die von den Charakteren der Gruppe gelesen werden, jeweils { "field", "count": true } (wie viele Charaktere es gibt) oder { "field", "sum": "<character number field>" } (was deren Werte zusammen ergeben, etwa Totem-Punkte). Mitgliederfelder werden bei jedem Lesen des gemeinsamen Bogens aus den Charakteren berechnet, wie sie gerade sind; ein Charakter, der dazukommt oder geht, ändert sie also sofort. Mit Listen darf das summary.lists der Gruppe sie nennen.

Der Erstellungsassistent wird genau wie der eines Charakters geschrieben (Pools, Schritte, Zeilen mit Preis, Ausgabeangebote, Profile) und unterliegt denselben Regeln, bezogen auf die eigenen Felder und Listen der Gruppe. Seine Katalog- und Zeilenkopierschritte dürfen die Kataloge des Regelsatzes lesen, die Gruppenlisten befüllen. In Game Mode öffnet jeder Spieler die Bearbeitung (Edit) des gemeinsamen Bogens, die die geführte Einrichtung anbietet, und speichert sie für die ganze Gruppe. Jedes Speichern nennt die Revision, auf der es geöffnet wurde (gamePartySheetRevision in den Chat-Metadaten, erhöht durch jedes Speichern und durch Änderungen der Geschichte selbst): Ein Speichern, das geöffnet wurde, bevor das eines anderen ankam, wird abgelehnt, der neuere Bogen wird angezeigt, und der Entwurf des Spielers bleibt offen. Erneutes Speichern ist dann seine bewusste Entscheidung, den neueren Bogen zu ersetzen.

"party": {
  "label": "The Crew",
  "fields": [
    { "id": "tier", "label": "Tier", "type": "number", "min": 0, "max": 4, "default": 0 },
    { "id": "size", "label": "Crew size", "type": "number", "min": 0, "max": 12, "default": 0 }
  ],
  "lists": [{ "id": "upgrades", "label": "Upgrades", "columns": [{ "id": "name", "label": "Name", "type": "text" }] }],
  "builder": { "steps": [{ "id": "upgrades", "label": "Upgrades", "kind": "rows", "list": "upgrades" }] },
  "fromMembers": [{ "field": "size", "count": true }]
}