Cum poate un PM să transforme producția de artă: un studiu de caz în jocurile AAA

Declinare a responsabilității

În timp ce lucram ca project manager, am auzit adesea comentarii de genul: „De ce avem nevoie de PM-uri? Ce fac ei de fapt? Doar vorbesc și nimic mai mult." Este o opinie destul de răspândită.

Așa că am pregătit un articol despre ce poate face de fapt un PM (împreună cu echipa sa) și cât de mare poate fi impactul acelei munci pentru un proiect. Așa cum ne place nouă, PM-urilor și producătorilor — cu cifre, tabele și diagrame. Sunt trei părți despre Art Pipeline, Optimizarea Rutinei Zilnice și eticheta JIRA.

Acest caz provine din experiența mea personală și se concentrează pe modul în care am construit un departament de Cosmetice de la zero pe un proiect AAA și, în cele din urmă, am optimizat producția de artă, accelerând-o de 3,3 ori.

Vă mulțumesc foarte mult. Lectură plăcută.

Art Pipeline

Cazul

Odată, am trecut în producție ca Project Manager cu o misiune: să construiesc un departament de cosmetice care să livreze skin-uri (și altele) pentru battle pass-uri și evenimente din joc.

În același timp, aveam deja un departament de artă pentru personaje. Ei creaseră opt personaje în diverse stadii de finalizare și un skin de nivel înalt cu modificări de geometrie. Producerea acelui singur skin a durat artistului 16 luni.

Sarcina mea era să stabilesc un pipeline de producție funcțional și să îndeplinesc pe deplin cerințele editorului până la data de lansare: 21+ skin-uri cu geometrie nouă și 40+ recolorări. După aceea, trebuia să lansăm 7+ skin-uri de diferite tipuri în fiecare lună — iar anul următor, să dublăm aceste cifre.

Munca

Mai întâi, am analizat experiența anterioară și ritmul actual de producție al mesh-urilor (personaje și un skin). Folosind date din Jira și tone de foi Excel, am identificat mai multe puncte slabe.

Roadmap de producție artă

Nu exista un roadmap structurat pentru producția de artă pentru personaje în general și pentru cosmetice în special. Mesh-urile erau considerate parte a pipeline-ului de dezvoltare a personajelor, iar toată munca legată de ele era plasată în trei etape mari — L0, L1, L2 — de la prototip la versiunea finală lustruită. Fiecare dintre aceste sarcini supradimensionate putea depăși lungimea sprint-ului nu doar cu două cicluri, ci uneori cu trei sau chiar patru.

Lipsa unui standard

Fiecare mesh era tratat ca o caracteristică R&D. Când am comparat etapele L0/L1/L2 în diferite cazuri, am descoperit că acestea durau perioade complet diferite de timp — atât timp curat (ore înregistrate), cât și timp murdar (decalajul dintre crearea sarcinii, mutarea acesteia la „în progres" și marcarea ca „finalizată"). Chiar și numărul de sarcini pentru tipuri identice de mesh-uri varia semnificativ, iar unele dintre ele aveau descrieri aproape imposibil de înțeles.

Un aspect separat care a ieșit în evidență: un artist alocat sarcinii lucra la mesh de la început până la sfârșit (judecând după istoricul de alocare). Și în timpul producției, nu existau puncte logice în care el ar fi putut să o predea altcuiva fără a pierde calitate sau timp. Întreaga sarcină arăta ca un bloc masiv și continuu de muncă.

Lipsa transparenței procesului

Nu era clar ce se întâmpla în timpul dezvoltării sau cum era realizată. Calitatea și consistența actualizărilor de sarcini depindeau în întregime de dezvoltatorul însuși. Nu exista nicio modalitate de a urmări progresul de la distanță sau în afara stand-up-urilor de dimineață. Dacă un artist se îmbolnăvea, lead-ul putea prelua parțial sarcina sa, nu lăsa nicio notă și totuși o închidea.

Numărul de iterații

Chiar și din istoricul de bază al statusului era evident că sarcina mergea la review, apoi înapoi, apoi din nou la review și apoi înapoi la muncă. Și asta fără a menționa absența completă a comentariilor care să explice de ce sarcina era returnată la muncă și apoi trimisă din nou înapoi — niciun cuvânt.

Ne-am adunat cu micul nostru cerc de Illuminati — eu (ca PM), artistul principal și art lead-ul — și am început munca.

Soluția

Pentru început, am luat două decizii importante la nivel înalt pentru a opri confuzia la nivelul superior.

Am introdus grade

