Game design document template: begin met één pagina

Een game design document template hoort eerst op één pagina te passen en pas te groeien wanneer het spel daar aanleiding toe geeft. Begin met vijf blokken: pitch, designpijlers, core loop, lijst met systemen en open vragen. Alles wat erbij komt, van lore tot levelnotities, voeg je toe zodra een playtest bewijst dat het mechanisme echt werkt. Hieronder vind je het sjabloon dat we gebruiken voor tabletop- en indie-videogameprojecten, plus de plekken waar elke sectie het eerst begint te rotten.

Waarom gaan de meeste game design documents al in week drie dood?

De gebruikelijke oorzaak is ambitie. Iemand opent een leeg bestand, plakt een outline van twintig secties uit een forum en besteedt een weekend aan vakjes voor mechanics die nog nooit getest zijn. Na drie weken is het spel verschoven en het document niet. Niemand opent het nog, en niemand geeft dat toe.

De gids van Game Dev Beginner over GDD's noemt het probleem zonder omweg: grote, te gedetailleerde documenten vergen veel werk vooraf, zijn bijna altijd verouderd en werken belemmerend zolang het ontwerp nog beweegt. Hun oplossing is gefaseerd werken. Schrijf eerst een document van één pagina, daarna een van tien pagina's zodra het spel vorm krijgt, en de volledige versie pas wanneer er content wordt gemaakt.

Die fasering is voor tabletopontwerpers nog belangrijker dan voor videogameteams. Een TTRPG-ontwerper is vaak tegelijk schrijver, systeemverantwoordelijke en playtester. Er wacht geen engineer op een specificatie. Het document heeft precies één taak: voorkomen dat je tussen sessie vier en sessie veertig met jezelf in tegenspraak raakt.

Sla het template van veertig pagina's over als je alleen werkt, want je gaat het toch niet bijhouden. Zelfs het Wikipedia-artikel over game design documents noemt een GDD een levend document. Niemand verwacht dat het op dag één af is.

Wat hoort er in een game design document template dat mensen ook echt openen?

Vijf blokken dekken de eerste maand van bijna elk project. Houd elk blok kort genoeg dat je de hele pagina in twee minuten kunt lezen.

1. Pitch. Twee zinnen. Wie speelt het, wat doet die persoon, en waarin verschilt het van het dichtstbijzijnde spel dat hij of zij al heeft.

2. Designpijlers. Drie of vier uitspraken waaraan elke latere beslissing wordt getoetst. "Elk gevecht kost iets blijvends" is een pijler. "Leuk en boeiend" is dat niet.

3. Core loop. Het ding dat de speler steeds herhaalt. In een dungeon crawl kan dat verkennen, kiezen, riskeren en uitgeven zijn. In een politieke campagne misschien intrige, hefboom, gevolg en nasleep.

4. Lijst met systemen. Alleen namen, met één regel per systeem. Geen getallen nog.

5. Open vragen. De nuttigste sectie van de pagina, en precies die sectie die templates vaak weglaten. Schrijf op wat je niet weet, en zet er een datum bij.

Voeg onderaan een changelog toe, al is het maar één regel per week. Wanneer een playtest een idee doodt, noteer dan de beslissing en de reden. Anders probeer je het idee over een half jaar gewoon opnieuw.

Hoe schrijf je designpijlers die een discussie kunnen verliezen?

Een pijler verdient zijn plek door iets te kunnen afwijzen. Kun je geen functie noemen die de pijler zou weigeren, dan is het decoratie.

Test elke pijler met een snijlijst. Neem de drie functies waar je het meest aan hangt en vraag welke pijler elk ervan dient. Een functie die geen enkele pijler dient, gaat op de plank 'misschien later', en die plank mag lang zijn. Dit is het moeilijkste uur van het hele proces, en het is meer waard dan elke sectie uit een template.

Neem als uitgewerkt voorbeeld een campagnewereld met een pest in het midden. Pijler één: schaarste is zichtbaar, dus elke genezingsbron wordt aan tafel bijgehouden. Pijler twee: facties willen verschillende genezingen, dus geen enkele behandeling lost alles op. Pijler drie: de kaart krimpt, dus reizen wordt duurder naarmate het verhaal vordert. Dan komt er een voorstel voor een wederopwekkingsspreuk. Pijler één wijst het af. De beslissing kost tien seconden in plaats van een debat van veertig minuten.

Goed om te weten: pijlers zijn geen marketingslogan. Ze zijn intern en botweg, en ze mogen best een beetje ongemakkelijk klinken.

Waar hoort lore in een GDD, en wanneer staat het in de weg?

Lore is de sectie die het snelst groeit en het minst gelezen wordt. De meeste documenten stoppen het onder een kopje 'Verhaal' onderaan, of laten het het hele bestand overwoekeren. Geen van beide werkt.

Splits het materiaal op wat het doet. Lore die het spel verandert, zoals een wrok van een factie die een quest ontgrendelt of een vloek die een klasse vormgeeft, hoort binnen de systemen die het raakt. Lore die alleen sfeer zet, hoort op een aparte Codex-pagina die niemand hoeft te openen om een ontwerpbeslissing te nemen. De toets is eenvoudig: als het weghalen van de alinea geen mechanic, worp of keuze van de speler verandert, dan hoort ze in de Codex.

