A triage egy túldramatizált kifejezés, a folyamat mindig fontos, ám ritkán esik róla szó. Változtassunk ezen.
Fotó: Brett Jordan / Unsplash
A játékfejlesztésben a triage egyike azon tevékenységeknek, melyek folyamatosan történnek, a játékiparba érkezők alig beszélnek róla, ráadásul kissé homályosan határozzák meg a különböző stúdiók és a játékipar egyéb résztvevői. Általánosságban elmondható, hogy ha készítettél egy játékot, akkor triage is történt, de lehet, hogy soha nem definiáltad vagy beszéltél róla. Általában azt jelenti, hogy a feladatokat egy (remélhetőleg előre meghatározott) fontossági és megvalósíthatósági rendszer szerint rangsoroljuk.
A triage a soft science kategóriába sorolható – részben művészet és kreativitás, részben táblázatkezelőkben vezetett tervezés, részben gyártás (és gyártási adósság), részben pedig a körülmények felmérésének képessége. Nincs helyes módja, viszont rengeteg rossz módszer létezik.
Amikor azt mondom, hogy nincs helyes módszer, képzeld el ezt a (kissé utópisztikus) példát: pár heted van a játékod kiadásáig, és úgy tűnik, minden rendben van. Rengeteg kívánságlistán szerepel a játék, és teljesen stabil. A QA utolsó tesztjéből hirtelen kiderül, hogy az utópiából disztópia lett: a legutóbbi változtatások 2 új hibát hoztak.
Az egyik a végigjátszások 99%-ában előjön, a játék elején, és egyértelmű bosszúságot okoz a tutorial során, amikor az értesítés ottragad a képernyőn. Nyilvánvaló, hogy néhány embert ez annyira felbosszanthat, hogy bugosnak ítéli a játékod és bezárja – de a bug nem okoz összeomlást vagy olyan helyzetet, amelyből a játékos ne tudná folytatni a játékot.
A másik hiba a végigjátszások 0,00001%-ában jön elő, közel a játék vége felé, és nem csak összeomlik a játék, de az is előfordulhat, hogy véletlenszerűen tönkreteszi a felhasználó gépén lévő fájlokat. Nagyon kicsi az esélye annak, hogy ezek a fájlok fontosak vagy kritikusak a számítógépen található rengeteg fájl miatt, de fennáll az esélye.
Csak az egyik bugot van időd kijavítani a kiadás előtt, a másikat pedig majd csak egy hónappal utána. Szóval, mi a helyes?
Egy érv szerint olyan kicsi az esélye annak, hogy valami rossz történjen (1 a 10 000 000-hoz, csak a játék vége felé, és még akkor sem valószínű, hogy a kritikus fájlok megsérülnek), hogy a játék elején lévő gyakori bosszúság fontosabb – egy bugos tutorial után rendkívül lecsökken annak az esélye, hogy valaki végig is játssza a játékot.
A másik érv az, hogy minden ismert dolog, ami károsíthatja a felhasználói fájlokat, a bizalom megsértésének tekinthető, és a stúdió szélsőséges kritikával és bizalmatlansággal (és talán jogi felelősséggel) találhatja szemben magát. Mint ilyen, annak ellenére, hogy kicsi az esély, érvelhetsz amellett, hogy ennek a kijavítása sokkal fontosabb.
Tehát, melyik a jó döntés? Nem tudom megmondani: ezt tényleg neked, a producerednek vagy a stúdiódnak kell kitalálni. Személyes preferenciám mindig is a felhasználó védelme volt, ezért mindig előnyben részesítem azokat a kérdéseket, amelyek károsíthatják a felhasználó eszközét vagy adatait, majd a felhasználói élményt, ezután jöhet minden, ami ezeknek nem árt. Ismerek olyan stúdiókat is, amelyek elég durva hibákra húztak lapot, de jól jöttek ki belőle.
Ez nyilvánvalóan egy szélsőséges példa volt, de módosíthatod, hogy kevésbé legyen az. Mi van akkor, ha a gyakori hiba, ami a mentés visszatöltésével javítható, a játékosok 5%-ánál fordult elő a tutorial során, a kis valószínűségű hiba pedig egy összeomlás és kilépés az asztalra, ami szintén a játékosok 5%-ánál fordult elő? Vagy mi van akkor, ha az egyik újdonság egy hozzáadott jelenet a játék elején (ahol a legtöbb játékos látni fogja), a másik pedig egy jelenet, amit a végére kerül (ahol kevesebben látják, de ők elkötelezettebbek )?
Az ok amiért az ipar hazsnálja a „triage” kifejezést, valószínűleg az orvosi terminológiából származik, ahol úgy definiálják, hogy „olyan gyakorlat, amelyre akkor hivatkoznak, ha rendes ellátás az erőforrások hiányában nem biztosítható. A folyamat előnyben részesíti azokat, akiknek a legnagyobb szükségük van a segítségre, és akiknek a legnagyobb hasznuk származik belőle”. A játékipar hajlamos arra, hogy túldramatizálja a szakszavait, de tagadhatatlan, hogy az erőforrások hiánya általános probléma: a triage a fejlesztés teljes idején történik. Az is igaz, hogy a komplex triage megoldásai gyakran... kreatívak.
Az egyik kedvenc példám a triage-ra egy tervező volt, akit megkértek egy fizikával kapcsolatos hiba javítására. A hiba miatt az egész pályán leesett a framerate, és túlterhelődött az audio rész is, ami így csikorgó hangot hallatott: a szinten lévő összes tárgy egy kicsivel a talaj felett jött létre, és a motor valamiért ragaszkodott hozzá, hogy mindezt egyszerre kezelje. Az sem segített, hogy a jelenet egy helikopter látványos lezuhanásával indult – egy ilyen adrenalin pumpáló rész után technikai hibákkal találkozni eléggé kiábrándító.
Végül a tervező úgy "javította" a hibát, hogy elsötétítette a képet, elnémította az audiot, megvárta, amíg hiba lefut a sötét képernyő mögött, hang nélkül - majd ismét visszaállította képet, egy hangos zugó fül effekttel. A javítás végül hozzá is adott a jelenethez, szó szerint egy sufni megoldás javított rajta.
Ez a fajta trükk is triage. A fejlesztés során lesznek olyan időszakok, amikor rendesen meg tudod javítani a dolgokat – és lesznek olyan időszakok, amikor nem. Mindaddig, amíg a problémát úgy oldod meg, hogy minimálisra csökkented a javítással bevezetett problémák mennyiségét vagy súlyosságát – az egy megoldás. Gyakran (de nem mindig) jobb, ha van néhány ritka és alig észrevehető hiba, mint egy látványos. És az is triage, amikor rájössz, hogy a ritka és alig észrevehető hibák egyike később súlyosabb következményekkel járhat, és ezt most ki kell javítanod.
A triage annak az elfogadása is, hogy valamit nem javítasz ki, mert a javítás alkalmazásának kockázata meghaladja annak előnyeit. Ez ahhoz a gyakori félreértéshez vezet, hogy "a tesztelők nem találták meg a hibát" – gyakran előfordul, hogy a tesztelők megtalálták a hibát és jelentették is azt, de a triage más problémákat részesített előnyben, vagy nem akart stabilitási gondokat kockáztatni a javítás miatt.
Csak hogy hangsúlyozzam egy korábbi, de kissé finom megjegyzésemet: a triage nem csak a hibákra vonatkozik - a funkciókra és a tartalomra is. Csakúgy, mint bárminél, ami bekerült a játékba, vagy kikerült onnan, az előnyök és kockázatok mérlegelése kritikus fontosságú a lehető legzökkenőmentesebb fejlesztés biztosításához.
Az én személyes triage rendszerem egy félvállról odavetett megjegyzésen alapul, amit valaki a Vlambeernél mondott még a 2010-es évek elején (ott találtam az első utalást a kifejezésre). Nem emlékszem, hogy a társalapítóm, Jan Willem, vagy egy szabadúszó, aki velünk dolgozott, vagy én találtam ki – de azóta is ezt a kifejezést használom: mennyit fog érni Metacriticen ez az erőfeszítés?
A Metacritic összesíti az interneten található - kritikusok és felhasználók által adott - pontszámokat egyetlen pontba, ami egyszerre áldás és átok az iparág számára. Egyrészt segít az embereknek gyorsan felmérni, hogy egy játék mennyire jó, de az alattomos gyakorlatok már régóta bónuszokat és promóciókat ígérnek a Metacriticen lévő pontszámért cserébe.
Ez nyilván (részben) csak vicc, de segített megértetni a nem-producerekkel is, hogy mit értek triage alatt. Szeretnéd hozzáadni ezt a pályát? Hát, legalább két hónapba telik, hogy elkészítsük, és csak négy hónapunk van hátra – szerinted, mennyit fog ez érni Metacriticen? Ha a válasz csak 0,1 pluszpont, akkor lehet, hogy nem éri meg a hátralévő fejlesztési idő felét rászánni. Lehetne érvelni pro és kontra, hogy pontosan mennyit ér Metacriticen egy funkció, vagy mennyit von le egy hiba – de általában valamilyen megállapodásra kell jutnotok.
Producerként rendkívül fontos, hogy a motiváció megmaradjon a fejlesztés végén is, a csapat bevonása, valamint annak egyértelmű kommunikálása, hogy a lehető legjobb játékot próbálod szállítani, ahelyett, hogy csak nemet mondasz mindenre, valóban segíthet. Az, hogy milyen rendszert használsz, teljesen rajtad múlik: én a hülye Metacriticeset használom – te bármit használhatsz, ami segít a kommunikációban.
Ne feledd: a triage a prioritás, a szükségesség és a megvalósíthatóság függvénye. Mindaddig, amíg a rendszered mindezt szem előtt tartja, világosan kommunikálja, és előre meghatározza, nem lesz gond. Menet közben is alkalmazkodhatsz, ha van időd, de a stresszes fejlesztési időszakokban gyakran nem lesz idő a döntésekre: a legutolsó dolog, amit szeretnél, hogy arról kelljen vitatkozni, hogy a csapat miként dönti el, mi lesz javítva, mialatt elfogy az idő bármilyen javítás elvégzésére.
GYAKORLATOK
Tégy magadnak egy szívességet, és nézd meg Mike Acton hihetetlen, 2017-es GDC előadását a kommunikációról, a megtérülésről és a triage-ról.
Akár egyedül, akár csapatban dolgozol, próbálj meg egy működőképes triage rendszert létrehozni. Döntsd el, alapesetben mi kap prioritást: fontosabb a súlyosság, mint a gyakoriság? A játék elején lévő bug, vagy a játék végén lévő? Beszéljétek meg a lehetséges forgatókönyveket, és próbáljatok működő rendszert létrehozni belőlük. Dokumentáld, és mentsd el valahova, ahol mindenki, aki érintett a triage-ban, megtalálhatja, ha szükséges.
Alaposan gondold át a triage-zsal kapcsolatos kommunikációd: gondoskodsz arról, hogy a csapat megértse, miért születnek bizonyos döntéseket? A megfelelő embereket vonod be a döntéshozatalba? Nem lehet mindig szórakoztató döntéseket hozni, és a triage néha lehangoló, mert tudod, hogy bizonyos problémák további gondot okoznak, és nem tudod megoldani azokat - de fontos, hogy továbbra is reflektálj a kommunikációra. Ha csapatban dolgozol, egy triage folyamat után nézd meg, kaphatsz-e visszajelzést a legfontosabbaktól. Ha egyedül dolgozol, nézd meg, hogy a folyamat során fenn tudod-e tartani a motivációd, a mentális egészséged és a boldogságod.
