# Game design document template: begin met één pagina URL: https://auxworld.app/nl/journal/game-design-document-template Type: blog Locale: nl Published: 2026-10-27 Updated: 2026-10-29 --- > Een game design document template op één pagina voor indie-ontwerpers: zeven blokken, wat je moet schrappen en hoe je werelden documenteert die uit een prompt ontstaan. Je hebt een game design document template nodig dat op één pagina past, en dat pas groeit als de game er reden toe geeft. Begin met zeven blokken: pitch, core loop, speler-werkwoorden, wereld, systemen, scope en open vragen. Vul ze op één avond in. Schrap alles wat je deze maand niet in een prototype kunt testen. De rest van deze post is het template zelf, plus de delen die de meeste gidsen overslaan. ## Waarom de meeste game design documents in week twee sneuvelen Stel je het GDD van 40 pagina's voor. Mooie omslag, een inhoudsopgave, een lore-hoofdstuk dat niemand gevraagd heeft. Na twee weken is het prototype afgedreven en is het document een fossiel. Dat is de echte fout. Niet ontbrekende secties, maar een bestand dat ophoudt waar te zijn. Een GDD is een werkinstrument, eerder een changelog dan een bijbel. Als het document en de build elkaar tegenspreken, verliest het document, en stopt iedereen met het openen ervan. De vraag is dus niet: wat moet een game design document bevatten? De vraag is: wat is het kleinste document dat ik eerlijk bijgehouden krijg? ![Whiteboardschets van een core loop, vier vakjes verbonden met pijlen](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/auxworld/2026-10/7165e4-core.webp) ## Het one-page game design document template Kopieer deze outline. Elk blok krijgt twee tot vijf regels, bij de eerste ronde nooit meer. - **Pitch.** Eén zin die een vreemde kan herhalen. "Een coöp-havenstad waar het tij elke nacht de kaart herschrijft." - **Core loop.** Wat de speler steeds opnieuw doet, in minder dan een minuut. Teken het als een cirkel van werkwoorden. - **Speler-werkwoorden.** Vijf tot acht acties. Geen features. Werkwoorden: klimmen, handelen, verbergen, forken, repareren. - **Wereld.** Plek, sfeer, drie regels die altijd waar zijn. Weer telt als regel. - **Systemen.** De twee of drie mechanismen die de werkwoorden interessant maken. Economie, stealth, crafting, wat de loop ook draagt. - **Scope.** Wat er uitkomt, wat wordt geschrapt, wat een stretchdoel is. Zet bij elk onderdeel een datum. - **Open vragen.** De eerlijke lijst met dingen die je nog niet weet. Dit blok is het waardevolste op de pagina. Let op wat ontbreekt: monetisatie, een marketingplan, een achtergrondverhaal van personages. Die horen in aparte bestanden, geschreven zodra het prototype de loop bewijst. De meeste gepubliceerde templates beginnen daarmee, en dat is precies waarom die documenten nooit af komen. Heb je een langere structuur nodig voor een team dat sign-off moet geven, dan legt de [GitBook-gids over het schrijven van een game design document](https://www.gitbook.com/blog/how-to-write-a-game-design-document) de klassieke hoofdstukindeling uit. Het advies om te beginnen met een versie van één pagina en details toe te voegen zodra prototypes dat rechtvaardigen, is precies het juiste instinct. ## Wat een core loop-sectie echt moet zeggen Laat bijvoeglijke naamwoorden weg. Schrijf de loop als een zin met een timer. `Zoek 40 seconden naar bergingsmateriaal -> breng het naar de pier -> ruil voor één upgrade -> het tij verschuift, de kaart verandert -> herhaal`Lees het hardop. Klinkt één stap dood? Dan heb je je eerste prototypetaak gevonden. Klinkt elke stap prima, maar kun je niet zeggen waarom de speler terugkomt, dan mist de loop een reden. Zet dat als open vraag, in plaats van het onder proza te begraven. Een test die ik graag gebruik: de loopzin moet op één tekstregel passen. Heeft hij een alinea nodig, dan zijn het twee loops, en ontwerp je eigenlijk twee games. ## Welke secties mag je zonder spijt schrappen? Wees meedogenloos. Een solo- of tweepersoonsproject kan dit meestal op dag één laten vallen: - **Volledige personagebiografieën.** Houd een naam, een verlangen en een fout bij. Schrijf meer zodra het personage in een build verschijnt. - **Gedetailleerde levelbeschrijvingen.** Beschrijf de levelregels, niet de kamers. - **Platform- en monetisatiehoofdstukken.** Parkeer ze tot de loop werkt. - **Art bible.** Drie referentiebeelden en een palet. Meer niet. Sla dit over als je een jamgame in 72 uur uitbrengt: de pitch, de loop en de werkwoorden zijn dan je hele document. De volledige lijst is wel de moeite waard als je een uitgever hebt, een consolecertificeringsproces, of contractors die om middernacht geen vragen kunnen stellen. De [Unity game design document template-pdf](https://connect-prd-cdn.unity.com/20201215/83f3733d-3146-42de-8a69-f461d6662eb1/Game-Design-Document-Template.pdf) is een degelijke referentie voor hoe mechanieken en objectgedrag worden vastgelegd zodra er een team bij betrokken is. Lees hem als een catalogus, niet als een checklist. ## Waar bewaar je het document, en wat verandert je engine? Op de plek waar je het dagelijks bewerkt. Dat klinkt vanzelfsprekend, tot je ziet hoeveel GDD's in een pdf staan die niemand kan vergelijken. Kies een tool met koppen, een database voor taken en versiegeschiedenis. Een notitie-app met een database werkt goed, omdat je open vragen en je scopelijst getrackte items kunnen worden in plaats van opsommingen die verrotten. Platte Markdown in de repo is het andere goede antwoord. Het leeft naast de code, het vergelijkt schoon, en niemand vergeet het bij te werken tijdens een pull request. Het nadeel: niet-technische teamleden raken het niet aan. Wat je ook kiest, zet de one-pager bovenaan en link naar diepere bestanden. De pagina is de kaart. De bestanden zijn het terrein. ![Laptop met een gegenereerd mistig dorp naast een notitieboek met ontwerpschetsen](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/auxworld/2026-10/21d264-world.webp) De engine verandert er wel iets aan. Hij bepaalt welke werkwoorden goedkoop zijn en welke duur, dus je systemen- en scopeblok moeten dat gewoon zeggen. Zit je in een volledige 3D-engine met een grote asset-pijplijn, dan heeft de scope een regel per assetcategorie nodig, want content is waar planningen sterven. Wil je een open-sourceengine zonder royalty-berekeningen, dan wordt je scopeblok eenvoudiger: geen licentieregel, maar wel een echte notitie over welke features je zelf gaat bouwen. En is de game 2D met strakke mechanieken, dan draagt het loopgedeelte bijna alles. Kleine, leesbare documenten passen bij kleine, leesbare games. Het punt is niet om hier een winnaar te kiezen. Het punt is dat "Engine en tools" geen wegwerpregel is. Die moet noteren wat de engine makkelijk maakt, wat hij pijnlijk maakt, en wat je weigert te bouwen. ## Hoe schrijf je een GDD voor een wereld die zichzelf genereert? Dit is het gat in bijna elk template. Ze gaan ervan uit dat je elke boom met de hand plaatst. Wanneer een wereld uit een prompt wordt gegenereerd, verandert het ontwerpdocument van vorm. Je specificeert geen kamers meer. Je specificeert randvoorwaarden: wat er in elke wereld die de engine kan maken waar moet zijn, en wat mag variëren. Voeg twee blokken toe aan de one-pager: - **Wereldrandvoorwaarden.** De regels die niet mogen breken. "Elke nederzetting heeft water binnen twee minuten lopen." "Geen doodlopende questlocaties." - **Prompt-zaden.** De exacte prompts die je gebruikte, als onderdeel van het document opgeslagen. Zo ziet een zaad er in de praktijk uit: `een mistige havenstad bij laagwater, één vuurtoren, smalle trappen, touwbruggen tussen de daken, nog niemand te zien`Bewaar de prompt, bewaar wat er terugkwam, en noteer wat je zou forken. De prompt is tegelijk je specificatie en je changelog. Fork hem, verander één ding, kijk wat er gebeurt, en schrijf dan de delta in het document. Die gewoonte maakt van een gegenereerde wereld iets waar je over kunt redeneren, en het geeft teamgenoten iets concreets om te bekritiseren in plaats van een gevoel. Een waarschuwing: de kwaliteit van generatie verschilt sterk per tool, en sommige functies zitten in de hele branche nog in beta. Noteer de versie en de datum bij elk zaad, zodat je weet of een resultaat herhaalbaar is of een gelukkige worp. ## Een snelle manier om de loop te testen voor je meer schrijft Dit is de avondworkflow die ik op een nieuw idee zou draaien: - Schrijf de one-pager in 30 minuten. Bewerk hem daarna niet. - Zet de pitch en drie wereldregels om in een prompt, en genereer een eerste versie van de ruimte. - Loop de core loop door die ruimte, met de hand of in een ruw prototype. - Markeer elke stap die dood voelde. Die gaan in de open vragen. - Schrap één werkwoord. Altijd één. De schrapping is het deel dat mensen overslaan. Een ontwerpdocument dat alleen maar groeit, is een wensenlijst. Een werkwoord verwijderen dwingt de overige om meer gewicht te dragen, en meestal laat het zien welk systeem het echte werk deed. ![Prikbord met indexkaarten verbonden met rode draad, één kaart wordt vastgeprikt](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/auxworld/2026-10/0dac63-cards.webp) ## Hoe houd je het document levend na week twee? Drie gewoontes, geen daarvan heldhaftig. **Dateer elke open vraag.** Is een vraag ouder dan drie weken en nog open, beantwoord hem dan, of geef toe dat je hem vermijdt. **Werk het document bij in dezelfde zitting als de build.** Niet later. Later is hoe het fossiel ontstaat. Een bewerking van twee regels aan het eind van een sessie kost een minuut. **Houd onderaan een lijst met gedoode ideeën bij.** Dat bespaart je het opnieuw debatteren over hetzelfde mechanisme elke maand, en het is verrassend motiverend om te zien hoeveel je hebt uitgebracht door nee te zeggen. Als iemand nieuw het project binnenkomt, geef hem eerst de versie van één pagina en kijk waar hij in de war raakt. Elke verwarde vraag is een ontbrekende regel in het document. ## Wat zouden wij echt gebruiken? Ben je alleen of met z'n tweeën, dan is de one-pager van zeven blokken plus een lijst met prompt-zaden genoeg voor de eerste maand. Heb je een team, houd de one-pager dan als voordeur en voeg aparte bestanden toe voor systemen en content zodra het prototype die rechtvaardigt. Heb je een uitgever, geef hem de lange versie, maar hou je one-pager als de versie die je vertrouwt. Open vanavond een leeg blad en schrijf de pitch. Één zin. Dan de loop, met een timer erop. Lukt dat niet binnen een half uur, dan is het idee nog een droom. Dat is nuttig om te weten voordat je er een maand aan besteedt. ## FAQ ### Wat is een game design document template? Een herbruikbare outline om vast te leggen wat je game is, hoe hij speelt en wat je gaat bouwen. De bruikbaarste versies beginnen met een pitch, core loop, speler-werkwoorden, wereld, systemen, scope en open vragen, en blijven kort genoeg om bij te houden. ### Hoe lang moet een game design document zijn? Voor een solo- of tweepersoonsproject is één pagina meestal genoeg voor de eerste maand. Groei pas als het prototype een extra sectie rechtvaardigt, niet omdat het er professioneel uit moet zien. ### Wat laat je weg in een beginnend GDD? Monetisatie, marketingplannen, uitgebreide personagebiografieën en een volledige art bible. Die zijn nuttig, maar meestal pas nadat de kernloop in een prototype werkt. ### Hoe schrijf je een core loop? Schrijf de loop als één zin met een tijdslimiet, bijvoorbeeld 'verzamel 40 seconden, ruil, herhaal'. Heeft de zin meer dan één regel nodig, dan zijn het waarschijnlijk twee loops. ### Waar bewaar je een game design document? Waar je het dagelijks bewerkt. Een notitie-app met koppen, taken en versiegeschiedenis werkt goed. Platte Markdown in de repo past bij ontwikkelaars die de hoofdbijdragers zijn. ### Hoe documenteer je een wereld die uit een prompt wordt gegenereerd? Leg wereldrandvoorwaarden vast die altijd moeten gelden, en sla de exacte prompts op met de versie en datum van de tool. Zo kun je varianten forken en de verschillen in het document bijhouden. ### Hoe houd je het document actueel? Dateer open vragen, werk het document bij in dezelfde sessie als de build, en houd een lijst met geschrapte ideeën bij.