Een van de meest gecompliceerde aspecten van game-ontwikkeling is planning. Sommigen 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 in steen is gezet, maar je moet proberen zo nauwkeurig mogelijk te zijn.
Analyseer eerst het ontwerpdocument en bepaal de vereisten van het spel. 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 in 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 leiding van elke groep moet vervolgens voor elke taak de initiële benodigde tijdschattingen maken en deze aan teamleden toewijzen. Nadat dit is voltooid, moet de leiding samenwerken met het team om ervoor te zorgen dat de schattingen correct en redelijk zijn.
De projectmanager moet vervolgens alle taakramingen nemen en deze in een softwarepakket voor projectbeheer plaatsen, hetzij Microsoft Project of Excel (de twee oude industriestandaarden) of een van de nieuwere keuzes die beschikbaar zijn voor wendbaar projectbeheer..
Nadat de taken zijn toegevoegd, moet de projectmanager naar de taken kijken en afhankelijkheden tussen teams matchen om ervoor te zorgen dat de timing van het maken van een functie geen onmogelijke relaties heeft die verhinderen dat deze binnen de nodige tijdframes wordt voltooid. Als u bijvoorbeeld een racegame volledig wilt implementeren, zou u de codering van de duurzaamheid van de banden niet plannen voordat het fysieke systeem is voltooid. U zou geen kader hebben om de bandcode op te baseren.
Dit is waar dingen bijzonder gecompliceerd worden, maar waar de behoefte aan projectmanagement in de eerste plaats duidelijker wordt.
De projectmanager wijst geschatte start- en voltooiingsdata toe voor elke taak. In de traditionele projectplanning eindigt u met een trapsgewijze weergave "waterval", die de tijdlijn toont voor de voltooiing van het project en de afhankelijkheden die de taken koppelen.
Het is van cruciaal belang om te onthouden dat u rekening houdt met uitglijden, ziekteverzuim 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 zal kosten om te voltooien.
Door naar dit projectplan te kijken, kunt u bepalen of een functie op tijd duur zal zijn (en dus geld) en kunt u besluiten of de functie nodig is om de game te laten slagen. Je zou kunnen beslissen dat het uitstellen van een functie om bij te werken - of zelfs een vervolg - logischer is.
Ook is het handig om bij te houden hoe lang je aan een functie hebt gewerkt om te bepalen of het tijd is om een nieuwe techniek te proberen om het probleem op te lossen of om de functie af te snijden ten voordele 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 projecttracking zijn mijlpalen nuttig voor planningsdoeleinden en om het team specifieke doelen te geven om naar te streven. Bij het werken met een uitgever bepalen mijlpalen vaak hoe en wanneer de ontwikkelende studio wordt betaald.
Projectplanning wordt door velen als een overlast beschouwd, maar je zult bijna altijd merken dat ontwikkelaars die projecten ruim van tevoren plannen en hun mijlpalen halen, degenen zijn die op de lange termijn slagen.