Wprowadzenie zewnętrznego zespołu do trwającej produkcji w Unity to najpierw problem przekazania, a dopiero potem problem inżynieryjny. Nowi programiści muszą wiedzieć, co mogą bezpiecznie zmieniać, co już teraz jest kruche i która praca naprawdę ma znaczenie dla premiery. Audyt projektu ma odpowiedzieć właśnie na to. Zbyt często kończy się jednak długą listą obserwacji: „za dużo singletonów”, „stare pakiety”, „wydajność mogłaby być lepsza”. Żadnej z nich nie da się zaplanować, wycenić ani odebrać.

Ten poradnik jest dla liderów technicznych i producentów, którzy zamierzają zlecić audyt albo ocenić gotowy. Odpowiada na pytanie: jak audyt staje się uszeregowaną listą priorytetów i pakietem pracy, który można bezpiecznie przekazać?

Kiedy warto zacząć od audytu

Audyt zajmuje czas, zanim pojawi się jakikolwiek widoczny postęp, dlatego uzasadnia go niepewność, a nie przyzwyczajenie. Zwykle jest dobrym pierwszym krokiem, gdy:

  • Projekt został odziedziczony. Pierwotny zespół odszedł lub zajmuje się czymś innym i nikt nie potrafi z pewnością powiedzieć, które systemy są nośne.
  • Wydajność nie osiąga celu na docelowym sprzęcie, ale nie wiadomo, czy przyczyną są treści, kod, rendering czy architektura.
  • Projekt stał się wolny, niestabilny lub trudny do zmian. Małe funkcje zajmują tygodnie, merge psują sceny, a te same błędy wracają.
  • Prototyp ma stać się produkcją. Kod udowodnił, że gra działa, ale nie powstał po to, by przyjąć dużo treści i większy zespół.
  • Producent lub wydawca musi zdecydować, czy inwestować dalej, i potrzebuje do tego technicznej podstawy.

Jeśli problem jest wąski, powtarzalny, a jego przyczyna znana, skupiona poprawka bywa tańsza niż pełny audyt. Dobry partner powie Ci to wprost. Zakres audytu powinien odpowiadać skali niepewności.

Co przygotować przed audytem

Jakość audytu zależy od danych wejściowych. Przygotuj je, zanim zewnętrzny zespół zacznie pracę, a wszystko, czego nie możesz dostarczyć, potraktuj jako osobne ustalenie.

Dane wejściowe Dlaczego są ważne
Wersja Unity i render pipeline Od nich zależą ścieżki aktualizacji, zgodność pakietów i dostępne narzędzia.
Platformy docelowe i reprezentatywny sprzęt Ustalenia dotyczące wydajności mają sens tylko na sprzęcie, na którym będą grać gracze.
Aktualny build i kroki do jego zbudowania Pokazuje, czy build da się odtworzyć poza komputerem jednego programisty.
Powtarzalne błędy z krokami reprodukcji Zamieniają „czasem przycina” w scenariusz, który można zmierzyć przed zmianą i po niej.
Istniejące profile, logi crashy i zgłoszenia błędów Oszczędzają czas i pokazują, co zespół już wykluczył.
Zakres i odpowiedzialności Czego dotyczy audyt, kto odpowiada za poszczególne systemy, które gałęzie są aktywne i jakie są zasady code review.
Decyzja, którą audyt ma wesprzeć Na przykład: „Czy zewnętrzny zespół może przejąć system walki i AI, nie blokując produkcji treści?”

Najczęściej brakuje ostatniego wiersza. Audyt bez decyzji, którą ma wesprzeć, zwykle rozrasta się w inwentaryzację bez priorytetów.

Co powinien obejmować audyt

Audyt Unity przed co-developmentem powinien objąć obszary, w których wchodzący zespół najpewniej spowoduje lub napotka problemy. Głębokość analizy w każdym obszarze zależy od decyzji opisanej wyżej.

