नियमसेट की शीट

इस पेज की मदद से नियमसेट की कैरेक्टर शीट डिज़ाइन करें: एबिलिटी, स्किल, फ़ील्ड और सूचियाँ, लाइव स्टेट, घाव ट्रैक, पेनल्टी, आराम और Game Master टेक्स्ट, साथ ही पार्टी की शीट और प्रोग्रेस क्लॉक। यह पेज नियमसेट लिखने वालों के लिए है। शुरू करने से पहले Game Mode के नियमसेट लिखना पढ़ें।

शीट

संख्या पढ़ने वाली हर चीज़ उसका नाम वैल्यू रेफ़रेंस से देती है, जो ठीक एक कुंजी वाला ऑब्जेक्ट है: const, field, derived, abilityScore, abilityMod, abilityModFromField, skillMod, saveMod, listSum, livePool, liveTrack या itemStat। जैसे, ऐसा पूल जिसका अधिकतम निकाला गया मान है: "max": { "derived": "grit_max" }।

बिना प्रशिक्षण के चेक क्या करता है। जिस स्किल या सेव में कैरेक्टर का कोई प्रशिक्षण नहीं है (उसका स्तर पहला है), वह सामान्य तरह रोल होता है, जब तक नियमसेट स्किल या सेव पर, या उसके सेक्शन पर, untrained से कुछ और न कहे (स्किल या सेव का अपना नियम जीतता है):

"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" }
]

पैकेज वाले नियमसेट में एबिलिटी, स्किल और सेव पर सेक्शन, और कहीं भी untrained, Capability API 1.41 हैं।

स्किल या सेव में cap हो सकता है, यानी वैल्यू रेफ़रेंस जो बताता है कि उसका चेक अधिकतम कितना हो सकता है: ऐसी रेटिंग जिससे वह आगे नहीं बढ़ सकता, या ऐसा ट्रैक जो उसे दबाकर रखता है। Gravewatch, Soothe को उस Resolve तक सीमित करता है जो वार्डन के पास बचा है, "cap": { "livePool": "resolve" }। सीमित की गई संख्या ही वह है जो शीट दिखाती है और हर चेक रोल करता है, और with= से एबिलिटी बदलने का हिसाब सीमा से पहले वाली संख्या पर होता है और फिर दोबारा सीमित होता है। यह सीमा स्किल या सेव मॉडिफ़ायर नहीं पढ़ सकती, न वह निकाला गया मान जिसे वह पढ़ती है, न उससे ऊपर घोषित कोई निकाला गया मान, ताकि शीट अब भी ऊपर से नीचे एक ही बार में निकाली जाए। Capability API 1.39।

hideWhen किसी फ़ील्ड, निकाले गए मान, सूची, पूल या साधारण ट्रैक को दूसरे फ़ील्ड के मान के आधार पर छिपाता है, ठीक तीन में से एक तरीके से: एक मान के equals, एक मान के notEquals (फ़ील्ड में कुछ और होने पर हर बार छिपा, यानी "सिर्फ़ इस तरह के कैरेक्टर के लिए" ऐसे कहा जाता है), या मानों की सूची के in। बताया गया हर मान ऐसा होना चाहिए जो फ़ील्ड में आ सके, वरना नियम कभी मेल नहीं खाएगा, और यह हर मान के लिए अलग से जाँचा जाता है; notEquals और in के लिए इसमें नंबर फ़ील्ड का दायरा और टेक्स्ट फ़ील्ड की लंबाई भी शामिल है। नियम वह मान पढ़ता है जो शीट एडिटर दिखाता है: सेट न किया गया फ़ील्ड वह मान है जिससे खाली शीट शुरू होती है, और जो enum मान नियमसेट अब नहीं देता वह फ़ील्ड का डिफ़ॉल्ट है। 5e फ़ाइल स्पेल न चलाने वाले कैरेक्टर से स्पेल स्लॉट छिपाने के लिए equals इस्तेमाल करती है; Gravewatch रात की पहरेदारी पर न होने वाले हर वार्डन की शीट से लालटेन का तेल "hideWhen": { "field": "watch", "notEquals": "night" } से हटा देता है। लेयर ऐसा कोई मान नहीं हटा सकती जिससे इनमें से कोई तुलना करता है। घाव ट्रैक छिपाया नहीं जा सकता, क्योंकि शीट कुछ भी दिखाए, रोल और लड़ाइयाँ उसे पढ़ती हैं। notEquals और in Capability API 1.39 हैं।

