Game design document mall: en sida först, sedan mer

En game design document mall ska få plats på en sida först och växa först när spelet förtjänar det. Börja med fem block: pitch, designpelare, kärnloop, systemlista och öppna frågor. Allt annat, från lore till nivåanteckningar, läggs till när en playtest visar att mekaniken faktiskt håller. Nedan följer mallen vi använder för bordsrollspel och oberoende tv-spelsprojekt, och var varje sektion brukar börja ruttna.

Varför dör de flesta GDD:er redan i vecka tre?

Det vanliga felet är ambition. Någon öppnar en tom fil, klistrar in en 20-punkters disposition från ett forum och lägger en helg på att fylla i rutor för mekaniker som ingen har testat. Vid vecka tre har spelet flyttat sig men dokumentet har inte gjort det. Ingen öppnar det längre, och ingen erkänner det.

Game Dev Beginners guide till GDD:er säger det rakt ut: stora, alltför detaljerade dokument kräver tungt arbete i förväg, är nästan alltid inaktuella och blir hämmande när designen fortfarande rör sig. Lösningen är att etappindela. Skriv ett dokument på en sida först, ett på tio sidor när spelet tar form, och den fullständiga versionen först när innehållet ska produceras.

Det spelar större roll för bordsrollspelsdesigners än för tv-spelsteam. En rollspelsdesigner är ofta författare, systemansvarig och playtestare på en gång. Ingen ingenjör väntar på en specifikation. Dokumentet har exakt ett jobb: att hindra dig från att motsäga dig själv mellan session fyra och session fyrtio.

Hoppa över 40-sidorsmallen om du arbetar ensam. Du kommer inte att underhålla den. Även standarddefinitionen kallar en GDD för ett levande dokument, vilket betyder att ingen förväntar sig att den är färdig första dagen.

Vilka delar gör en game design document mall som folk faktiskt öppnar?

Fem block täcker första månaden i nästan varje projekt. Håll varje block så kort att du kan läsa hela sidan på två minuter.

• Pitch. Två meningar. Vem spelar, vad gör de, och vad skiljer det från det närmaste spelet de redan äger.

• Designpelare. Tre eller fyra påståenden som varje senare beslut prövas mot. "Varje strid kostar något permanent" är en pelare. "Roligt och engagerande" är det inte.

• Kärnloop. Det spelaren upprepar. I ett dungeon crawl kan det vara utforska, välj, riskera, spendera. I en politisk kampanj kan det vara intrig, inflytande, konsekvens, fallout.

• Systemlista. Bara namn, med en rad per system. Ange inga siffror ännu.

• Öppna frågor. Den mest användbara sektionen på sidan, och den som mallar brukar utelämna. Skriv ner vad du inte vet, och datera det.

Lägg till en ändringslogg längst ner, även om den bara är en rad per vecka. När en playtest dödar en idé, skriv ner dödandet och skälet. Annars kommer framtida du att prova samma idé igen.

Hur skriver du designpelare som kan förlora ett argument?

En pelare förtjänar sin plats genom att stoppa något. Om du inte kan nämna en funktion som pelaren skulle förkasta är den bara dekoration.

Testa varje pelare med en skärlista. Ta de tre funktioner du är mest fäst vid och fråga vilken pelare var och en tjänar. En funktion som inte tjänar någon går till hyllan "kanske senare", och den hyllan får vara lång. Det här är den svåraste timmen i hela processen, och den är värd mer än någon mallsektion.

Här är ett genomarbetat exempel från en kampanjvärld med en pest i centrum. Pelare ett: knappheten syns, så varje läkande resurs spåras vid bordet. Pelare två: fraktionerna vill ha olika botemedel, så ingen enskild behandling löser allt. Pelare tre: kartan krymper, så resor blir dyrare i takt med att berättelsen går framåt. Nu kommer ett förslag på en återupplivningsbesvärjelse. Pelare ett säger nej. Beslutet tar tio sekunder i stället för en debatt på fyrtio minuter.

Värt att veta: pelare är inget marknadsföringsslagord. De är interna och tvärt formulerade, och de kan låta lite otrevliga. Det är helt okej.

Pelarna bör också få ändras, men bara på ett sätt: genom ett uttalat beslut som går att spåra i ändringsloggen. En pelare som tyst byts ut halvvägs genom produktionen är ett av de vanligaste skälen till att två halvfärdiga versioner av samma spel hamnar i samma projekt. Skriv datum och skäl, och stryk den gamla formuleringen i stället för att låta den ligga kvar bredvid den nya. Då vet du i efterhand varför ett beslut togs, och det är ofta just den informationen som saknas när ett spel ska skrivas om.

Var hör lore hemma i en GDD, och var står den i vägen?

Lore är den sektion som växer snabbast och läses minst. De flesta dokument begraver den under en rubrik "Berättelse" längst ner, eller låter den sluka hela filen. Ingetdera fungerar.

Dela upp materialet efter vad det gör. Lore som ändrar spelet, till exempel en fraktions agg som låser upp ett uppdrag eller en förbannelse som formar en klass, bor inne i de system den påverkar. Lore som bara sätter stämningen bor på en separat Codex-sida som ingen behöver öppna för att fatta ett designbeslut. Testet är enkelt: om du tar bort stycket och varken en mekanik, ett tärningsslag eller ett spelarval ändras, hör det hemma i Codex.

