Jak PM może przekształcić produkcję graficzną: Studium przypadku w grach AAA

Zastrzeżenie

Pracując jako project manager, często słyszałem komentarze w stylu: „Po co w ogóle są nam PM-y? Co oni właściwie robią? Tylko gadają i nic więcej." To dość powszechna opinia.

Dlatego przygotowałem artykuł o tym, co PM może faktycznie zrobić (razem ze swoim zespołem) i jak znaczący wpływ może to mieć na projekt. Tak jak my, PM-y i producenci, lubimy — z liczbami, tabelami i wykresami. Są trzy części dotyczące Art Pipeline, optymalizacji codziennych rutyn i etykiety JIRA.

Ten przypadek pochodzi z mojego osobistego doświadczenia i koncentruje się na tym, jak zbudowaliśmy dział kosmetyków od podstaw w projekcie AAA i ostatecznie zoptymalizowaliśmy produkcję artystyczną, przyspieszając ją 3,3-krotnie.

Dziękuję bardzo. Życzę miłej lektury.

Art Pipeline

Przypadek

Gdy przeszedłem do produkcji jako Project Manager z misją: zbudować dział kosmetyków, który dostarczy skiny (i więcej) do przepustek bojowych i wydarzeń w grze.

W tym samym czasie mieliśmy już dział grafiki postaci. Stworzyli osiem postaci na różnych etapach ukończenia i jeden skin wysokiej klasy ze zmianami geometrii. Wyprodukowanie tego jednego skina zajęło artyście 16 miesięcy.

Moim zadaniem było ustanowienie funkcjonującego pipeline'u produkcyjnego i pełne spełnienie wymagań wydawcy do daty premiery: 21+ skinów z nową geometrią i 40+ przekolorowań. Po tym musieliśmy wydawać 7+ skinów różnych typów co miesiąc — a w następnym roku podwoić te liczby.

Praca

Najpierw przeanalizowałem poprzednie doświadczenia i obecne tempo produkcji meshów (postaci i skina). Korzystając z danych z Jira i ton arkuszy Excel, zidentyfikowaliśmy kilka słabych punktów.

Mapa drogowa produkcji artystycznej

Nie było ustrukturyzowanej mapy drogowej dla produkcji grafiki postaci w ogóle, a kosmetyków w szczególności. Meshe były uważane za część pipeline'u rozwoju postaci, a wszystkie prace z nimi związane były umieszczane w trzech dużych etapach — L0, L1, L2 — od prototypu do ostatecznej, dopracowanej wersji. Każde z tych przewymiarowanych zadań mogło przekraczać długość sprintu nie tylko o dwa cykle, ale czasami o trzy lub nawet cztery.

Brak standardu

Każdy mesh był traktowany jako funkcja R&D. Kiedy porównaliśmy etapy L0/L1/L2 w różnych przypadkach, odkryliśmy, że zajmowały one zupełnie różne ilości czasu — zarówno czystego czasu (zalogowanych godzin), jak i brudnego czasu (przerwy między utworzeniem zadania, przeniesieniem go do „w trakcie" i oznaczeniem jako „gotowe"). Nawet liczba zadań dla identycznych typów meshów znacznie się różniła, a niektóre z nich miały opisy prawie niemożliwe do zrozumienia.

Osobna rzecz, która się wyróżniała: jeden artysta przypisany do zadania pracował nad meshem od początku do końca (sądząc po historii przypisań). I podczas produkcji nie było żadnych logicznych punktów, w których mógłby go przekazać komuś innemu bez utraty jakości lub czasu. Całe zadanie wyglądało jak jeden ogromny, ciągły blok pracy.

Brak przejrzystości procesu

Nie było jasne, co dzieje się podczas rozwoju lub jak jest to realizowane. Jakość i spójność aktualizacji zadań zależała całkowicie od samego dewelopera. Nie było sposobu, aby śledzić postęp zdalnie lub poza porannymi stand-upami. Jeśli artysta zachorował, lead mógł częściowo przejąć jego zadanie, nie zostawić żadnych notatek i nadal je zamknąć.

Liczba iteracji

Nawet z podstawowej historii statusu było oczywiste, że zadanie trafiało na przegląd, potem wracało, potem z powrotem na przegląd, a następnie z powrotem do pracy. I to nie wspominając o całkowitym braku komentarzy wyjaśniających, dlaczego zadanie było zwracane do pracy, a potem wysyłane ponownie — ani słowa.

Zebraliśmy się z naszym małym kręgiem Iluminatów — ja (jako PM), główny artysta i art lead — i zabraliśmy się do pracy.

Rozwiązanie

Na początek podjęliśmy dwie ważne decyzje wysokiego szczebla, aby zatrzymać chaos na najwyższym poziomie.

Wprowadziliśmy stopnie

Wcześniej projekt był pełen całego zakresu terminów i etykiet: recolor, paintjob, skin, premium skin, veterans i tak dalej. Każde słowo odnosiło się do innego rodzaju pracy, co tylko bardziej nas myliło. Porzuciliśmy to wszystko i wprowadziliśmy dokument, który jasno określał różnice między skinami i ich stopniami.

