Sådan skriver du brætspilsregler: En designers komplette guide

De fleste brætspilsdesignere behandler regelbogen som en eftertanke. Dette er bagvendt - en regelbog er det første indtryk, den første barriere og den mest almindelige årsag til, at spillere giver op, før spillet starter. Hver time, du bruger på at forfine mekanikken, kan blive undermineret af en regelbog, der forvirrer snarere end præciserer. Denne vejledning dækker, hvordan professionelt regelbogsdesign ser ud, hvorfor de fleste regelbøger fejler i deres primære job, og hvorfor den bedste løsning på en dårlig regelbog nogle gange er slet ingen regelbog.

Kerneproblemet med de fleste regelbøger

Den centrale fejl i næsten enhver dårligt skrevet regelbog er front-loading. De fleste regelbøger forsøger at forklare alt, før spilleren har spillet noget. Resultatet er information uden kontekst — spillere læser om "Nuclear Port indkomstskalering", før de forstår, hvad en Nuclear Port er, hvorfor de vil have en, eller hvad indkomst betyder i praksis.

Frontindlæste regler er regler, som ingen læser. Forskning viser konsekvent, at de fleste brætspilsspillere rapporterer at læse regelbogen som den aktivitet, de frygter mest før en session. Mange grupper udpeger en udpeget "regellæser", som absorberer regelbogen og derefter genforklarer den for andre verbalt. Læg mærke til implikationen: regelbogen fejler allerede sit primære job. Den er skrevet for at én person skal videresende til andre, ikke for at spillere skal læse direkte. Hvis din regelbog kræver en menneskelig tolk for at fungere, skal den omdesignes fra bunden.

Rettelsen er strukturel. Ikke bedre skrivning, ikke flere eksempler - en fundamentalt anderledes organisation, der matcher, hvordan spillere faktisk lærer: ved at gøre, med lige nok information til at tage den næste handling.

Struktur: Den tredelte regelbog

En velstruktureret regelbog har tre adskilte dele med forskellige formål, forskellige målgrupper og – ideelt set – forskellige fysiske sektioner eller dokumenter.

Del 1: Mål- og vindertilstand (maks. 1 side). Spillere skal vide, hvor de skal hen, før de bekymrer sig om, hvordan de kommer dertil. Vindbetingelsen er ikke en eftertanke - det er rammen, der giver hver efterfølgende regel sin mening. Hvorfor betyder territorium noget? Fordi at kontrollere mere territorium hjælper dig med at vinde. Hvorfor betyder indkomst betydning? Fordi indkomst finansierer den ekspansion, der vinder. Uden gevinstbetingelsen etableret først, flyder hver efterfølgende regel fri for kontekst.

Del 2: Minimum for at spille (2-3 sider). Ikke alle regler - nok regler til at fuldføre tur 1. Alt andet kan vente. Spillere lærer ved at gøre; Reglerne for drejning 4 leveres bedst efter drejning 3, ikke før drejning 1. Dette afsnit skal besvare et spørgsmål: hvad gør jeg på min første tur? Det skal ikke svare: hvad sker der, hvis to spillere begge har hære ved siden af en Nuclear Port, der er besat af en tredje spillers diplomati-token?

Del 3: Reference (så længe det er nødvendigt). Komplet regler for kantsager, præciseringer og variantregler. Ingen læser dette, før de spiller - det er til opslag midt i spillet, når der opstår en usædvanlig situation. Formater det i overensstemmelse hermed: Overskrifter skal være søgbare, kantsager skal være tydeligt mærket, og strukturen skal understøtte tilfældig adgang frem for sekventiel læsning.

Neutronium: Parallel Wars tager denne tredelte logik til sin naturlige konklusion med Recovered Memories-systemet — Del 1 og 2 leveres i spillet, ét univers ad gangen, gennem spillets egen tutorial-struktur. Spillere møder aldrig del 3, før de har spillet nok til at forstå, hvorfor edge cases betyder noget. Regelbogen bliver selve spillet.

Eksempel-første skrivning

Hver regel bør føre med eksemplet, derefter generaliseringen. Dette er det modsatte af, hvordan de fleste designere skriver regler, fordi designere tænker i abstraktioner og skriver i abstraktioner. Spillere tænker i konkrete handlinger og har brug for konkrete eksempler først.

Den første version er teknisk korrekt. Den anden version kan læses ved den første gennemgang. Den første version kræver, at spilleren har fire betingede klausuler i arbejdshukommelsen samtidigt. Den anden version giver dem en handling, de skal tage og en pege på den situation, der måske slet ikke opstår i sving 1.

Skriv eksemplet først, derefter reglen. Peg derefter på, hvor den fulde detalje bor. Læsere, der har brug for detaljerne, vil følge referencen. Læsere, der endnu ikke har brug for detaljerne, vil springe det over og fortsætte med at spille - hvilket er præcis, hvad du ønsker. Regler, der stopper spillet, er regler, der afslutter sessioner.

Progressiv offentliggørelse