Obszar Pytania, na które audyt powinien odpowiedzieć
Architektura Jak zorganizowane są assembly i zależności? Gdzie przebiegają granice między gameplayem, siecią, warstwą prezentacji i danymi? Które systemy są zbyt mocno powiązane?
Pakiety i pluginy Jakie pakiety i wersje są używane? Czy któreś są sforkowane, osadzone w projekcie lub porzucone? Co blokuje aktualizację?
Sceny i prefaby Jak sceny są ładowane i kto jest ich właścicielem? Skąd biorą się konflikty przy merge i zerwane referencje serializowane?
Przepływy danych Gdzie jest właściciel stanu gry? Jak konfiguracja, zapisy i ewentualnie stan sieciowy przepływają przez grę?
Narzędzia Jakie narzędzia edytora, reguły importu i walidacja danych istnieją? Gdzie designerzy lub graficy mogą niezauważenie zepsuć build?
Build pipeline Czy czysta maszyna lub CI potrafi zbudować każdy docelowy build, łącznie z buildami serwerów headless, jeśli gra ich używa? Które kroki są ręczne?
Wydajność Co pokazują profile CPU, GPU, pamięci, ładowania i garbage collection na reprezentatywnym sprzęcie docelowym, w powtarzalnym scenariuszu?

Wiersz o wydajności wymaga osobnego ostrzeżenia. Profile z edytora albo z mocnego komputera deweloperskiego przydają się do orientacji, ale nie są dowodem dla mobilnych gogli VR ani dla przeciętnego PC gracza. Techniki takie jak Burst, native containers czy układ danych zorientowany na dane trafiają do kolumny działań tylko wtedy, gdy uzasadnia je zmierzone obciążenie. Nasz zespół stosował je przy VOXSYS, mobilnej strzelance VR, której celem było 90 FPS (praca wykonana przez obecnych członków zespołu w ich wcześniejszych rolach w VR Storm Studio). Wniosek: najpierw mierz, a optymalizuj potwierdzone wąskie gardło, nie podejrzewane.

Z tego samego powodu ważny jest wiersz o build pipeline. Przy Bean stalker, proceduralnym świecie VR tworzonym przez 18-osobowy, interdyscyplinarny zespół, narzędzia, walidacja i automatyzacja buildów znaczyły tyle samo co sam algorytm generowania: twórcy treści potrzebowali szybkiej informacji zwrotnej, a zespół release powtarzalnych wyników.

Co musi zawierać każde ustalenie

To jest sedno użytecznego audytu. Każde ustalenie powinno być samodzielną jednostką, którą producent może zaplanować, a programista zweryfikować. Skorzystaj z tego szablonu:

Pole Co zawiera Słaba wersja Użyteczna wersja
Problem Jeden konkretny problem, zawężony do systemu lub procesu. „Architektura jest chaotyczna.” „Spawnowanie przeciwników alokuje pamięć i instancjonuje prefaby w trakcie walki.”
Dowód Jak to zaobserwowano: profil, log, odwołanie do kodu, kroki reprodukcji. „Zauważyliśmy to.” „Profil na sprzęcie docelowym, scenariusz X, klatki N–M; ścieżka kodu w SpawnController.”
Wpływ na gracza / biznes Co odczuwa gracz albo co traci produkcja. „Źle dla wydajności.” „Widoczne przycięcie w szczycie każdej fali walki.”
Priorytet Uszeregowany względem innych ustaleń według wpływu i ryzyka. Wszędzie „wysoki”. „P1: blokuje uzgodniony próg jakości przed premierą.”
Proponowane działanie Co zmienić i czy to szybka poprawka, stopniowy refaktor czy przebudowa. „Zrefaktorować spawnowanie.” „Pula prefabów przeciwników, usunięcie alokacji przy każdym spawnie, dodanie scenariusza regresji.”
Kryteria akceptacji Po czym wszyscy poznają, że praca jest skończona, mierzone tak samo jak dowód. „Powinno być szybciej.” „Ten sam scenariusz, ten sam sprzęt: żadna klatka w trakcie fali nie przekracza uzgodnionego budżetu.”

