Hoe een game-ontwikkelingsproject te plannen

Een van de meest gecompliceerde aspecten van game ontwikkeling is aan het plannen. Sommigen zouden beweren dat kleine indieprojecten deze stap niet nodig hebben; ze moeten gewoon aan het project werken totdat het klaar is. Dit is verre van waar.

Het ontwerpkader dat bij de oorsprong van het project is gelegd, bepaalt de koers voor de ontwikkeling van het hele project. Het is belangrijk om bij deze stap te onthouden dat niets vaststaat, maar je moet proberen zo nauwkeurig mogelijk te zijn.

Analyseer eerst het ontwerpdocument en bepaal de vereisten van de game. Splits vervolgens elke vereiste op in een lijst met functies die nodig zijn om de vereiste te implementeren.

Neem elke functie en werk met uw leads op elk gebied (kunst, animatie, programmeren, geluid, niveauontwerp, enz.) om het op te splitsen in taken voor elke afdeling (een groep of persoon, afhankelijk van de grootte van uw team).

De leider van elke groep moet vervolgens voor elke taak initiële schattingen van de tijdvereisten maken en deze aan teamleden toewijzen. Nadat dit is voltooid, moet de lead met het team samenwerken om ervoor te zorgen dat de schattingen correct en redelijk zijn.

De projectmanager moet dan alle taakschattingen nemen en deze ook in een projectbeheersoftwarepakket plaatsen Microsoft Project of Excel (de twee oude industriestandaarden) of een van de nieuwere keuzes die beschikbaar zijn voor een agile project beheer.

Zodra de taken zijn toegevoegd, moet de projectmanager naar de taken kijken en afhankelijkheden tussen teams matchen om ervoor te zorgen dat de de timing van het maken van een functie heeft geen onmogelijke relaties waardoor deze niet binnen de vereiste tijd kan worden voltooid kaders. Om bijvoorbeeld een racegame volledig te implementeren, zou je de codering van de bandduurzaamheid niet plannen voordat het natuurkundig systeem is voltooid. Je zou geen raamwerk hebben om de bandencode op te baseren.

Hier wordt het bijzonder ingewikkeld, maar waar de behoefte aan projectmanagement in de eerste plaats duidelijker wordt.

De projectmanager wijst voor elke taak een geschatte start- en einddatum toe. Bij traditionele projectplanning krijgt u een trapsgewijze 'waterval'-weergave, die de tijdlijn voor het voltooien van het project en de afhankelijkheden die de taken met elkaar verbinden, laat zien.

Het is van cruciaal belang om te onthouden dat rekening moet worden gehouden met slip, ziekteverlof van werknemers, onverwachte vertragingen bij functies, enz. Dit is een tijdrovende stap, maar het geeft u snel een idee van hoeveel tijd het project precies in beslag zal nemen.

Door naar dit projectplan te kijken, kunt u bepalen of een functie in de tijd (en dus geld) kostbaar zal zijn en besluiten of de functie nodig is om het spel te laten slagen. U zou kunnen besluiten dat het logischer is om een ​​functie uit te stellen om te updaten - of zelfs een vervolg -.

Het is ook handig om bij te houden hoe lang je aan een functie hebt gewerkt, om te bepalen of het tijd is om een ​​nieuwe techniek uit te proberen om het probleem op te lossen of om de functie te schrappen ten behoeve van het project.

Een veelvuldig gebruik van projectplanning omvat het creëren van mijlpalen. Mijlpalen geven aan wanneer een bepaald element van functionaliteit, een periode van werken aan het project of een percentage van de taken is voltooid.

Voor interne projecttracering zijn mijlpalen nuttig voor planningsdoeleinden en voor het geven van specifieke doelen aan het team. Bij het werken met een uitgever bepalen mijlpalen vaak hoe en wanneer de ontwikkelstudio wordt betaald.

Projectplanning wordt door velen als hinderlijk ervaren, maar je zult bijna altijd merken dat ontwikkelaars die projecten ruim van tevoren plannen en hun mijlpalen bereiken, degenen zijn die op de lange termijn slagen.