Uppdelningen skyddar också kanonen. När ett faktum bor på två ställen glider de isär. Välj ett hem för varje faktum och länka dit från alla andra ställen. Kanon är ett löfte, och varje motsägelse bryter det.

Designers som arbetar med berättelsetunga spel lägger ofta till en kort tidslinjesida och en förteckning över vem som vet vad. Båda är billiga. Båda sparar hela sessioner av omarbetning när en sen avslöjande måste landa rätt.

Vilket verktyg ska hålla din mall: Notion, Obsidian eller ett vanligt dokument?

Verktyget spelar mindre roll än om dokumentet lever kvar där du redan arbetar. Ett dokument i en flik du aldrig öppnar är ett dött dokument.

Notion är standardvalet för små team, eftersom sidor länkar till varandra, databaser håller föremål och fraktioner, och medarbetare inte behöver någon installation. Färdiga mallar finns, bland annat en Notion-mall för GDD med sektioner för kontroller, spelloop, nivådesign och regler. Haken är inlåsning och frestelsen att bygga databaser för saker som inte behöver dem.

Obsidian passar den ensamma designern som vill ha vanliga Markdown-filer på disken. Bakåtlänkar gör verkligt jobb här: länka en fraktion till varje scen den dyker upp i så får du en konsistenskontroll på köpet. Det överlever även att leverantören försvinner, vilket spelar roll om projektet pågår i många år.

GitBook fungerar när dokumentet ska vara publikt eller halvpublikt, till exempel för en playtestgrupp eller en crowdfunding-sida för backers. Ett vanligt Google-dokument duger för en game jam. Undvik allt med tung behörighetsmodell om inte en förläggare begär det.

Oavsett val, sätt en regel: dokumentet uppdateras i slutet av varje playtest, innan någon går hem. Tio minuter, inga undantag.

Ett praktiskt sätt att komma igång är att kopiera de fem blocken till en tom sida och fylla i varje rubrik med en mening, även om meningen är fel. Den felaktiga meningen är användbar, eftersom den visar exakt vad du tror och kan ersättas med något bättre så fort en playtest säger emot. Ett tomt block säger ingenting alls.

Vad lägger du till när prototypen klarar playtesten?

Efter tre eller fyra sessioner med riktiga spelare förtjänar sidan sitt nästa lager. Lägg till sektioner i den här ordningen, och bara när smärtan dyker upp.

Systemdetaljer. Siffror, tabeller, kantfall. Skriv dem när du låser ett system, inte före. I ett rollspel hör handlingsekonomi, skadeintervall och resurskostnader hit, tillsammans med regeltexten så som den är skriven. I ett tv-spel lägger du till de datatabeller som ingenjörerna kommer att läsa.

Innehållslistor. Föremål, fiender, fraktioner, platser. Använd en tabell med en rad per post och en kolumn för vilken pelare varje post tjänar. Rader som inte tjänar något är kandidater för att skäras bort.

Gränssnitt och flöde. Layout för karaktärsblad i ett bordsspel, skärmflöde i ett digitalt. Skissa för hand innan du beskriver det i text.

Produktionsanteckningar. Milstolpar, omfattning, risker, vad som ingår i första releasen och vad som inte gör det. Om du planerar att sälja resultatet på DriveThruRPG eller Itch.io är det här också där sidtexten och prisantagandena börjar.

En pitch- eller marknadsföringssektion är ett separat dokument för en separat läsare. Förläggare och backers vill ha marknadskontext och unika försäljningsargument. Dina playtestare vill ha regler. Blandar du dem blir filen något som tjänar ingen av dem.

Kan AI hjälpa dig skriva en game design document, och var brister den?

Den hjälper med utkast till de tråkiga delarna och misslyckas med det som spelar roll. Be en modell utveckla en systemlista till en tabell med kantfall, så får du ett godtagbart första utkast på en minut. Be den välja dina pelare, så får du pelare som låter som alla andra spel. Den genererar snabbt. Besluten behöver fortfarande en mänsklig genomgång.

Den praktiska användningen är konsistenskontroll. Mata in Codex och systemlistan, och fråga var två sidor motsäger varandra. Verktyg byggda kring en lång berättelsebibel, som Novelcrafter, är gjorda för just den typen av korsreferens. Behandla utdata som en lista över misstänkta, inte som en dom, och kontrollera varje flagga mot dina egna sidor.

En hård regel: modellen skriver aldrig sektionen med öppna frågor. Den sidan är din ärliga lista över det du inte vet, och att lämna över den förstör hela poängen.

Vad ska du hoppa över, och vad ska du behålla?

Hoppa över den fullständiga mallen tills en mekanik har klarat minst tre riktiga sessioner. Hoppa över essän om målgrupp om du inte kan namnge fem verkliga personer som skulle spela. Hoppa över detaljerade monetariseringssektioner för ett spel som inte har hittat sin loop. Hoppa över varje sektion du inte kan föreställa dig att läsa högt för en medarbetare.

Behåll pelarna, de öppna frågorna och ändringsloggen. De tre gör det mesta av jobbet. Ett dokument med bara dem, uppdaterat varje vecka, slår en polerad fil på 30 sidor som ingen har öppnat sedan i mars.

Mallen är ett löfte till ditt framtida jag om vad du bestämde och varför. Håll den tillräckligt kort för att du ska kunna hålla löftet.