Share
Elke indie-ontwikkelaar of -team heeft zich afgevraagd hoe het ontwikkelingsproces het best kan worden beheerd. Is het verplicht om gedetailleerde documentatie te gebruiken, zoals het legendarische spelontwerpdocument (GDD)? Wat zijn de meest voorkomende fouten en hoe kunnen deze worden voorkomen?
Voor diegenen die naar antwoorden op deze vragen hebben gezocht, wil ik de ervaring van ons team met het creëren van onze GDD delen.
Veel gameontwerpers onthouden zich van het cultiveren van ontwerpdocumenten en het organiseren van ideeën. Ik kan me niet voorstellen hoe deze ontwikkelaars door die tijden heen komen dat ze gehinderd worden door slecht werkende code, tijdelijke kunst en botsende mechanica, terwijl ze zich proberen te herinneren waarom het was dat ze eerst zichzelf onderwierpen om een spel te maken in de eerste plaats.
Het hebben van een doordacht ontwerpdocument voor games kan in deze tijden fungeren als uw kruk. Het laat je de geweldige ideeën en concepten zien die je de hele nacht wakker hielden toen je voor het eerst aan je spel begon, en, misschien nog belangrijker, welke uit het spel moeten worden gesneden om je leven gemakkelijker te maken, of opnieuw bewerkt om te maken jouw inspanningen de moeite waard.
Een spelontwerp document fungeert als een nexus en een hub om verbinding te maken en elk aspect van een spel te vermelden. Het bestaat uit geschreven beschrijvingen, afbeeldingen, grafieken, grafieken en lijsten met informatie die relevant zijn voor elk ontwikkelingssegment, en wordt vaak georganiseerd aan de hand van welke functies in het spel zullen zijn, en legt duidelijk uit hoe ze allemaal in elkaar zullen passen.
Het creëren van een GDD helpt de ontwerper van uw team bij het begrijpen van wat de essentie van het spel is en bij de geplande reikwijdte van zijn overkoepelende wereld en gameplay. En als alle spelelementen in één overzichtelijk document staan, kan de ontwerper zijn visie eenvoudig overbrengen op de rest van het team, terwijl het ook helpt zwaktes of ontbrekende componenten op te sporen die het spel mogelijk nodig heeft.
De GDD zou moeten dienen als uw masterchecklist. Het zal het document zijn dat je in de lucht gooit tijdens het vieren na het voltooien van alle secties en het beëindigen van je spel.
Omdat een GDD vol beschrijvingen is, is het een ideale bron voor alle PR- en marketingfronten, met concepten die de esthetiek en aantrekkingskracht van het spel weergeven die al zijn geschreven en klaar om te kopiëren en te plakken.
De vaardigheden van potentiële werknemers kunnen snel worden beoordeeld als gekwalificeerd of niet door te kijken naar hun inloggegevens naast de overeenkomstige secties van hun posities in het document..
Als fondsenwerving voor uw team in het vaandel staat, is het van cruciaal belang om een goed samengestelde GDD te hebben voor beleggers om te kijken en de risico's van uw ontwikkeling te bepalen, evenals uw vermogen om uw beloften waar te maken.
Het creëren en naleven van een game-ontwerpdocument is als het planten van een zaadje en het zien groeien tot een boom in de loop van de ontwikkeling. Je hebt je eerste voorbereiding, cultivatie en uiteindelijk het gruwelijke en slopende werk van de oogst.
Een veelgemaakte fout is dat u niet al uw teamleden de juiste tuingereedschap geeft om uw spel te realiseren. De GDD zal ervoor zorgen dat iedereen samenwerkt, zodat je niet merkt dat je programmeur en artiest de tak afsnijden waar ze op staan.
Proberen alles in één keer te beschrijven
Het is niet nodig om elke functie en monteur gedetailleerd in de eerste versie te vermelden. Dit is onmogelijk als je met een klein team aan een complexe game werkt. Het schetsen van de belangrijkste knooppunten van gameplay en kernelementen zal u inzicht geven in wat er moet worden gedaan, maar u moet verwachten ze een voor een te vullen, in de tijd.
Het instellen van speldoelen met deadlines kan voor sommige ontwikkelaars onaangenaam lijken. Deadlines maken deel uit van de saaie 9-tot-5-levensstijl, dus veel mensen hebben een natuurlijke aversie tegen hen.
Het instellen van deadlines is echter hoe je ervoor zorgt dat je game gemaakt wordt en niet voor altijd onvoltooid blijft zitten in een map op je bureaublad. Dit soort doelen zijn mijlpalen op weg naar vooruitgang en het een voor een doorgeven ervan is een duidelijke aanwijzing dat u iets goed doet. Elk is een reden om te vieren.
Deadlines zijn een basiscomponent van de planning waarmee u de prestaties van uw team en uzelf kunt volgen. Het helpt bij het nemen van beslissingen die in de werkelijkheid zijn geworteld en bouwt uiteindelijk een momentum en ethiek op die gezond zijn voor het team als geheel en de individuen daarbinnen.
Er is ruimte in de GDD voor basisbeschrijvingen die betrekking hebben op gameplay, verhaallijnen en belangrijke coderingstaken. Naarmate de ontwikkeling vordert, voegt u meer details toe aan deze secties. Tijdens het maken en testen van de game moet u specifieke technische details toevoegen of bijwerken telkens wanneer een functie wordt geïmplementeerd of gewijzigd. Op deze manier heb je nooit een build met elementen die je niet terug kunt traceren naar de GDD, waardoor ontbrekende links van ideeën, code of kunst worden gecreëerd. Het kan ook nuttig zijn om informatie toe te voegen over de moeilijkheid om bepaalde taken uit te voeren, en of deze volledig in het spel zijn geïntegreerd of mogelijk verdere revisie vereisen.
Tijdens dit hele proces moeten uw eerste concepten doorschijnen naar steeds gedetailleerdere beschrijvingen van elk facet dat uw functies bevatten. Dit helpt om concrete mijlpalen te maken die gemakkelijk te navigeren zijn en terug te gaan om te zien waar ze vandaan komen en waar ze naartoe moeten.
Naarmate de GDD blijft groeien en meer gefinaliseerd wordt, is het nog steeds belangrijk om het up-to-date te houden. Dit elimineert situaties waarin teamleden iets doen zonder te kunnen rechtvaardigen waarom ze tijd hebben besteed om ze te doen, wat cruciaal is voor de crunch-tijd.
Persoonlijk heb ik een onverklaarbare primaire angst om te verdrinken in een berg gedrukte documentatie. Dit zou een echte nachtmerrie worden als ik alle oude versies van onze GDD voor elk teamlid zou moeten houden.
Waarom zouden we onszelf zo moeten martelen in het tijdperk van digitale technologie? Er zijn tal van gratis online diensten zoals Google Docs of Trello waarmee u alle wijzigingen kunt opslaan en alle opmerkingen van uw team in realtime kunt bekijken.
Bij het starten van de GDD is het normaal om ingepakt te raken in concepten. Achtergronden, inleidingen en belangrijke beschrijvingen helpen het spel vorm te geven en vorm te geven. Naarmate u functies gaat testen en implementeren, moeten deze concepten verfijnder, gespecificeerd en gedetailleerd worden. Het behouden van de juiste organisatie zal steeds kritischer worden naarmate uw GDD aankomt in gewicht en dichtheid.
Begin in de conceptfase, waar je ideeën brainstormt en ze allemaal op papier zet. Dit zou spannend moeten zijn! Het zal ook als een routekaart dienen, zodat je onderweg je doelen en visie niet uit het oog verliest. Wanneer de aantrekkelijkheid van bepaalde game-elementen hun glans verliest of je in een greppel brengt, is het misschien tijd om je oorspronkelijke concept te herwerken om ervoor te zorgen dat je een bevredigende finishlijn bereikt.
Tegen de achtergrond van ontwikkeling, als je eenmaal een gung-ho-team aan boord hebt, zullen discussies en game-builds helpen het document te vormen en te ordenen tot een gebruiksvriendelijke en forse gids voor iedereen. Er is op dit moment nog steeds ruimte om te experimenteren met nieuwe concepten en ideeën, maar ze moeten in toom worden gehouden met enkele van uw eerste documentatie.
Het huisgedeelte van de ontwikkeling is waar uw spelontwerpdocument u urenlang frustratie en verdriet zal besparen. Naarmate je dichterbij komt, zou je GDD langzaamaan moeten uitgroeien tot een stenen tablet, met functies en mechanica die zich in meer permanente game-builds bevinden, allemaal bij elkaar gehouden door kunst die zeker in meerdere iteraties is gemaakt om te voldoen aan de specificaties van het document. Het document moet helpen om alle wielen van het team op de grond te houden, met een goed zicht op realistische verwachtingen bij het leveren van het spel.
Het is niet nodig om een absoluut complete GDD te hebben voordat u met de ontwikkeling begint. Maar de GDD moet voltooid zijn voor de komende 10 dagen of twee weken na het huidige werk van uw team - en de relevante delen van het document moeten zo gedetailleerd mogelijk zijn.
Delen van de GDD moeten tijdens het hele ontwikkelingsproces worden gewijzigd en aangepast, soms zelfs in de laatste dagen vóór de release. Het kan lijken op een rampzone als de inhoud niet goed is getrimd. Als je bang bent om tekst te verwijderen die verouderd is, knip en plak je deze in een addendum of een apart document. Dit laat het hoofdgedeelte van de GDD relevant voor de huidige staat van ontwikkeling, zonder alle afleidingen van vorige iteraties.
Stop nooit teamleden die nieuwe ideeën indienen. Ideecreatie is een van de meest lonende delen van ontwikkeling en moet te allen tijde worden aangemoedigd. Uw teamleden moeten zich ontwikkelen, wetende dat veel van deze concepten worden geknipt en nooit in het spel worden opgenomen, maar dit moet hen er niet van weerhouden te dromen! Niemand weet welke ideeën in eerste instantie tot de beste resultaten leiden, dus het genereren van nieuwe en innovatieve ideeën moet een hoofdbestanddeel zijn van uw discussies en dienovereenkomstig gevierd worden.
Het toezicht op de GDD mag alleen door één teamlid worden uitgevoerd. Ze identificeren de belangrijkste ideeën waarop moet worden geconcentreerd en snijden de minder belangrijke ideeën.
Het aanmoedigen van actieve feedback is dan belangrijk, omdat andere teamleden niet de kans hebben om hun ideeën direct aan het document toe te voegen.
De meeste ontwikkelingsproblemen bestaan uit een harde buitenkant van miscommunicatie en een zacht interieur van niet weten hoe ze te compenseren en te corrigeren. Deze barrières kunnen worden weggenomen met nauwgezet onderhoud van de GDD en duidelijke, beknopte documentatie, en dit kan het best worden bereikt als een persoon die verantwoordelijkheid op zich neemt.
Wees consistent met letterstijlen en gebruik uniforme kop- en inspringingen, interpunctie en opmaak. Het creëren van een legende of sleutel om uit te leggen wat specifieke gekleurde hoogtepunten betekenen, kan een lange weg afleggen naar minder verwarring en minder tijd besteden aan het overbrengen van de stadia van de implementatie van verschillende functies..
Hoe eenvoudiger en duidelijker u de taal in de GDD bewaart, hoe beter uw team het zal begrijpen.
Het is belangrijk om het schrijven helder en bondig te houden en uw team moet u actief feedback geven over de presentatie en duidelijkheid van de GDD. Een heen-en-weer-dynamiek resulteert in een meer samenhangende ontwikkelervaring met overkoepelende voordelen, waaronder een gedefinieerde kunststijl, minder communicatiefouten en minder stressvolle documentatie en kantoorwerk.
Maar het belangrijkste is dat de GDD een weerspiegeling is van je teamcultuur, gemaakt in het formaat dat je het beste vindt en het meest aantrekkelijk is voor jou en degenen met wie je werkt.
Niemand zou ooit kunnen zeggen dat ze iets niet goed begrepen hebben of iets correct hebben gedaan, vanwege een gebrek aan referentiemateriaal in de GDD.
Visuele materialen en referenties spelen een sleutelrol in het proces van het overbrengen van ideeën. Sommige moeilijke concepten kunnen in minder tijd worden uitgelegd met visuele hulpmiddelen zoals grafieken en concept art. Dit zal ervoor zorgen dat elk teamlid de informatie begrijpt die aan hen wordt doorgegeven, wat hen in ruil zal helpen om hun ontwikkeltaken sneller af te ronden.
Je moet jezelf niet beperken tot droge tekst. (Als je dat doet, zal je lang wachten voordat iedereen verloofd is en de belangrijkste ideeën begrijpen!) Probeer de emoties van de spelers en de ervaringen die het spel zou kunnen cultiveren te beschrijven.
Het bijhouden van een GDD klinkt misschien technisch, maar je moet niet bang zijn om je hart te verscheuren en het naar het document te gooien. Laat je emotie en passie bloeden. Stel je voor hoe je de speler wilt laten voelen en schrijf die aspiraties op naast de beschrijvingen van je functies. Dit helpt bij het cultiveren van een collectief bewustzijn in je team over wat je spel probeert uit te dragen aan de speler - en laten we eerlijk zijn, gevoelens moeten enthousiasme achter zich hebben als je wilt dat ze door iemand anders begrepen worden.
Stel de prioriteiten van taken en functies in, documenteer hun deadlines en beheer de uitvoering ervan. Je kunt niet absoluut alle ideeën ontwikkelen die je team en je geest zullen voorstellen, dus (nadat je een aantal hebt weggelaten), moet je hun prioriteiten stellen en op zijn minst een planning maken voor de implementatie ervan..
Een goed verzorgde GDD zorgt voor een uitstekende, geprioriteerde lijst met taken die door uw team moeten worden voltooid. Niet alle functies in een GDD maken het tot de laatste game. Met dit in gedachten, moet u beslissen welke functies voorrang hebben op andere, en u moet ze plannen voor implementatie en testen voordat die anderen.
Denk goed na over wat essentieel is voor je spel, en wat er mogelijk is gezien het vaardigheidsniveau van je team, en gebruik die informatie om je productie te begeleiden.
Een solide GDD kan ook helpen nieuwe teamleden in het project te helpen en ze net zo enthousiast te maken als u bent.
Aangezien een volledig geschetste GDD kan resulteren in wat een overdreven angstaanjagende game lijkt te zijn, is het goed om te onthouden dat meer dan één persoon zijn specifieke eigenschappen zal invullen. Door uw teamleden taken toe te wijzen in de GDD, wordt deze krachtiger en blijft iedereen op dezelfde pagina. Iedereen kan naar het document springen om te zien wat er is voltooid, welke taken voor hen liggen en voor de rest van het team, en waarom ze aan hun huidige taak werken..
Het schrijven van iets in een gedeelde GDD mag de discussie met het team niet minimaliseren of elimineren, het moet dienen om de teamdiscussie te vergroten en uw communicatiedynamiek te verbeteren. Het is belangrijk dat iedereen duidelijk begrijpt hoe jij (en de andere teamleden) elke functie van het spel voorstellen.
Ideeën snijden kan moeilijk en zenuwslopend zijn, maar het is een inherent proces voor het maken van games. Ervoor zorgen dat een open, vrije discussie deel uitmaakt van de ontwikkeling, zal de inherente spanningen hier helpen verlichten, zonder leden ervan te weerhouden creatief te zijn.
Ik vond veel goede ideeën die het spel virtueel speelden, zowel voor als tijdens het maken van het spel. Dit geeft natuurlijk geen garantie dat die ideeën tijdens de ontwikkeling en het testen in het spel zullen komen, maar vooral in de beginfase is het een goede manier van brainstormen..
Hoewel het goed is om binnen een team een opwinding op te wekken, is het net zo belangrijk om je speldoelen in de realiteit te verankeren. Mechanica en complexe vijandige en vlakke gedragingen zien er altijd geweldig uit op papier, maar de realiteit heeft een manier om de grootsheid van bepaalde spelelementen te corroderen, en dit zou te verwachten zijn.
Gevolgen van updates en wijzigingen zijn in sommige situaties bijna niet te voorzien van tevoren, dus onthoud gewoon dat het uw taak is om te proberen de hoeveelheid verbouwing te beperken die moet worden uitgevoerd wanneer zich wijzigingen voordoen. Als je het gebruikelijk maakt om nieuwe ideeën in gedachten te spelen voordat je ze op papier zet, heb je een grotere kans om ontwikkelingsdoelen te blijven wortelen in realistische verwachtingen.
Ons team is multinationaal. We leven over de hele wereld, in verschillende tijdzones, en dit maakt het onmogelijk om gedrukte versies van documenten voor iedereen te gebruiken, en het is moeilijk om real-time gesprekken te hebben. Het gebruik van tools zoals Skype (voor gesprekken), Google Drive (voor het delen van bestanden), Google Docs (voor samenwerken aan documenten en het delen van de GDD) en FlockDraw (voor digitale tekeningen) kan echt helpen met uitleg en discussies..
Als je merkt dat het nodig is om een GDD te onderhouden voor de productie van je spel, moet je goed kijken naar hoe je je ontwikkelt. Er zijn bijna zeker momenten waarop real life en full-time banen het maken van spellen in de weg staan, of je implementatie van functies en mechanica werkt gewoon niet.
Op de stormachtige zeeën van game-ontwikkeling kan een gezonde GDD soms dienen als een stevig en solide vaartuig, en zelfs als een reddingsboot. Het is een gedetailleerd dagboek van je worstelingen en triomfen, een verzameling gedachten en ideeën waar je op terug kunt vallen tijdens moeilijke tijden. Je zou kunnen merken dat het verbeteren van de kwaliteit van de GDD ook doorwerkt in de rest van de ontwikkeling, waardoor de lat voor je team over het algemeen hoger wordt. Het moet dienen als een stevige hub om teamdiscussies te vergemakkelijken en nieuwe, nog grotere ideeën te genereren. Tegelijkertijd kan het deze concepten in realistische controle houden.
De voordelen van dit soort efficiëntie lijken misschien klein als ze individueel worden bekeken, maar gedurende de lange ontwikkelingsgang bouwt het een prachtig soort momentum op. Uiteindelijk zou dit type document u en uw team moeten stimuleren, dwingen en inspireren om af te maken wat u bent begonnen. Het moet je laten zien dat je spel een plan heeft dat kan worden gerealiseerd.
En nadat u klaar bent met spelen, staat uw GDD als een bewijs van al uw harde werk en inspanningen, de achter-de-schermen van een uitgebreide ervaring waar iedereen van kan genieten..
Accentsconagua