साधारण ट्रैक का max संख्या के बजाय वैल्यू रेफ़रेंस हो सकता है, ताकि कैरेक्टर की कोई रेटिंग तय करे कि वह कहाँ तक जाता है: "max": { "field": "willpower_rating" }। उसके min और default संख्याएँ ही रहते हैं। नामित स्तरों वाले घाव ट्रैक का max उसके स्तरों की संख्या के बराबर होता है; नंबर वाले खानों का ट्रैक अपने max जितना लंबा होता है (नीचे नामित स्तरों के बजाय नंबर वाले खाने देखें)। alwaysShow: true ट्रैक को डिफ़ॉल्ट पर होने पर भी Game Master के शीट ब्लॉक में छापता है, ऐसी रेटिंग के लिए जो हर टर्न मायने रखती है; इसके बिना डिफ़ॉल्ट पर रहा ट्रैक छोड़ दिया जाता है, क्योंकि शून्य पर तीन डेथ सेव कुछ नहीं कहते। पैकेज वाले नियमसेट में ये तीनों Capability API 1.37 हैं।

लाइव स्टेट: रूप, रुख, रोशनी

enum फ़ील्ड कैरेक्टर बनाते समय चुना जाता है और चुना ही रहता है, और स्थिति सिर्फ़ चालू या बंद होती है। लाइव स्टेट एक बंद समूह में से एक मान है जो खेल में बदलता है: रूप बदलने वाले का रूप, लड़ाई का रुख, लालटेन कितनी जल रही है।

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

साथ चलने वाली संख्याएँ। "op": "enumTable" वाला निकाला गया मान enum फ़ील्ड या लाइव स्टेट के हर मान के लिए एक संख्या देता है:

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

पैकेज वाले नियमसेट में लाइव स्टेट, enumTable और state का नाम देने वाला आराम का चरण Capability API 1.42 हैं।

घाव ट्रैक: संख्या के बजाय ट्रैक वाला स्वास्थ्य

कई सिस्टम हिट पॉइंट गिनते ही नहीं। उनमें खानों का एक कॉलम होता है, हर अगला खाना पिछले से बुरा, और चोट लगने पर आप एक टिक करते हैं। किसी live.tracks एंट्री को kinds और साथ में नामित levels या नंबर वाले boxes (नीचे) दें, तो वह स्केल पर संख्या न रहकर ऐसा ट्रैक बन जाती है:

आपके सिस्टम को कौन सा रूप चाहिए? पूल दर्ज करता है कि कितना नुकसान लगा; ट्रैक दर्ज करता है कि कितना और उसका हर हिस्सा किस प्रकार का था। अगर आपका सिस्टम कहता है कि घाव bashing, lethal या aggravated है, और वार के बाद भी यह मायने रखता है कि वह कौन सा था, क्योंकि aggravated धीरे भरता है, या सोखा नहीं जा सकता, या आखिर में वही मारता है, तो रोल के बाद वह प्रकार कहीं बचा रहना चाहिए, और सिर्फ़ निशान उसे रखता है। पॉइंट का पूल यह नहीं कर सकता: नुकसान घटने के बाद वह सिर्फ़ एक छोटी संख्या है, और शीट पर कुछ भी याद नहीं रखता कि कौन सा पॉइंट किस प्रकार का था। इसीलिए जिस नियमसेट का स्वास्थ्य पूल है, उसमें combat.damageKinds चुपचाप अनदेखा होने के बजाय अस्वीकार होता है। पूल में अब भी damageTypes हो सकते हैं, और विरोधी अब भी उनका प्रतिरोध कर सकता है या उनसे इम्यून हो सकता है, क्योंकि यह सवाल है कि वार का कितना हिस्सा लगता है, यह नहीं कि बाद में घाव क्या है।

