Een gamedesign-document schrijven: structuur, tips en veelgemaakte fouten

Hoe schrijf je een gamedesign-document: structuur, tips en veelgemaakte fouten Foto 0
Een gamedesigner is iemand die aan de basis staat van elk spel. Hij creëert het concept en de regels van het spel en deelt zijn taak mee aan elk teamlid. En het belangrijkste gereedschap in de handen van deze specialist is een gamdesign-document.

Game design document, dizdok of kortweg GDD is een volwaardige technische documentatie van het spel, een “bijbel” van het project, een hulpmiddel met de basis die het team zal leiden, zelfs als de game designer op het meest ongelegen moment uit de communicatie “valt”.

De GDD wordt gemaakt door de gamedesigner in samenwerking met afdelingshoofden. Het is noodzakelijk dat elk teamlid (programmeur, artiest, tester, projectmanager, tech support specialist en anderen) de GDD kan openen, er snel in kan navigeren en een duidelijke leidraad voor actie krijgt.

“Een slechte DDD is een DDD die geen antwoord geeft op de belangrijkste vragen: wat? waarom? en waarom? Na het lezen van de documentatie zouden de mensen die betrokken zijn bij de implementatie geen globale vragen meer moeten hebben”, – zegt Evgeny Chuvychin, hoofdontwerper van VOKI Games studio.

In ons artikel vertellen we je hoe je een effectieve GDD opstelt, die in alle opzichten duidelijk en toegankelijk is.

Een gameplay-document dat geen vragen oproept
Waar moet je beginnen met het schrijven van de belangrijkste projecthandleiding? Er zijn veel populaire diensten voor het organiseren van documenten (Confluence, enz.), maar je kunt de informatie ook opmaken in Google Docs.

De reikwijdte van de GDD hangt uitsluitend af van de reikwijdte van het project. Voor een eenvoudig hypercasual spel kunnen 3-5 pagina’s genoeg zijn. Maar als je de implementatie van iets globalers op je hebt genomen, met een groot aantal levels, verhaallijnen, functies en schermen, kan het document aanzienlijk “groeien”. Het belangrijkste is om alles nauwkeurig te beschrijven, niet mooi. Het is tenslotte noodzakelijk dat de navigatie door het document gemakkelijk is, zelfs voor degenen die het voor de eerste keer openen.

Wees erop voorbereid dat de GDD bij elke update van het spel zal veranderen. Sommige processen zullen worden geoptimaliseerd, nieuwe functies en personages zullen verschijnen, manieren om informatie te presenteren zullen veranderen, enzovoort.

Laten we beginnen met de structuur. Deze is voor elk project anders, maar kan onderverdeeld worden in rubrieken:

Inhoudsopgave
Inleiding
Verhalend
Gameplay
Interface
Functies
Analytics
Inhoudsopgave: hier moet je de hiërarchie van het project beschrijven, links om door het document te navigeren.

Inleiding: voeg een korte beschrijving toe van het spel, de positionering, basismechanica, setting, doelpubliek – alles wat helpt om vanaf de eerste pagina te begrijpen hoe de maker het toekomstige product ziet.

Verhaal: geschiedenis van de plaats en gebeurtenissen, overlevering, informatie over personages, quest-elementen.

Gameplay: gameplay met al zijn mechanieken en manieren van interactie met de speler.

Interface: dit deel van het document moet worden ontworpen als een mocap – een flowchart van alle schermen en vensters van je spel: waar en waar je naartoe kunt vanuit elke afzonderlijke pagina. Hiervoor kun je Moqups, InVision, Gliffy of een andere analoog gebruiken. We hebben hier meer geschreven over programma’s die het werk van een gameontwerper kunnen vereenvoudigen.

Schrijven, afkorten (c)
We raden aan om de structuur waar mogelijk op te splitsen in opsommingstekens en lijsten.

Bijvoorbeeld:

Een speler wordt gevraagd om een nieuw meubelstuk in een herenhuis te plaatsen
1.1 Als de speler genoeg sterren heeft, koopt hij het meubelstuk. 1.2 Als de speler genoeg sterren heeft, koopt hij het meubelstuk.

1.2 Als de speler niet genoeg sterren heeft, wordt hij gevraagd een level te voltooien om het voorwerp te vinden.

Functies: functies van voorwerpen, grondstoffen en andere functies, chips van het spel.

Graphics: kunstgids, formaten, tekstverwerking en andere standaardisatie, karakter- en vensterkenmerken. Een belangrijk punt hier is om onnodige beschrijving van animaties te vermijden. Bijvoorbeeld:

Nee: “het personage springt ter plekke op met zijn handen omhoog, geschrokken van het geluid in de open haard”;

Ja: “het personage wordt bang”.

Het is belangrijk om de taak duidelijk te schetsen en de nuances aan de animator over te laten – hij weet hoe hij de emoties van het personage zo realistisch mogelijk kan maken.

Analytics: A/B-tests, statistieken van verschillende bronnen en tracking metrics.

Hoe schrijf je een gamdizayn document: structuur, tips en populaire fouten Foto 1
Nog enkele nuttige tips:

voel je vrij om informatie te illustreren met afbeeldingen. Het is vreemd om een venster of een personage te beschrijven zonder er een afbeelding van bij de tekst te voegen;
Grote bestanden met verwijzingen (afbeeldingen, video’s) maken het document zwaarder en de kwaliteit van deze bestanden gaat aanzienlijk achteruit. Afbeeldingen kunnen worden geüpload naar een site voor het delen van bestanden of in een apart document worden geplaatst, en video’s kunnen worden geüpload naar YouTube, waarbij alleen verwijzingen naar de GDD worden toegevoegd;
Zinnen moeten beknopt en informatief zijn. Denk eraan – we schrijven geen roman, maar een gids voor actie;
Er moet orde in het document zitten: de tekst moet netjes georganiseerd zijn en elke referentie moet op de juiste plaats staan met een handtekening.
Om terug te komen op het onderwerp van een goede GDD: bij het maken en bewerken ervan moeten we onszelf in de schoenen van andere teamleden en spelers plaatsen en onszelf afvragen: “Kan deze paragraaf verkeerd geïnterpreteerd worden?”, “Zal de persoon bijkomende vragen hebben?”, “Is het document gemakkelijk te navigeren?”.

Je moet echter niet het perfecte diddok najagen. Laat het optimaliseren en updaten parallel aan de ontwikkeling van je project!