Dwa pola są często pomijane, a to właśnie one sprawiają, że audyt da się wdrożyć. Dowód pozwala Twojemu zespołowi samodzielnie sprawdzić ustalenie. Kryteria akceptacji zamieniają ustalenie w zadanie z jasnym końcem i stają się standardem przeglądu, gdy praca do Ciebie wraca.

Szybka poprawka, stopniowy refaktor czy większa przebudowa

Każde proponowane działanie trzeba sklasyfikować, bo te trzy typy niosą bardzo różne ryzyko dla produkcji, która w tym czasie dalej dostarcza treści.

Typ Kiedy pasuje Ryzyko dla produkcji Jak to zweryfikować
Szybka poprawka Lokalna, dobrze zrozumiana przyczyna: gorąca alokacja, brakująca walidacja, ręczny krok builda. Niskie; dotyczy jednego systemu. Pierwotna reprodukcja i pomiar, przed zmianą i po niej.
Stopniowy refaktor System działa, ale opiera się zmianom: splątane zależności, niejasna własność stanu. Średnie; wymaga testowalnej granicy i planu migracji dopasowanego do bieżącej pracy nad treścią. Testy wokół krytycznych reguł, niezmienione zachowanie i uzgodnione kryteria akceptacji.
Większa przebudowa Dowody wskazują, że przyczyna jest strukturalna, np. własność stanu nie udźwignie nowego wymagania. Wysokie; konkuruje z funkcjami i wymaga planu etapowego. Etapowe kamienie milowe, każdy z własnymi kryteriami akceptacji.

Wiarygodny audyt nie przeskakuje od razu do przepisywania od zera. Większość ustaleń powinna trafić do dwóch pierwszych wierszy. Jeśli audyt proponuje przebudowę, musi dołączyć dowód, że mniejsze działania nie wystarczą, oraz plan, który nie zamrozi reszty produkcji.

Od audytu do przekazania w co-development

Audyt staje się użyteczny, gdy jego ustalenia zamieniają się w pakiet pracy, który zewnętrzny zespół może przejąć na własność. Zanim zacznie się implementacja, uzgodnijcie cztery rzeczy.

Odpowiedzialności. Zwykle po Twojej stronie są dostęp do repozytorium, zasady pracy z gałęziami i polityka code review, priorytety produktowe i odbiór dostarczonej pracy, a także docelowy sprzęt i wymagania platform. Zewnętrzny zespół odpowiada za jakość inżynieryjną tego, co dostarcza, za powtarzalne pomiary dla każdej deklaracji optymalizacji i za jasne granice odpowiedzialności z Twoimi programistami.

Zależności. Dla każdego ustalenia w pakiecie zapisz, od czego zależy: od innych ustaleń, dostaw treści, aktualizacji pakietu, dostępu do urządzenia, decyzji designu. Niezapisane zależności zamieniają się w opóźnienia, za które nikt nie odpowiada.

Przegląd. Ustalcie, kto przegląda pull requesty, jak często pokazujecie postępy i co się dzieje, gdy ustalenie okazuje się większe niż szacowano. Kryteria akceptacji z audytu są checklistą przeglądu.

Przekazanie. Określ, co wraca po zakończeniu pracy: zmergowany kod, testy wokół zmienionych reguł, dokumentacja, zaktualizowane narzędzia i pomiary przed i po. Celem jest kod, który Twój zespół może dalej utrzymywać, a nie zależność od zewnętrznego zespołu.

Różne modele odpowiedzialności, od wydzielonego obszaru pracy po programistów wbudowanych w zespół, opisujemy na stronie tworzenie gier. To, jak podchodzimy do audytów istniejących projektów Unity, przedstawia strona tworzenie gier w Unity.

Przykładowe ustalenie (ilustracyjne)

Przykład ilustracyjny. Poniższe ustalenie jest hipotetyczne. Nie opisuje prawdziwego klienta ani projektu i nie zawiera zmierzonych wartości. Pokazuje tylko, jak wygląda wypełniony szablon.