Die splitsing beschermt ook de canon. Staat een feit op twee plekken, dan lopen ze op den duur uiteen. Kies per feit één thuisplek en link er vanuit elders naartoe. Canon is een belofte, en elke inconsistentie breekt die.

Ontwerpers van verhaalzware games voegen vaak een korte tijdlijnpagina toe en een tabel met 'wie weet wat'. Beide kosten weinig. Beide besparen hele sessies herwerk wanneer een late onthulling precies goed moet landen.

Welk hulpmiddel moet je template bewaren: Notion, Obsidian of een gewoon document?

Het gereedschap doet er minder toe dan of het document blijft staan op de plek waar je al werkt. Een document in een tabblad dat je nooit opent, is een dood document.

Notion is voor kleine teams de standaardkeuze. Pagina's linken naar elkaar, databases houden facties en items bij, en medewerkers hebben geen installatie nodig. Er bestaan kant-en-klare opties, waaronder een Notion-template voor een GDD met secties voor besturing, gameloop, leveldesign en regels. Het nadeel is vendor lock-in en de verleiding om databases te bouwen voor dingen die die niet nodig hebben.

Obsidian past bij de solo-ontwerper die gewone Markdown-bestanden op de schijf wil. Backlinks doen hier echt werk: link een factie aan elke scène waarin ze voorkomt en je krijgt gratis een consistentiecheck. Het overleeft bovendien het verdwijnen van de leverancier, wat ertoe doet als een project jaren duurt.

GitBook werkt wanneer het document publiek of half-publiek moet zijn, bijvoorbeeld voor een playtestgroep of een crowdfundingpagina voor backers. Een gewoon Google Doc is prima voor een game jam. Sla alles met een zwaar rechtenmodel over, tenzij een uitgever erom vraagt.

Wat je ook kiest, stel één regel vast: het document wordt aan het eind van elke playtest bijgewerkt, voordat iemand naar huis gaat. Tien minuten, zonder uitzondering.

Wat voeg je toe zodra het prototype playtests overleeft?

Na drie of vier sessies met echte spelers verdient het document van één pagina de volgende laag. Voeg secties toe in deze volgorde, en alleen wanneer de pijn zich aandient.

Systeemdetail. Getallen, tabellen en randgevallen. Schrijf die op zodra je een systeem vastlegt, niet ervoor. Bij een TTRPG horen hier de actie-economie, de schadebereiken en de grondstofkosten, plus de regeltekst zoals die er staat. Voor een videogame komen hier de datatabellen die engineers nodig hebben.

Contentlijsten. Items, vijanden, facties en locaties. Gebruik een tabel met één rij per entry en een kolom voor de pijler die elk ervan dient. Rijen die niets dienen, zijn kandidaten om te schrappen.

Interface en flow. De indeling van het personageblad bij tabletop, de schermflow bij digitaal. Schets het met de hand voordat je het in tekst beschrijft.

Productienotities. Mijlpalen, scope, risico's, en wat er in de eerste release zit en wat niet. Als je het resultaat wilt verkopen op DriveThruRPG of Itch.io, beginnen hier ook je paginateksten en prijsaannames.

Een pitch of marketingsectie is een apart document voor een andere lezer. Uitgevers en backers willen marktcontext en unique selling points. Je playtesters willen regels. Door die te mengen krijg je een bestand dat geen van beiden goed bedient.

Kan AI helpen bij het schrijven van een game design document, en waar schiet het tekort?

AI helpt bij concepten van de saaie onderdelen en faalt bij de onderdelen die ertoe doen. Vraag een model om een systeemlijst uit te werken tot een tabel met randgevallen, en je krijgt in een minuut een bruikbare eerste versie. Vraag het om je pijlers te kiezen, en je krijgt pijlers die op die van elk ander spel lijken. Het genereert snel. De beslissingen hebben nog steeds een menselijke blik nodig.

Het praktische gebruik is de consistentiecheck. Voer de Codex en de systeemlijst in en vraag waar twee pagina's elkaar tegenspreken. Tools die gebouwd zijn rond een lange story bible, zoals Novelcrafter, zijn ontworpen voor dit soort kruisverwijzing. Behandel de output als een lijst met verdachten, geen vonnis, en controleer elke melding tegen je eigen pagina's.

Een harde regel: het model schrijft nooit de sectie met open vragen. Die pagina is je eerlijke lijst van wat je niet weet, en die uitbesteden doet het hele doel teniet.

Wat laat je weg, en wat houd je?

Sla het volledige template over tot een mechanic minstens drie echte sessies heeft overleefd. Sla het essay over 'doelgroep' over als je niet vijf echte mensen kunt noemen die het zouden spelen. Sla gedetailleerde monetisatiesecties over voor een spel dat zijn loop nog niet heeft gevonden. Sla elke sectie over die je niet kunt voorstellen als je hem hardop aan een medewerker voorleest.

Houd de pijlers, de open vragen en de changelog. Die drie doen het meeste werk. Een document met alleen die drie, wekelijks bijgewerkt, verslaat een gepolijst bestand van dertig pagina's dat niemand sinds maart nog heeft geopend.

Het template is een belofte aan je toekomstige zelf over wat je hebt besloten en waarom. Houd het kort genoeg om die belofte na te kunnen komen.