Vienas iš sudėtingiausių žaidimo plėtra planuoja. Kai kurie teigia, kad mažiems indie projektams šio žingsnio nereikia; jiems tereikia dirbti projektą, kol jis bus baigtas. Tai toli gražu nėra tiesa.
Pradinis planavimas
Projekto pradžia išdėstyta projektavimo programa nulems viso projekto raidos eigą. Šiame žingsnyje svarbu atsiminti, kad nieko nėra akmenyje, tačiau turėtumėte stengtis būti kuo tikslesni.
Funkcijų sąrašas
Pirmiausia išanalizuokite dizaino dokumentą ir nustatykite žaidimo reikalavimus. Tada suskirstykite kiekvieną reikalavimą į funkcijų, kurių reikės reikalavimui įgyvendinti, sąrašą.
Užduočių laužymas
Pasinaudokite kiekviena funkcija ir dirbkite su savo klientais kiekvienoje srityje (menas, animacija, programavimas, garsas, lygio dizainas ir kt.), kad būtų galima suskirstyti į užduotis kiekvienam skyriui (grupei ar asmeniui, atsižvelgiant į jūsų komandos dydį).
Užduočių skyrimas
Tada kiekvienos grupės vadovas turėtų sudaryti pradinius kiekvienos užduoties laiko sąmatas ir jas priskirti komandos nariams. Kai tai bus baigta, vadovas turėtų dirbti su komanda, kad įsitikintų, jog įverčiai yra teisingi ir pagrįsti.
Priklausomybės
Tada projekto vadovas turi paimti visas užduočių sąmatas ir sudėti jas į projekto valdymo programinės įrangos paketą „Microsoft Project“ arba „Excel“ (du ilgalaikiai pramonės standartai) arba bet kurį iš naujesnių pasirinkimų, galimų judriam projektui valdymas.
Pridėjęs užduotis, projekto vadovas turi peržvelgti užduotis ir suderinti priklausomybes tarp komandų, kad įsitikintų, jog funkcijos sukūrimo laikas neturi neįmanomų ryšių, kurie neleidžia jos atlikti per reikiamą laiką rėmai. Pvz., Norėdami visiškai įgyvendinti lenktynių žaidimą, neplanuosite padangų ilgaamžiškumo kodavimo dar prieš baigdami fizikos sistemą. Jūs neturėtumėte sistemos, pagal kurią būtų galima pagrįsti padangų kodą.
Planavimas
Čia viskas pasidaro ypač sudėtinga, bet pirmiausia išryškėja projekto valdymo poreikis.
Projekto vadovas kiekvienai užduočiai paskiria numatomas pradžios ir pabaigos datas. Tradiciniame projekto planavime jūs pateikiate pakopinį „krioklio“ vaizdą, kuris rodo projekto pabaigos laiką ir užduotis siejančias priklausomybes.
Svarbu nepamiršti atsižvelgti į paslydimą, darbuotojų nedarbingumo laiką, netikėtą funkcijų vėlavimą ir pan. Tai yra daug laiko reikalaujantis žingsnis, tačiau jis greitai suteiks jums supratimą, kiek tiksliai laiko prireiks projektui įvykdyti.
Ką daryti su duomenimis
Pažvelgę į šį projekto planą galite nustatyti, ar savybė brangiai kainuos laiką (taigi ir pinigus), ir priimti sprendimus, ar ši funkcija reikalinga žaidimui sėkmingai. Galite nuspręsti, kad atidėti funkcijos atnaujinimą ar net tęsinį yra prasmingiau.
Be to, naudinga nustatyti, kiek laiko dirbote su funkcija, kad nustatytumėte, ar laikas išbandyti naują metodą problemai išspręsti, ar sumažinti funkciją projekto labui.
Etapai
Dažnas projekto planavimas susijęs su gairių sudarymu. Tarpiniai etapai rodo, kada buvo įvykdytas tam tikras funkcionalumo elementas, darbo su projektu laikotarpis ar procentas užduočių.
Vykdant vidinį projekto stebėjimą, orientyrai yra naudingi planuojant ir pateikiant komandai konkrečius tikslus, kurių reikia. Dirbant su leidėju, etapai dažnai nulemia, kaip ir kada apmokama besivystančiai studijai.
Baigiamosios pastabos
Projekto planavimas daugeliui atrodo nepatogus, tačiau beveik visada pastebėsite, kad ilgainiui pasiseka kūrėjams, planuojantiems projektus iš anksto iš anksto ir vykdantiems svarbius tikslus.