{
  "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 }
  ]
}

ठीक-ठीक नियम, क्योंकि अस्पष्ट पढ़ने से गलत ट्रैक बनता है:

खेल में निशान लगाना। Game Master [sheet: op="damage" track="harm" kind="knock" amount="1"] लिखता है, और ऋणात्मक amount से हील करता है। खाने-दर-खाने भरने वाले ट्रैक पर वह उस खाने के लिए box="3" जोड़ता है जिस पर वार लगता है। damage का पूल वाला रूप, जो इसके बजाय pool= का नाम देता है, नहीं बदला है। घाव ट्रैक पर साधारण track कमांड अस्वीकार होती है: अकेली संख्या नहीं बता सकती कि नए निशान क्या हैं। खिलाड़ी शीट पर हाथ से भी खाने चिह्नित और साफ़ कर सकता है, जैसी इन सिस्टम में उम्मीद होती है।

लड़ाई भी इसे चिह्नित कर सकती है। combat.health को पूल के बजाय ट्रैक की ओर इशारा कराएँ तो लड़ाई उसे चिह्नित करती है: लगा हुआ वार उतने खाने चिह्नित करता है जितने combat.damageKinds.marks कहता है, उस प्रकार से जिससे वह ब्लॉक उसके नुकसान प्रकार को जोड़ता है, और जिस कैरेक्टर का ट्रैक भरा है वह गिरा हुआ है, जिसे आपका मरने का नियम पढ़ता है। खाने-दर-खाने भरने वाले ट्रैक पर per-point नुकसान उस खाने का नाम देता है जिस पर वह लगता है और per-blow पहले खाने पर निशाना लगाता है, और जिस वार को कोई खाना नहीं ले सकता वह कैरेक्टर को गिरा देता है, क्योंकि ऐसे ट्रैक रखने वाले सिस्टम में बाहर हो जाने का यही मतलब है। हीलिंग किसी भी प्रकार का एक निशान साफ़ करती है, सबसे हल्का। अस्थायी पॉइंट अस्वीकार होते हैं, क्योंकि ट्रैक में उनके रहने के लिए कोई बफ़र नहीं है। Engine ट्रैक को उसके बचे हुए स्तरों की तरह पढ़ता है, इसलिए लड़ाई की बाकी हर बात, गिरना, फिर से जीवित होना, लॉग और सारांश, नहीं बदलती।

आराम घाव ट्रैक को हील कर सकता है। "to" से उसका नाम देने वाला restore चरण उसे ओवरफ़्लो समेत उतने निशानों तक साफ़ करता है; ऋणात्मक "by" से नाम देने वाला चरण उतने निशान साफ़ करता है, ओवरफ़्लो पहले, इसलिए "by": { "const": -2 } दो साफ़ करता है। साथ में kind का नाम देने वाला चरण सिर्फ़ उसी प्रकार के निशान साफ़ करता है: Gravewatch का "Catch your breath" { "track": "harm", "kind": "knock", "to": "min" } है, जो चोट (knock) के निशान ठीक करता है और चीर (tear) के निशान छोड़ देता है। निशान जोड़ने वाला चरण कुछ नहीं करता, क्योंकि आराम कोई नुकसान चिह्नित नहीं करता, और इसमें धनात्मक "by" भी आता है: वह बिना कुछ कहे छोड़ दिया जाता है, इसलिए माइनस का चिह्न लिखें।

नामित स्तरों के बजाय नंबर वाले खाने