Progressiv afsløring er princippet om kun at introducere regler, når spillere har brug for dem - ikke at forhåndsindlæse hele regelsættet, før en enkelt tur er taget. Princippet: indfør først Mekaniker B, når Mekaniker A har været brugt mindst én gang. Spillere, der har udført en handling én gang, har den kognitive ramme til at forstå dens interaktioner. Spillere, der aldrig har udført handlingen, har ingen sådan ramme.

Dette er det samme princip, som driver god software-onboarding. Gmail forklarer ikke filtre, før du har sendt en e-mail. Photoshop forklarer ikke blandingstilstande, før du har oprettet et lag. Komplekse værktøjer introducerer avanceret funktionalitet, efter at grundlæggende funktionalitet er etableret, ikke før.

I praksis bør din første spillesession bruge cirka 20 % af dine regler. Ved session 5 skulle spillerne møde 80 % af reglerne. De resterende 20 % er avanceret mekanik, som afslappede spillere måske aldrig har brug for - og det er fint. Et spil, hvor afslappede spillere får en komplet og tilfredsstillende oplevelse ved at bruge 80 % af mekanikken, er et veldesignet spil. Et spil, hvor spillere skal forstå 100 % af mekanikken, før de kan spille Turn 1, er et spil med et regelbogsproblem.

Ordlisteproblemet

Hvert spilspecifikke udtryk har brug for en definition. Dette er bordindsats, ikke valgfrit. Fejlen er ikke at undlade at definere termer – det er at definere dem i den rækkefølge, designeren tænkte på dem, hvilket sjældent er den rækkefølge, en ny spiller vil støde på dem.

Retningen: Definer vilkår i den rækkefølge, en ny spiller vil støde på dem under deres første session. Hvis en spiller støder på "Nn" (Neutronium valuta) før "Nuclear Port", skal du først definere Nn. Hvis de vil støde på "segment" før "hex", skal du definere segment først. Alfabetisk rækkefølge er for encyklopædier; play-order er til spilordlister.

Den sekundære fejl: at begrave ordlistedefinitioner i sektioner i stedet for at samle dem ét sted. Definer hvert udtryk i ordlisten, og brug derefter dette udtryk konsekvent hele vejen igennem. Definer ikke termer inline i regeltekst - dette er kilden til de "tre betingelser i en parentes" problem, der gør regler uigennemtrængelige. Neutronium har en selvstændig ordliste på /ordliste med hvert spiludtryk i afspilningsrækkefølge, krydsreferencet til mekanikafsnittet, hvor hvert udtryk optræder i kontekst.

Afprøvning af din regelbog

Regelbogen er en testbar designartefakt, ikke et færdiggjort dokument. Test det på samme måde, som du tester din mekanik: med definerede succeskriterier, observerbar adfærd og data, du handler på.

Kernetesten: Se nogen lære dit spil fra din regelbog uden at hjælpe dem. Svar ikke på spørgsmål. Må ikke afklare. Peg ikke på den rigtige side. Bare se på. Hvert øjebliks forvirring - hver genlæsning, hver pause, hver forkert handling - er en regelbogsfejl. Den fejl har en placering og en årsag. Find begge dele.

Spor følgende under hver regelbogstestsession:

• Den tid, der gik, før den første tur begynder
• Antal gange hver side blev genlæst
• Antal stillede spørgsmål (hvert spørgsmål er en fiasko, selvom svaret teknisk set er i regelbogen)
• Specifikke sektioner, der forårsagede genlæsninger eller spørgsmål
• Første ulovlige handling foretaget (reglen, der regulerede det, blev ikke forstået)

Dette er dine fejl. Behandl dem som fejl: find hovedårsagen, ret den specifikke fejl, test igen. En regelbog, der genererer nul genlæsninger og nul spørgsmål i tre på hinanden følgende testsessioner med nye spillere, er en regelbog, der er klar til at sendes.

Hvornår skal regelbogen fjernes

Den mest radikale løsning på regelbogsproblemet er slet ingen front-loaded regelbog. Det lyder drastisk. Det er også den konklusion, som playtestdata førte til for Neutronium: Parallel Wars.

Playtesting viste, at forudlæsning af regelbogen var det største enkeltpunkt for frafald i spiller-onboarding-tragten. Spillere, der læste regelbogen før de spillede, gav op før de spillede. Spillere, der sprang over regelbogen og startede spillet, blev i timevis. Konklusionen er kontraintuitiv, men klar: regelbogen hjalp ikke spillere med at lære spillet. Det forhindrede dem i at starte.

Recovered Memories in-game tutorial-systemet leverer regler på det tidspunkt, hvor det er relevant - efterhånden som spillet udfolder sig, ikke før det begynder. Univers 1 lærer sine fem mekanikker gennem leg. Universe 2 introducerer yderligere tre mekanikker i sammenhæng. Ingen spiller har nogensinde haft brug for at læse en regelbog før deres første session, fordi spillet lærer sig selv. Regelbogen eksisterer som et referencedokument for spillere, der ønsker at verificere kantsager - ikke som en forudsætning for at starte.

Hvis dine playtestdata viser, at læsning af regelbog er dit højeste frafaldspunkt, så overvej om selve regelbogen er problemet. Svaret er normalt: ja. Se også: Sådan designes et brætspil for den bredere designproces, der producerer disse indsigter.

Ofte stillede spørgsmål