Înainte de asta, proiectul era plin de o întreagă gamă de termeni și etichete: recolor, paintjob, skin, premium skin, veterans și așa mai departe. Fiecare cuvânt se referea la un tip diferit de muncă, ceea ce ne-a confuzat și mai mult. Am renunțat la toate acestea și am introdus un document care contura clar diferențele dintre skin-uri și gradele lor.

Regula „Un skin = Un epic = O ramură"

Am împrumutat această regulă organizațională de la echipa de dezvoltare a personajelor. Un epic include toată munca legată de skin pe partea de dezvoltare. Fiecare epic conține o singură ramură și un singur pull request dedicat acelui skin. La rândul său, epic-ul era legat de inițiativa/caracteristica relevantă a sezonului (sau evenimentului) pentru o navigare mai ușoară.

Acesta a fost punctul nostru de plecare. De acolo, am reconstruit întregul flux de lucru.

Am eliminat L0–L1–L2

În schimb, am împărțit producția conform logicii reale de producție: Design → Geometrie → Texturi → Implementare.

Fiecare etapă a fost împărțită în pași logici mai mici, de exemplu: \n Concept: Moodboard – Schiță 2D – Schiță 3D (dacă este necesar) \n Geometrie: Low Res – High Res – Import fișier FBX \n Implementare: Rig – GD Setup – Art Review – QA

Skin-ul în sine a fost, de asemenea, împărțit în trei părți: corpul, arma și modulele. Ceea ce înseamnă că de atunci puteam avea trei sarcini separate, cum ar fi: \n Corp – Geometrie Low Res, \n Armă – Geometrie Low Res, \n Module – Geometrie Low Res.

Acest lucru a transformat ceea ce obișnuia să fie un singur bloc masiv de muncă într-un constructor asemănător Lego care putea fi distribuit între artiști în funcție de volumul lor de muncă. Acum era posibil să urmărim exact în ce etapă se afla producția în prezent.

Noul roadmap de producție artă

Practic, tot ce făcusem mai sus a fost prezentat ca o secvență de acțiuni. Această diagramă ne-a ajutat — pe noi și pe orice PM care ar putea să mă înlocuiască în timpul concediului medical sau a vacanței — să înțelegem unde și ce procese puteau fi rulate în paralel pentru a economisi timp.

Formatare unificată pentru Epic-uri și sarcini

Epic-ul conținea acum doar sarcini strict legate de gradul skin-ului — nimic în plus.

Fiecare epic includea conceptul skin-ului în descrierea sa, precum și criteriile de acceptare de la producător.

Acest lucru a redus confuzia și i-a dat artistului o înțelegere clară a ceea ce se aștepta în fiecare etapă. (Mai târziu am rafinat și mai mult descrierile sarcinilor, dar asta se referă la subiectul rutinei zilnice, care urmează.)

Am configurat, de asemenea, o secțiune separată în Confluence cu un board Mira unde toate aceste descrieri erau listate pentru fiecare sarcină, cu comentarii pentru project manager explicând când și ce sarcină ar trebui creată, împreună cu o formulă Jira care putea fi pur și simplu copiată și lipită în corpul sarcinii.

Estimări

Am încercat să împărțim sarcinile astfel încât să fie ușor de planificat. Proiectul folosea sprint-uri de două săptămâni, așa că am căutat să găsim o structură comună: să nu depășim prea mult limitele, oferind totuși fiecărei sarcini un punct logic de finalizare.

Mulțumiri enorme colegilor mei — fără experiența lor nu am fi putut să împărțim acest lucru atât de precis. Să ne bazăm doar pe cifrele din Jira ar fi fost mult mai greu, deoarece în producția de artă abilitatea specialistului individual contează foarte mult, iar atunci când proiectam estimări, trebuia să găsim un teren auriu între ceea ce puteam livra în mod realist și ceea ce doream să realizăm. Așa am ajuns la formula că un pas de dezvoltare = un sprint plus două zile cel mult.

Acum artistul putea vedea cât timp avea pentru fiecare sarcină și cât de aproape era de finalizarea ei. Cu o comunicare adecvată, acesta a devenit un instrument de susținere. Dacă un artist vedea că mai avea trei zile pentru o sarcină, dar înțelegea că nu o va termina — putea să-mi spună proactiv.

Acest lucru însemna că nu trebuia să „control" dezvoltatorul; aceștia aveau toate instrumentele pentru a mă ajuta și a ridica un semnal de alarmă acolo unde am putea rata un termen limită.

Ca rezultat, am reușit să obținem autonomia dezvoltatorului. Când deschidea un epic, artistul găsea o sarcină gata, complet pregătită pe care putea să o înceapă imediat — chiar dacă nu erau complet siguri ce să facă la început. Am făcut sesiunile de review și criteriile de evaluare transparente.

Rezultat

Direct la subiect. Doar cifre.

Acesta este cazul.

\ \ \