जहाँ ट्रैक उतना लंबा हो जितना कैरेक्टर मज़बूत है, वहाँ उसे levels के बजाय boxes दें। उसमें उतने खाने होते हैं जितना उसका अपना max है, जो शीट का निकाला गया मान हो सकता है (लाइव स्टेट पढ़ने वाला कभी नहीं), अधिकतम 64:

{
  "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"
}

खाने-दर-खाने भरना, और अस्वीकार करने वाले ट्रैक

सूची से जुड़ने वाले स्तर

नामित स्तरों वाले ट्रैक पर "extra": { "list": "scars", "countColumn": "levels", "penaltyColumn": "penalty" } शीट की किसी सूची को हर कैरेक्टर के लिए उसे लंबा करने देता है। हर पंक्ति, क्रम से, अपनी संख्या जितने स्तर (अधिकतम 16) अपनी पेनल्टी पर जोड़ती है, उस आखिरी स्तर के बाद जिसकी पेनल्टी कम से कम उतनी अच्छी है; पेनल्टी मेल खाने पर उनका नाम उस स्तर पर रखा जाता है, वरना पेनल्टी पर। Gravewatch में पुराने घावों के दाग (scars) इसी तरह काम करते हैं। शीट से छिपी सूची कुछ नहीं जोड़ती, और अगर किसी पंक्ति के स्तर चिह्नित रहते वह पंक्ति हटा दी जाए, तो जो निशान अब नहीं समाते वे ओवरफ़्लो के रूप में रखे जाते हैं: शीट एडिट करने से नुकसान वापस नहीं होता।

पैकेज वाले नियमसेट में boxes, fill, onFull, extra और आराम के चरण का kind Capability API 1.40 हैं।

आपके रोल की पेनल्टी

resolution.penaltyFrom उस घाव ट्रैक का नाम देता है जिसकी पेनल्टी इस नियमसेट के हर चेक पर लागू होती है। यह घोषित किया जाता है, मान नहीं लिया जाता, इसलिए इसे छोड़ने वाला नियमसेट बिल्कुल वैसे ही रोल करता है जैसे घाव ट्रैक आने से पहले करता था।

पेनल्टी क्या करती है, यह शीट की अपनी संख्या की तरह ही आपके हल करने के प्रकार पर निर्भर है:

जिस ट्रैक का यह नाम देता है वह घाव ट्रैक होना चाहिए। साधारण ट्रैक में लागू करने को कोई पेनल्टी नहीं होती, और उसका नाम देना इंपोर्ट पर अस्वीकार होता है। नतीजा बताता है कि कौन सी पेनल्टी लागू हुई, ताकि खिलाड़ी देख सके कि उसने कम डाइस क्यों रोल किए, और Game Master का अपना शीट ब्लॉक स्तर और उसकी कीमत दिखाता है।

शीट से आने वाले मॉडिफ़ायर

शीट की कुछ संख्याएँ हर उस रोल के साथ चलती हैं जिसे वे छूती हैं: हर चढ़ाई पर भारी बोझ, हर दबे पाँव चलने पर कवच की पेनल्टी, हर चीज़ पर आशीर्वाद। resolution.adjust दोनों प्रकारों में यही बताता है:

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

नतीजा बताता है कि शीट ने क्या जोड़ा (रिकॉर्ड पर adjust="-2", और डाइस कार्ड पर एक लाइन), ताकि खिलाड़ी देख सके कि रोल वैसा क्यों निकला। पैकेज वाले नियमसेट में यह Capability API 1.38 है।

आराम