Pole Treść
Problem W trakcie fal walki przeciwnicy są instancjonowani z prefabów w momencie spawnu, a logika spawnu przy każdym przeciwniku alokuje tymczasowe kolekcje.
Dowód Profil CPU na uzgodnionym sprzęcie docelowym, w powtarzalnym scenariuszu (stały zapis z początku trzeciej fali). W klatkach ze skokami widać instancjonowanie i garbage collection w ścieżce kodu spawnu. Miejsce w kodzie jest wskazane.
Wpływ na gracza / biznes Gracze widzą przycięcie w najbardziej intensywnym momencie każdej fali. Na platformie VR to samo przycięcie byłoby też problemem z komfortem. W recenzjach i notatkach z playtestów pojawia się jako „przycinanie”.
Priorytet P1: dotyczy każdej sesji i blokuje uzgodniony próg wydajności na następny kamień milowy.
Proponowane działanie Szybka poprawka: wstępnie wypełniona pula dla prefabów przeciwników używanych w fali i usunięcie alokacji przy każdym spawnie ze ścieżki spawnu. Scenariusz trafia do regularnej kontroli wydajności, aby problem nie wrócił niezauważony.
Kryteria akceptacji W tym samym scenariuszu, na tym samym sprzęcie żadna klatka w trakcie fali nie przekracza uzgodnionego budżetu czasu klatki, a po rozgrzaniu ścieżka spawnu nie alokuje pamięci zarządzanej przy kolejnych spawnach. Profile przed i po są dołączone do pull requesta.

Zwróć uwagę, czego w przykładzie nie ma: obiecanej procentowej poprawy. Kryterium akceptacji jest powiązane z własnym budżetem projektu i mierzone tak samo jak dowód. Dzięki temu da się je sprawdzić.

Jeśli Twoja obecna produkcja to gra sieciowa, ten sam szablon działa dla ustaleń dotyczących buildów serwerowych i własności stanu. W Bad Goons, naszym obecnym autorskim IP w aktywnej produkcji, klient Unity 6, warstwa realtime FishNet, symulacja wokseli i dedykowane serwery Linux są traktowane jako osobne systemy produkcyjne, a audyt powinien szukać właśnie takiego rozdzielenia albo je zalecić. Case study VOXSYS pokazuje wydajnościową stronę tej samej dyscypliny.

Checklista do oceny oferty audytu

Zadaj te pytania, zanim zatwierdzisz audyt, i jeszcze raz, gdy otrzymasz raport.

  • Oferta wskazuje decyzję, którą audyt ma wesprzeć, a nie tylko obszary do przejrzenia.
  • Wymienione są potrzebne dane wejściowe: wersja Unity, render pipeline, platformy i sprzęt docelowy, kroki budowania, powtarzalne błędy, istniejące profile, zakres i odpowiedzialności.
  • Analiza wydajności jest zaplanowana na reprezentatywnym sprzęcie docelowym, w powtarzalnych scenariuszach.
  • Przegląd obejmuje architekturę, pakiety, sceny, przepływy danych, narzędzia, build pipeline i wydajność albo wyjaśnia, dlaczego dany obszar pominięto.
  • Każde ustalenie będzie zawierać problem, dowód, wpływ na gracza lub biznes, priorytet, proponowane działanie i kryteria akceptacji.
  • Ustalenia są uszeregowane względem siebie, a nie wszystkie oznaczone jako „wysokie”.
  • Każde działanie jest sklasyfikowane jako szybka poprawka, stopniowy refaktor lub większa przebudowa, wraz z ryzykiem dla produkcji.
  • Każda propozycja przebudowy zawiera dowód, że mniejsze zmiany nie wystarczą, oraz plan, który nie zamrozi produkcji treści.
  • Raport kończy się pakietem pracy: odpowiedzialności, zależności, proces przeglądu i elementy do przekazania.
  • Deklaracje optymalizacji będą poparte pomiarami przed i po w tym samym scenariuszu.
  • Twój zespół może zweryfikować każde ustalenie bez obecności zewnętrznego zespołu.