Sådan planlægges et spiludviklingsprojekt

En af de mest komplicerede aspekter af spiludvikling planlægger. Nogle vil hævde, at små indie-projekter ikke har brug for dette trin; de skal blot arbejde på projektet, indtil det er gjort. Dette er langt fra sandt.

Designrammen, der er lagt til projektets oprindelse, bestemmer forløbet for hele projektets udvikling. Det er vigtigt at huske på dette trin, at intet er sat i sten, men du skal forsøge at være så nøjagtig som muligt.

Først skal du analysere designdokumentet og bestemme spilets krav. Derefter skal du opdele hvert krav i en liste over funktioner, der er nødvendige for at implementere kravet.

Tag hver funktion og arbejd med dine kundeemner i hvert område (kunst, animation, programmering, lyd, niveau design osv.) for at opdele det i opgaver for hver afdeling (en gruppe eller person, afhængigt af størrelsen på dit team).

Lederen for hver gruppe skal derefter oprette estimater for det første tidsbehov for hver opgave og tildele dem til teammedlemmer. Når dette er afsluttet, skal ledelsen samarbejde med teamet for at sikre, at estimaterne er korrekte og rimelige.

Projektlederen skal derefter tage alle opgørelsesestimater og placere dem i en softwarepakke til projektstyring Microsoft Project eller Excel (de to langvarige industristandarder) eller et hvilket som helst af de nyere valg, der er tilgængelige for smidigt projekt ledelse.

Når opgaverne er tilføjet, skal projektlederen se på opgaverne og matche afhængigheder mellem holdene for at sikre, at tidspunktet for oprettelse af en funktion har ikke umulige forhold, der forhindrer, at den afsluttes inden for den nødvendige tid rammer. For eksempel for fuldt ud at implementere et racerspil ville du ikke planlægge kodning af dækets holdbarhed før færdiggørelsen af ​​fysiksystemet. Du vil ikke have nogen rammer til at basere dækkoden på.

Det er her ting bliver særligt kompliceret, men hvor behovet for projektstyring i første omgang bliver mere tydeligt.

Projektlederen tildeler estimerede start- og afslutningsdatoer for hver opgave. I traditionel projektplanlægning ender du med en kaskaderende "vandfald" -visning, der viser tidslinjen for projektets afslutning og de afhængigheder, der forbinder opgaverne.

Det er vigtigt at huske at faktor i glidning, sygdomstid for medarbejdere, uventede forsinkelser på funktioner osv. Dette er et tidskrævende trin, men det vil hurtigt give dig en idé om nøjagtigt, hvor lang tid projektet vil tage at gennemføre.

Ved at se på denne projektplan kan du bestemme, om en funktion vil være dyr i tide (og derfor penge) og træffe beslutninger om, hvorvidt funktionen er nødvendig for, at spillet skal lykkes. Du kan muligvis beslutte, at det er mere fornuftigt at forsinke en funktion til opdatering - eller endda en efterfølger -.

Det er også nyttigt at spore, hvor længe du har arbejdet på en funktion, til at bestemme, om det er tid til enten at prøve en ny teknik til at løse problemet eller skære funktionen til fordel for projektet.

En hyppig brug af projektplanlægning indebærer oprettelse af milepæle. Milepæle angiver, hvornår et bestemt element af funktionalitet, en periode med arbejde på projektet eller en procentdel af opgaverne er afsluttet.

Ved intern projektsporing er milepæle nyttige til planlægningsformål og til at give teamet specifikke mål at sigte mod. Når man arbejder med et udgiver, bestemmer milepæle ofte, hvordan og hvornår udviklingsstudiet skal betales.

Projektplanlægning betragtes af mange som en gener, men du finder næsten altid, at udviklere, der planlægger projekter i god tid og rammer deres milepæle, er dem, der lykkes på lang sigt.