आराम restore चरणों और साफ़ होने वाली चीज़ों की सूची है। हर चरण एक लक्ष्य (pool, poolGroup, listPools, track या state) का नाम देकर या तो उसे सेट करता है ("to": "max", "to": "min" या कोई संख्या) या बदलता है ("by": { "const": 1 } या "by": { "fractionOfMax": 0.5 })। घाव ट्रैक का नाम देने वाला चरण उसे सिर्फ़ हील कर सकता है, इसलिए उसका by ऋणात्मक होता है; ऊपर देखें। लाइव स्टेट का नाम देने वाला चरण उसे सिर्फ़ सेट करता है, "default" पर या उसके किसी मान पर। fractionOfMax वाला poolGroup चरण समूह के हर पूल को उसके अपने हिस्से से बदलता है; इसके बजाय पूरे समूह के अधिकतम पर हिस्सा निकालने के लिए "shared": true (Capability API 1.77) जोड़ें, और तब वह हिस्सा समूह के पूलों को उसी क्रम में दिया जाता है जिसमें शीट उन्हें सूचीबद्ध करती है, हर एक को उतना जितना उसमें कम है। 5e का लंबा आराम, जो हर डाइस के लिए अलग पूल में रखे गए हिट डाइस में से "कैरेक्टर की कुल संख्या का आधा" लौटाता है, { "poolGroup": "hit_dice", "by": { "fractionOfMax": 0.5, "round": "down", "min": 1 }, "shared": true } है।

Game Master टेक्स्ट

पूरा GM नियम संदर्भ

वैकल्पिक टॉप-लेवल gmReference में Game Master के लिए नियमसेट का पूरा नियम संदर्भ होता है, अधिकतम 16,000 अक्षर। फ़ैसले के विस्तृत नियम यहाँ रखें, और चेक और संसाधनों के छोटे निर्देश gm.checkGuidance और gm.sheetGuidance में रखें। उन फ़ील्ड की, और gm.worldGuidance की, 1,500 अक्षरों की सीमा अब भी है; लेयर के निर्देशों की मौजूदा सीमाएँ भी वैसी ही रहती हैं।

"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."

संदर्भ स्थिर सिस्टम प्रॉम्प्ट में Game Master rules reference (Game Master नियम संदर्भ) के नीचे दिखता है, हर रिक्वेस्ट में एक बार। इसे कभी हर टर्न वाले रिमाइंडर में कॉपी नहीं किया जाता। प्रॉम्प्ट में सुरक्षित दूसरे टेक्स्ट की तरह, यह एक लाइन होना चाहिए, बिना कंट्रोल कैरेक्टर, वर्ग ब्रैकेट या मैक्रो ब्रेसेज़ ({{ और }}) के। जब हिस्ट्री और जवाब के बजट में होने वाले आम बदलावों के बाद भी रिक्वेस्ट कॉन्टेक्स्ट सीमा से ज़्यादा हो, तो मुख्य निर्देश काटे जाने से पहले संदर्भ को चिह्नित कटौती के साथ छोटा किया जाता है। मौजूदा प्रॉम्प्ट रखने के लिए इसे सेट न करें। इसे इस्तेमाल करने वाले पैकेज को मैनिफ़ेस्ट में schemaVersion: 2 और capabilityApi: { "major": 1, "minor": 145 } या नया घोषित करना होगा।

पार्टी और सीन के प्रोग्रेस क्लॉक (clocks)

Capability API 1.143 वैकल्पिक टॉप-लेवल clocks ऑब्जेक्ट जोड़ता है। क्लॉक कमांड बंद रखने के लिए इसे छोड़ दें। ऑब्जेक्ट सख्त है: सिर्फ़ ये तीन कुंजियाँ मानी जाती हैं।

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

sizes में एक से छह अलग-अलग पूर्णांक खंड-संख्याएँ हो सकती हैं, हर एक 2 से 12 तक; डिफ़ॉल्ट [4, 6, 8] है। max एक साथ रखे जाने वाले क्लॉक की अधिकतम संख्या है, 1 से 12 तक, और डिफ़ॉल्ट 8 है। वैकल्पिक text प्रॉम्प्ट में सुरक्षित, अधिकतम 400 अक्षरों की एक लाइन है, जो बताती है कि GM को क्लॉक कब बनाने और टिक करने चाहिए। खाली ऑब्जेक्ट डिफ़ॉल्ट चालू करता है।

