Hur man planerar ett spelutvecklingsprojekt

En av de mest komplicerade aspekterna av spelutveckling är planering. Vissa hävdar att små indieprojekt inte behöver detta steg; de behöver helt enkelt arbeta med projektet tills det är klart. Detta är långt ifrån sant.

Inledande planering

Den konstruktionsram som läggs vid projektets ursprung kommer att avgöra kursen för hela projektets utveckling. Det är viktigt att komma ihåg vid detta steg att ingenting är i sten, men du bör försöka vara så exakt som möjligt.

Funktionslista

Först analysera designdokumentet och fastställa spelets krav. Dela sedan upp varje krav i en lista med funktioner som kommer att behövas för att genomföra kravet.

Bryta ner uppgifterna

Ta varje funktion och arbeta med dina ledningar inom varje område (konst, animering, programmering, ljud, nivådesign, etc.) för att dela upp dem i uppgifter för varje avdelning (en grupp eller person, beroende på teamets storlek).

Tilldela uppgifter

Ledningen för varje grupp bör sedan skapa uppskattningar av initialtidskrav för varje uppgift och tilldela dem till teammedlemmar. När detta är klart bör ledningen samarbeta med teamet för att säkerställa att uppskattningarna är korrekta och rimliga.

beroenden

Projektledaren måste sedan ta alla uppskattningar av uppgifterna och placera dem i ett programhanteringsprogram för programvara, antingen Microsoft Project eller Excel (de två långvariga branschstandarderna) eller något av de nyare val som är tillgängliga för smidig projektledning.

När uppgifterna har lagts till måste projektledaren titta på uppgifterna och matcha beroenden mellan team för att säkerställa att tidpunkten för att skapa en funktion inte har omöjliga relationer som förhindrar att den slutförs inom nödvändiga tidsramar. För att till fullo implementera ett racingspel skulle du inte schemalägga kodningen för däckens hållbarhet innan fysiksystemet slutförts. Du skulle inte ha några ramar för att basera däckkoden på.

schemaläggning

Det är här saker och ting blir särskilt komplicerade, men i första hand blir behovet av projektledning tydligare.

Projektledaren tilldelar uppskattade start- och slutdatum för varje uppgift. I traditionell projektplanering slutar du med en övergripande "vattenfall" -vy som visar tidslinjen för projektets slutförande och beroenden som kopplar uppgifterna.

Det är viktigt att komma ihåg att ta hänsyn till glidning, anställdas sjuk tid, oväntade förseningar på funktioner osv. Detta är ett tidskrävande steg, men det kommer snabbt att ge dig en uppfattning om exakt hur mycket tid projektet kommer att ta att slutföra.

Vad man ska göra med uppgifterna

Genom att titta på denna projektplan kan du bestämma om en funktion kommer att bli kostsam i tid (och därför pengar) och fatta beslut om funktionen är nödvändig för att spelet ska lyckas. Du kan bestämma att det är mer meningsfullt att försena en funktion för att uppdatera eller till och med en uppföljare.

Att spåra hur länge du har arbetat med en funktion är också användbart för att avgöra om det är dags att antingen prova en ny teknik för att lösa problemet eller klippa funktionen till förmån för projektet.

milstolpar

Ofta används projektplanering för att skapa milstolpar. Milstolpar anger när ett visst element av funktionalitet, en tidsperiod att arbeta på projektet eller en procentandel av uppgifterna har slutförts.

För intern projektspårning är milstolpar användbara för planeringsändamål och för att ge teamet specifika mål att sträva efter. När man arbetar med en förläggare bestämmer milstolpar ofta hur och när utvecklingsstudion betalas.

Slutanmärkningar

Projektplanering betraktas av många som en olägenhet, men du kommer nästan alltid att upptäcka att utvecklare som planerar projekt i god tid och träffar sina milstolpar är de som lyckas på lång sikt.