Hvordan planlegge et spillutviklingsprosjekt

En av de mest kompliserte sidene ved spillutvikling planlegger. Noen vil hevde at små indie-prosjekter ikke trenger dette trinnet; de trenger ganske enkelt å jobbe med prosjektet til det er gjort. Dette er langt fra sant.

Designrammen som er lagt til prosjektets opprinnelse vil avgjøre forløpet for hele prosjektets utvikling. Det er viktig å huske på dette trinnet at ingenting er satt i stein, men du bør prøve å være så nøyaktig som mulig.

Først må du analysere designdokumentet og bestemme spillets krav. Del deretter hvert krav i en liste over funksjoner som vil være nødvendige for å implementere kravet.

Ta hver funksjon og jobb med lederne dine på hvert område (kunst, animasjon, programmering, lyd, nivåutforming osv.) for å dele det opp i oppgaver for hver avdeling (en gruppe eller person, avhengig av størrelsen på teamet ditt).

Lederen for hver gruppe skal deretter lage innledende tidskravestimater for hver oppgave og tilordne dem til teammedlemmer. Etter at dette er fullført, bør ledelsen samarbeide med teamet for å sikre at estimatene er riktige og rimelige.

Prosjektlederen må da ta alle oppgavestimatene og plassere dem i en prosjektstyringsprogramvarepakke Microsoft Project eller Excel (de to langvarige industristandardene) eller noen av de nyere valgene som er tilgjengelige for smidig prosjekt ledelse.

Når oppgavene er lagt til, må prosjektlederen se på oppgavene og matche avhengigheter mellom team for å sikre at tidspunktet for å opprette en funksjon har ikke umulige forhold som forhindrer at den fullføres innen nødvendig tid rammer. For å implementere et racingspill, vil du for eksempel ikke planlegge koding av dekkets holdbarhet før fysikksystemet er fullført. Du har ingen rammer for å basere dekkkoden på.

Det er her ting blir spesielt kompliserte, men der behovet for prosjektledelse i utgangspunktet blir tydeligere.

Prosjektleder tildeler estimerte start- og fullføringsdatoer for hver oppgave. I tradisjonell prosjektplanlegging ender du opp med en fossende "fossefall" -visning, som viser tidslinjen for fullføring av prosjektet og avhengighetene som knytter oppgavene til.

Det er avgjørende å huske å faktor i utglidning, syketid for ansatte, uventede forsinkelser på funksjoner, etc. Dette er et tidkrevende skritt, men det vil raskt gi deg en ide om nøyaktig hvor mye tid prosjektet vil ta å fullføre.

Ved å se på denne prosjektplanen, kan du bestemme om en funksjon vil bli kostbar i tide (og derfor penger) og ta beslutninger om funksjonen er nødvendig for at spillet skal lykkes. Du kan bestemme at det er mer fornuftig å utsette en funksjon for å oppdatere - eller til og med en oppfølger -.

Det er også nyttig å spore hvor lenge du har jobbet med en funksjon for å avgjøre om det er på tide å enten prøve en ny teknikk for å løse problemet eller kutte funksjonen til beste for prosjektet.

En hyppig bruk av prosjektplanlegging innebærer å lage milepæler. Milepæler indikerer når et visst element av funksjonalitet, en tidsperiode med å jobbe på prosjektet eller en prosentandel av oppgavene er fullført.

For intern prosjektsporing er milepæler nyttige for planleggingsformål og for å gi teamet spesifikke mål å sikte mot. Når du jobber med et forlag, bestemmer milepæler ofte hvordan og når utviklingsstudioet skal betales.

Prosjektplanlegging blir av mange sett på som en plage, men du vil nesten alltid oppleve at utviklere som planlegger prosjekter i god tid og treffer sine milepæler, er de som lykkes på lang sikt.