क्लॉक पार्टी/सीन के होते हैं, किसी कैरेक्टर के नहीं। GM रिमाइंडर हर टर्न उनके नाम और भराव सूचीबद्ध करता है और ये कमांड सिखाता है:

नाम 1–100 अक्षरों की एक लाइन होते हैं, बिना डबल कोट, वर्ग ब्रैकेट, कंट्रोल कैरेक्टर या मैक्रो ब्रेसेज़ के। हर टैग ठीक एक काम माँगता है। कमांड जवाब के क्रम में लागू होती हैं, इसलिए एक ही जवाब में क्लॉक बनाया और टिक किया जा सकता है। Engine हर टैग को result="ok" now="4/6" (या now="cleared") के साथ, या result="refused" reason="..." के साथ दोबारा लिखता है। मॉडल के दिए नतीजे वाले एट्रिब्यूट हटा दिए जाते हैं। अनजान क्लॉक और गलत बनी रिक्वेस्ट अस्वीकार होती हैं; एक जवाब में अधिकतम 40 कमांड लागू होती हैं।

Game Mode पार्टी के स्टेटस के बगल में खंडों वाला गोला, नाम और भराव दिखाता है। टैग सेव हुए जवाब में रसीद के रूप में रहते हैं और नैरेशन से छिपे रहते हैं। क्लॉक हर गेम-स्टेट स्नैपशॉट में rulesetClocks के रूप में सेव होते हैं; डेटा न होने का मतलब है कोई क्लॉक नहीं। दोबारा जेनरेट करना पिछले स्नैपशॉट से शुरू होता है, आगे बढ़ाना मौजूदा स्नैपशॉट से, और स्वाइप/संदेश चुनना या हटाना उस स्नैपशॉट के बाकी हिस्से के साथ क्लॉक भी लौटा देता है।

पार्टी शीट: क्रू, जहाज़ या साझा Story Points

Capability API 1.144 sheet के बगल में वैकल्पिक टॉप-लेवल party जोड़ता है। इसमें हर गेम के लिए एक साझा शीट होती है, जैसे Blades का क्रू, Lasers & Feelings का जहाज़, या Genesys के Story Points:

"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 वही फ़ील्ड स्कीमा इस्तेमाल करता है जो sheet.fields; pools sheet.live.pools वाला, start, group, hideWhen और allowTemp समेत। कम से कम एक फ़ील्ड या पूल ज़रूरी है, और उनके ID पार्टी शीट के अंदर अलग-अलग होने चाहिए। कैरेक्टर और पार्टी के ID एक जैसे हो सकते हैं। इस माइनर वर्ज़न में पार्टी शीट में सेक्शन, सूचियाँ, एबिलिटी, निकाले गए मान या कैरेक्टर शीट के माइग्रेशन नहीं होते। पूल का max कोई स्थिर संख्या या पार्टी का नंबर फ़ील्ड पढ़ता है। कैरेक्टर के फ़ॉर्मूले पार्टी के मान नहीं पढ़ सकते, और पार्टी के फ़ॉर्मूले कैरेक्टर के मान नहीं। hideWhen भी सिर्फ़ पार्टी के फ़ील्ड का नाम देता है।

advancement.fields उन number, text या longtext फ़ील्ड का नाम देता है जिन्हें GM स्थायी रूप से बदल सकता है। advancement.text और text में से हर एक प्रॉम्प्ट में सुरक्षित, अधिकतम 400 अक्षरों की एक लाइन लेता है। वैकल्पिक summary gm.sheetSummary को दोबारा इस्तेमाल करता है: उसके fields पार्टी के फ़ील्ड चुनते हैं; derived और lists खाली होने चाहिए। सारांश के बिना पार्टी के सारे दिखने वाले फ़ील्ड दिखाए जाते हैं। पूल हमेशा दिखते हैं।

