Ha egy futó Unity fejlesztésbe külső csapatot hozol be, az előbb átadási kérdés, és csak utána mérnöki. Az új fejlesztőknek tudniuk kell, mihez nyúlhatnak biztonságosan, mi az, ami már most is törékeny, és melyik munka számít ténylegesen a megjelenés szempontjából. Egy projekt auditnak pontosan erre kellene választ adnia. Sokszor mégis csak egy hosszú észrevétellista lesz belőle: „túl sok a singleton”, „régiek a package-ek”, „lehetne jobb a teljesítmény”. Ezek egyikét sem lehet ütemezni, megbecsülni vagy átvenni.
Ez az útmutató technikai vezetőknek és producereknek szól, akik auditot rendelnének meg, vagy egy elkészültet kell megítélniük. A kérdés, amire válaszol: hogyan lesz egy auditból rangsorolt prioritáslista és biztonságosan átadható munkacsomag?
Mikor érdemes audittal kezdeni?
Az audit időbe kerül, mielőtt bármi látható haladás lenne, ezért a bizonytalanság indokolja, nem a megszokás. Általában akkor jó első lépés, ha:
- Örökölt projektről van szó. Az eredeti csapat már nincs ott vagy máson dolgozik, és senki sem tudja biztosan, melyik rendszer tartja a többit.
- A teljesítmény nem éri el a célt a cél hardveren, de nem tudni, hogy a tartalom, a kód, a renderelés vagy az architektúra az oka.
- A projekt lassú, instabil vagy nehezen módosítható lett. Apró feature-ök hetekig tartanak, a merge-ök szétszedik a scene-eket, és ugyanazok a hibák térnek vissza.
- Egy prototípusból éles fejlesztés lesz. A kód bizonyította a játékot, de nem arra épült, hogy sok tartalmat és nagyobb csapatot elbírjon.
- Producerként vagy publisherként arról kell döntened, hogy fektess-e bele többet, és ehhez technikai alap kell.
Ha a probléma szűk, reprodukálható, és az oka már ismert, egy célzott javítás gyakran olcsóbb, mint egy teljes audit. Egy jó partner ezt meg is mondja. Az audit mérete a bizonytalanság méretéhez igazodjon.
Mit adj át az audit előtt?
Az audit minősége a bemenetein múlik. Ezeket készítsd elő, mielőtt a külső csapat nekiáll, és ha valamit nem tudsz biztosítani, az önmagában is megállapítás.
| Bemenet | Miért fontos? |
|---|---|
| Unity verzió és render pipeline | Ettől függ a frissítési út, a package-kompatibilitás és az, hogy milyen eszközök érhetők el. |
| Célplatformok és reprezentatív hardver | A teljesítménnyel kapcsolatos megállapítás csak azon a hardveren értelmes, amelyen a játékosok játszani fognak. |
| Aktuális build és az elkészítésének lépései | Kiderül belőle, hogy a build reprodukálható-e egyetlen fejlesztő gépén kívül is. |
| Reprodukálható hibák lépésekkel | A „néha akad” helyett olyan forgatókönyv lesz, amit előtte és utána is meg lehet mérni. |
| Meglévő profilok, crash logok és hibajegyek | Időt spórol, és megmutatja, mit zárt már ki a csapat. |
| Scope és felelősségi körök | Mire terjed ki az audit, ki felel az egyes rendszerekért, mely branchek aktívak, és mik a code review szabályai. |
| A döntés, amit az auditnak alá kell támasztania | Például: „Átveheti-e egy külső csapat a harcrendszert és az AI-t úgy, hogy ne akassza meg a tartalomgyártást?” |
Leggyakrabban az utolsó sor hiányzik. Ha az audit mögött nincs eldöntendő kérdés, könnyen prioritás nélküli leltárrá nő.
Mit vizsgáljon az audit?
Egy co-development előtti Unity auditnak azokat a területeket kell lefednie, ahol a belépő csapat a legnagyobb eséllyel okoz vagy talál problémát. Az, hogy egy-egy területet milyen mélyen kell vizsgálni, a fenti döntéstől függ.
| Terület | Kérdések, amikre az auditnak válaszolnia kell |
|---|---|
| Architektúra | Hogyan szerveződnek az assemblyk és a függőségek? Hol vannak a határok a játékmenet, a hálózat, a megjelenítés és az adatok között? Mely rendszerek kapcsolódnak túl szorosan? |
| Package-ek és pluginok | Milyen package-ek és verziók vannak használatban? Van-e forkolt, beágyazott vagy elhagyott köztük? Mi akadályozza a frissítést? |
| Scene-ek és prefabok | Hogyan töltődnek be a scene-ek, és kié melyik? Honnan jönnek a merge konfliktusok és a törött szerializált referenciák? |
| Adatfolyamok | Hol van a játékállapot gazdája? Hogyan mozog a konfiguráció, a mentés és adott esetben a hálózati állapot a játékon belül? |
| Eszközök | Milyen editor toolok, import szabályok és adatvalidáció vannak? Hol tudják a designerek vagy a grafikusok észrevétlenül eltörni a buildet? |
| Build pipeline | Elő tud-e állítani egy tiszta gép vagy a CI minden cél buildet, a headless szerver buildeket is, ha vannak? Mely lépések kézzel mennek? |
| Teljesítmény | Mit mutatnak a CPU-, GPU-, memória-, betöltési és garbage collection profilok reprezentatív cél hardveren, megismételhető forgatókönyvben? |
A teljesítmény sorához tartozik egy külön figyelmeztetés. Az editorból vagy egy erős fejlesztői gépről készült profil tájékozódásra jó, de nem bizonyíték egy mobil VR headsetre vagy egy átlagos játékos PC-re. Az olyan technikák, mint a Burst, a native containerek vagy az adatorientált elrendezés, csak akkor kerüljenek a beavatkozás oszlopba, ha egy mért terhelés indokolja őket. A csapatunk a VOXSYS-on használta ezeket, egy mobil VR shooteren, amelynek a célja 90 FPS volt (a munkát a jelenlegi csapattagok korábbi, VR Storm Studio-s szerepükben végezték). A tanulság: előbb mérj, és a bizonyított szűk keresztmetszetet optimalizáld, ne a gyanúsítottat.
Ugyanezért számít a build pipeline sora is. A Bean stalkeren, egy procedurális VR világon, amelyet egy 18 fős, több szakterületet átfogó csapat épített, az eszközök, a validáció és a build automatizálás ugyanannyit számított, mint maga a generáló algoritmus: a tartalomkészítőknek gyors visszajelzés kellett, a release csapatnak pedig megismételhető eredmény.
Mit kell tartalmaznia minden megállapításnak?
Ez egy hasznos audit lényege. Minden megállapítás legyen önálló egység, amit egy producer be tud ütemezni, egy fejlesztő pedig ellenőrizni tud. Ezt a sablont használd:
| Mező | Mit tartalmaz? | Gyenge változat | Használható változat |
|---|---|---|---|
| Probléma | Egyetlen konkrét gond, egy rendszerre vagy munkafolyamatra szűkítve. | „Kusza az architektúra.” | „Az ellenfelek spawnolása harc közben memóriát foglal és prefabokat példányosít.” |
| Bizonyíték | Hogyan derült ki: profil, log, kódhivatkozás, reprodukciós lépések. | „Észrevettük.” | „Felvétel cél hardveren, X forgatókönyv, N–M. frame; kódút a SpawnControllerben.” |
| Hatás a játékosra / az üzletre | Mit érez a játékos, vagy mit veszít a fejlesztés. | „Rossz a teljesítménynek.” | „Látható akadás minden harci hullám csúcsán.” |
| Prioritás | A többi megállapításhoz képest rangsorolva, hatás és kockázat alapján. | Mindenhol „magas”. | „P1: blokkolja a megjelenéshez rögzített minőségi szintet.” |
| Javasolt beavatkozás | Mit kell módosítani, és ez gyors javítás, fokozatos refaktor vagy átstrukturálás-e. | „Refaktoráljuk a spawnolást.” | „Poolozzuk az ellenség prefabokat, kivesszük a spawnonkénti foglalásokat, és felveszünk egy regressziós forgatókönyvet.” |
| Átvételi feltétel | Miből tudja mindenki, hogy kész, ugyanúgy mérve, mint a bizonyítékot. | „Gyorsabb lesz.” | „Ugyanaz a forgatókönyv, ugyanaz a hardver: a hullám alatt egyik frame sem lépi túl az egyeztetett keretet.” |
Két mezőt szoktak kihagyni, pedig éppen ezek teszik végrehajthatóvá az auditot. A bizonyíték miatt a saját csapatod is át tudja nézni a megállapítást. Az átvételi feltétel pedig munkatétellé teszi a megállapítást, egyértelmű végponttal, és ez lesz a review mércéje is, amikor a munka visszakerül hozzád.
Gyors javítás, fokozatos refaktor vagy nagyobb átstrukturálás?
Minden javasolt beavatkozást be kell sorolni, mert a három típus nagyon eltérő kockázatot jelent egy olyan fejlesztésben, amely közben is folyamatosan kapja a tartalmat.
| Típus | Mikor illik? | Kockázat a fejlesztésre | Hogyan ellenőrizhető? |
|---|---|---|---|
| Gyors javítás | Helyi, jól értett ok: egy forró foglalás, egy hiányzó validáció, egy kézi build lépés. | Alacsony, egy rendszert érint. | Az eredeti reprodukció és mérés, előtte és utána. |
| Fokozatos refaktor | Működő, de nehezen változtatható rendszer: összegabalyodott függőségek, tisztázatlan állapottulajdon. | Közepes; tesztelhető határ és a futó tartalommunkához igazított migrációs terv kell hozzá. | Tesztek a kritikus szabályok körül, változatlan viselkedés, plusz az egyeztetett átvételi feltételek. |
| Nagyobb átstrukturálás | A bizonyítékok szerint az ok strukturális, például az állapot gazdája nem tud kiszolgálni egy új követelményt. | Magas; feature-ökkel versenyez, és lépcsőzetes terv kell hozzá. | Lépcsőzetes mérföldkövek, mindegyik saját átvételi feltétellel. |
Egy megbízható audit nem ugrik rögtön az újraírásra. A megállapítások nagy része az első két sorba kerül. Ha mégis átstrukturálást javasol, mellé kell tennie a bizonyítékot, hogy a kisebb beavatkozás nem elég, és egy olyan tervet, ami nem fagyasztja be a fejlesztés többi részét.
Az audittól a co-development átadásig
Az audit akkor válik hasznossá, amikor a megállapításaiból olyan munkacsomag lesz, amit egy külső csapat a sajátjaként vihet. Mielőtt elindul a megvalósítás, négy dologban egyezzetek meg.
Felelősségi körök. Jellemzően te felelsz a repository hozzáférésért, a branch szabályokért és a code review rendjéért, a termékprioritásokért és a leszállított munka átvételéért, valamint a cél hardverért és a platformkövetelményekért. A külső csapat felel az általa leszállított munka mérnöki minőségéért, minden optimalizálási állítás reprodukálható méréséért és a belső fejlesztőiddel közös, világos felelősségi határokért.
Függőségek. A csomag minden megállapításánál írd le, mitől függ: más megállapításoktól, tartalomszállításoktól, egy package frissítéstől, egy eszközhöz való hozzáféréstől, egy design döntéstől. A le nem írt függőségekből olyan csúszások lesznek, amelyekért senki sem felel.
Review. Döntsétek el, ki nézi át a pull requesteket, milyen gyakran mutatjátok be a haladást, és mi történik, ha egy megállapítás nagyobbnak bizonyul a becsültnél. Az audit átvételi feltételei adják a review checklistet.
Átadás. Határozd meg, mi jön vissza, amikor a munka kész: mergelt kód, tesztek a módosított szabályok körül, dokumentáció, frissített eszközök és az előtte–utána mérések. A cél egy olyan kódbázis, amit a csapatod tovább tud vinni, nem a külső csapattól való függés.
A különböző felelősségi modelleket, a lehatárolt munkaterülettől a beágyazott fejlesztőkig, a játékfejlesztés oldalon írjuk le. Azt, hogy kifejezetten meglévő Unity projektek auditját hogyan közelítjük meg, a Unity játékfejlesztés oldal mutatja be.
Szemléltető példa egy megállapításra
Szemléltető példa. Az alábbi megállapítás kitalált. Nem valódi ügyfelet vagy projektet ír le, és nincs benne mért érték. Csak azt mutatja meg, hogyan néz ki a sablon kitöltve.
| Mező | Tartalom |
|---|---|
| Probléma | A harci hullámok alatt az ellenfelek spawnoláskor prefabból példányosodnak, és a spawn logika minden ellenfélnél ideiglenes kollekciókat foglal. |
| Bizonyíték | CPU-profil az egyeztetett cél hardveren, megismételhető forgatókönyvben (egy rögzített mentés a harmadik hullám elejéről). A kiugró frame-ekben példányosítás és garbage collection látszik a spawn kódúton. A kód helye hivatkozva. |
| Hatás a játékosra / az üzletre | A játékosok minden hullám legintenzívebb pillanatában akadást látnak. VR célplatformon ugyanez kényelmi probléma is lenne. Az értékelésekben és a playtest jegyzetekben „szaggatásként” jelenik meg. |
| Prioritás | P1: minden játékmenetet érint, és blokkolja a következő mérföldkőhöz rögzített teljesítményszintet. |
| Javasolt beavatkozás | Gyors javítás: előre feltöltött pool a hullámban használt ellenség prefaboknak, és a spawnonkénti foglalások kivétele a spawn kódútból. A forgatókönyv bekerül a rendszeres teljesítményellenőrzésbe, hogy a hiba ne térhessen vissza észrevétlenül. |
| Átvételi feltétel | Ugyanabban a forgatókönyvben, ugyanazon a hardveren a hullám alatt egyetlen frame sem lépi túl az egyeztetett frame-idő keretet, és bemelegítés után a spawn kódút spawnonként nem foglal managed memóriát. Az előtte–utána felvételek a pull requesthez vannak csatolva. |
Figyeld meg, mi nincs a példában: megígért százalékos javulás. Az átvételi feltétel a projekt saját keretéhez kötődik, és ugyanúgy mérjük, mint a bizonyítékot. Ettől lesz átnézhető.
Ha a mostani fejlesztésed hálózati játék, ugyanez a sablon működik a szerver buildekkel és az állapottulajdonnal kapcsolatos megállapításokra is. A Bad Goonsban, a jelenleg aktív fejlesztés alatt álló saját IP-nkben a Unity 6 kliens, a FishNet realtime réteg, a voxel szimuláció és a Linux dedikált szerverek külön fejlesztési rendszerként kezelődnek, és egy auditnak pont ezt a szétválasztást kell keresnie vagy javasolnia. A VOXSYS esettanulmány ugyanennek a fegyelemnek a teljesítményoldalát mutatja.
Checklist egy audit ajánlat értékeléséhez
Tedd fel ezeket a kérdéseket, mielőtt jóváhagysz egy auditot, és újra, amikor megkapod a riportot.
- Az ajánlat megnevezi a döntést, amit az audit alátámaszt, nem csak a vizsgált területeket.
- Fel vannak sorolva a szükséges bemenetek: Unity verzió, render pipeline, célplatformok és hardver, build lépések, reprodukálható hibák, meglévő profilok, scope és felelősségi körök.
- A teljesítményvizsgálat reprezentatív cél hardveren, megismételhető forgatókönyvekben történik.
- A vizsgálat lefedi az architektúrát, a package-eket, a scene-eket, az adatfolyamokat, az eszközöket, a build pipeline-t és a teljesítményt, vagy megindokolja, miért marad ki egy terület.
- Minden megállapításban lesz probléma, bizonyíték, játékos- vagy üzleti hatás, prioritás, javasolt beavatkozás és átvételi feltétel.
- A megállapítások egymáshoz képest rangsoroltak, nem mind „magas”.
- Minden beavatkozás be van sorolva gyors javításnak, fokozatos refaktornak vagy nagyobb átstrukturálásnak, a fejlesztési kockázatával együtt.
- Minden átstrukturálási javaslat mellett ott a bizonyíték, hogy a kisebb módosítás nem elég, és egy terv, ami nem fagyasztja be a tartalomgyártást.
- A riport munkacsomaggal zárul: felelősségi körök, függőségek, review folyamat és átadandó elemek.
- Az optimalizálási állításokat ugyanabban a forgatókönyvben készült előtte–utána mérések támasztják alá.
- A saját csapatod a külső csapat nélkül is ellenőrizni tud minden megállapítást.