Zasada „Jeden skin = Jeden epic = Jedna gałąź"

Pożyczyłem tę zasadę organizacyjną od zespołu rozwoju postaci. Jeden epic obejmuje wszystkie prace związane ze skinem po stronie deweloperskiej. Każdy epic zawiera pojedynczą gałąź i pojedynczy pull request poświęcony temu skinowi. Z kolei epic był powiązany z odpowiednią inicjatywą/funkcją sezonu (lub wydarzenia) dla łatwiejszej nawigacji.

To był nasz punkt wyjścia. Stamtąd przebudowaliśmy cały proces pracy.

Pozbyliśmy się L0–L1–L2

Zamiast tego podzieliliśmy produkcję zgodnie z rzeczywistą logiką produkcji: Design → Geometry → Textures → Implementation.

Każdy etap został podzielony na mniejsze logiczne kroki, na przykład: \n Concept: Moodboard – 2D Sketch – 3D Sketch (jeśli potrzebny) \n Geometry: Low Res – High Res – FBX File Import \n Implementation: Rig – GD Setup – Art Review – QA

Sam skin został również podzielony na trzy części: ciało, broń i moduły. Oznaczało to, że od tego momentu mogliśmy mieć trzy oddzielne zadania, takie jak: \n Body – Geometry Low Res, \n Weapon – Geometry Low Res, \n Modules – Geometry Low Res.

To przekształciło to, co kiedyś było pojedynczym masywnym blokiem pracy, w konstruktor podobny do klocków Lego, który mógł być dystrybuowany między artystami w zależności od ich obciążenia pracą. Teraz możliwe było śledzenie dokładnie, na jakim etapie znajduje się obecnie produkcja.

Nowa mapa drogowa produkcji artystycznej

W zasadzie wszystko, co zrobiliśmy powyżej, zostało przedstawione jako sekwencja działań. Ten wykres pomógł nam — i każdemu PM, który mógłby mnie zastąpić podczas zwolnienia chorobowego lub urlopu — zrozumieć, gdzie i które procesy mogą być prowadzone równolegle, aby zaoszczędzić czas.

Ujednolicone formatowanie Epiców i zadań

Epic teraz zawierał tylko zadania ściśle związane ze stopniem skina — nic więcej.

Każdy epic zawierał koncepcję skina w swoim opisie, a także kryteria akceptacji od producenta.

To zmniejszyło zamieszanie i dało artyście jasne zrozumienie tego, czego oczekiwano na każdym etapie. (Później jeszcze bardziej udoskonaliliśmy opisy zadań, ale to odnosi się do tematu codziennej rutyny, który będzie następny.)

Stworzyłem również osobną sekcję w Confluence z tablicą Mira, gdzie wszystkie te opisy były wymienione dla każdego zadania, z komentarzami dla project managera wyjaśniającymi, kiedy i jakie zadanie powinno zostać utworzone, wraz z formułą Jira, którą można było po prostu skopiować i wkleić do treści zadania.

Szacunki

Próbowaliśmy rozbić zadania tak, aby były łatwe do zaplanowania. Projekt używał dwutygodniowych sprintów, więc staraliśmy się znaleźć wspólną strukturę: nie przekraczać granic zbyt mocno, jednocześnie dając każdemu zadaniu logiczny punkt zakończenia.

Ogromne podziękowania dla moich kolegów — bez ich doświadczenia nie bylibyśmy w stanie tego tak precyzyjnie rozłożyć. Poleganie tylko na liczbach z Jira byłoby znacznie trudniejsze, ponieważ w produkcji artystycznej umiejętności indywidualnego specjalisty mają duże znaczenie, a projektując szacunki, musieliśmy znaleźć złoty środek między tym, co mogliśmy realistycznie dostarczyć, a tym, co chcieliśmy osiągnąć. Tak doszliśmy do formuły, że jeden krok rozwoju = sprint plus dwa dni maksymalnie.

Teraz artysta mógł zobaczyć, ile czasu ma na każde zadanie i jak blisko jest jego ukończenia. Przy odpowiedniej komunikacji stało się to narzędziem wsparcia. Jeśli artysta widział, że zostały mu trzy dni na zadanie, ale rozumiał, że nie zdąży — mógł mi to proaktywnie powiedzieć.

Oznaczało to, że nie musiałem „kontrolować" dewelopera; mieli wszystkie narzędzia, aby mi pomóc i podnieść czerwoną flagę tam, gdzie mogliśmy nie dotrzymać terminu.

W rezultacie udało nam się osiągnąć autonomię dewelopera. Otwierając epic, artysta znajdował gotowe, w pełni przygotowane zadanie, które mógł rozpocząć natychmiast — nawet jeśli na początku nie był całkowicie pewien, co robić. Uczyniliśmy sesje przeglądowe i kryteria oceny przejrzystymi.

Rezultat

Prosto do sedna. Tylko liczby.

To jest przypadek.

\ \ \