[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" साझा शीट चुनता है; who छोड़ दें। मौजूदा who="party" अब भी हर कैरेक्टर पर लागू होता है और साझा शीट को कभी नहीं बदलता। यह माइनर वर्ज़न पार्टी शीट पर spend, restore और फ़ील्ड का advance मंज़ूर करता है। अनजान शीट, असमर्थित ऑपरेशन, नाकाफ़ी पूल, बिना घोषित उन्नति और अमान्य मान अस्वीकार होते हैं और Engine के नतीजे के साथ दोबारा लिखे जाते हैं। पार्टी के पूल कैरेक्टर के पूल वाला ही मौजूदा/अधिकतम का हिसाब और डिफ़ॉल्ट मानते हैं।

GM को हर टर्न कैरेक्टर शीट ब्लॉक के बगल में पार्टी का लेबल, फ़ील्ड और पूल मिलते हैं। Game Mode कैरेक्टर पोर्ट्रेट के बगल में समेटी जा सकने वाली, सिर्फ़ पढ़ने वाली पार्टी शीट देता है, उसी शीट प्रस्तुति के साथ। स्थायी मान चैट मेटाडेटा (gamePartySheet) में एक बार रहते हैं, gameCharacterCards के बगल में, और उन्नति की रसीदें साझा करते हैं। लाइव पूल rulesetLive की आरक्षित $party एंट्री इस्तेमाल करते हैं; सामान्य रूप में बदले गए कैरेक्टर नाम उससे टकरा नहीं सकते। दोबारा जेनरेट करना जवाब से पहले से शुरू होता है, और स्वाइप चुनना या हटाना मौजूदा हिस्ट्री के ज़रिए स्थायी और लाइव दोनों मान लौटा देता है। party के बिना वाले नियमसेट का व्यवहार पहले जैसा रहता है।

साझा पार्टी बनाना (Capability API 1.163)। पार्टी शीट में lists (अधिकतम 12, कैरेक्टर शीट की सूचियों की तरह लिखी गई), अपना अलग गाइडेड builder, और fromMembers हो सकते हैं: पार्टी के कैरेक्टर से पढ़े जाने वाले अधिकतम 8 पार्टी नंबर फ़ील्ड, हर एक { "field", "count": true } (कितने कैरेक्टर हैं) या { "field", "sum": "<character number field>" } (उनके मानों का जोड़, जैसे Totem dots)। जब भी साझा शीट पढ़ी जाती है, सदस्यों वाले फ़ील्ड कैरेक्टर की उस समय की हालत से निकाले जाते हैं, इसलिए किसी कैरेक्टर का जुड़ना या जाना उन्हें तुरंत बदल देता है। सूचियाँ हों तो पार्टी का summary.lists उनका नाम दे सकता है।

बिल्डर बिल्कुल कैरेक्टर के बिल्डर की तरह लिखा जाता है (पूल, चरण, कीमत वाली पंक्तियाँ, खर्च के ऑफ़र, प्रोफ़ाइल) और पार्टी के अपने फ़ील्ड और सूचियों के विरुद्ध उन्हीं नियमों से जाँचा जाता है। इसके कैटलॉग और पंक्ति कॉपी करने वाले चरण नियमसेट के वे कैटलॉग पढ़ सकते हैं जो पार्टी की सूचियाँ भरते हैं। Game Mode में कोई भी खिलाड़ी साझा शीट का Edit खोलता है, जो गाइडेड सेटअप देता है, और उसे पूरी पार्टी के लिए सेव करता है। हर सेव उस रिविज़न का नाम देता है जिस पर उसे खोला गया था (चैट मेटाडेटा में gamePartySheetRevision, जो हर सेव पर और कहानी के अपने बदलावों पर बढ़ता है): किसी और का सेव पहुँचने से पहले खोला गया सेव अस्वीकार होता है, नई शीट दिखाई जाती है, और खिलाड़ी का ड्राफ़्ट खुला रहता है, इसलिए दोबारा सेव करके उसकी जगह लेना उसका अपना फ़ैसला है।

"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 }]
}