5 remek funkció a Unity-ben

Jelen cikk egy sorozat része. A bevezetőt és a többi listát itt éred el:

Nehéz értékelni valamit, ami egyszerűen csak működik, ahogy kell. Hamar megszokjuk a jó dolgokat és csak azt vesszük észre, ha valami nem áll kézre vagy nem pont úgy van, ahogy egyszer megszerettük. Ezért sokkal könnyebb a hibákat és hiányosságokat kiszúrni minden szoftverben, mint értékelni azokat, amik miatt használjuk a prokramot.

Most viszont mégis megpróbálom összeszedni az én személyes kedvenceimet a Unity motor körül, amik ebbe a kategóriába tartoznak. A

5. Az editor bővíthetősége

A játékprogramozó feladata az én szememben elsősorban nem az, hogy “megírja” a végleges játékot magát, hanem hogy ideális eszközöket építsen az adott játék kapcsán felmerülő ötletek megvalósítására amit a játék-dizájnerek kezébe adhat.

Egy videojáték ötlet ritkán állja meg a helyét önmagában manapság. Egy nagy adag kísérletezés és tesztelés kell ahhoz, hogy eljussunk egy ötletből valami olyanig, ami kimagaslik a mai felhozatalból.

A fejlesztő feladata, hogy olyan keretet teremtsen, amiben minél hatékonyabban és rugalmasabban lehet kipróbálni és variálni játékmechanikai ötleteket.

Tehát a programozó elsősorban nem a játékot készíti el. Ez a játék dizájner feladata. A programozó eszközöket készít, amivel az adott játékot le lehet gyártani. Minél kisebb a projekt annál gyakoribb, hogy a két pozíció nem különül el. Én magam is szeretek mindkét feladatkörben részt venni.

Viszont ekkor is érdemes fejben külön választani a két felelősségi kört. Amikor kódolok, akkor felteszem a programozó kalapomat és eszközöket készítek, nem csak egy konkrét mechanikát programozok le egy az egyben. Amikor ezzel végzek, akkor kalapot cserélek és a dizájner perszónám nekiáll használni az eszközöket.

Ez azért hasznos hozzáállás, mert ha egy eszközzel nehéz dolgozni, akkor a munka jóval lassabb. Kevesebb tartalom, pálya, puzzle, boss, kihívás készül el vele egységnyi idő alatt vagy ami még rosszabb, férc munkát végzünk. Ezért hasznos, ha egy oldala a fejlesztésnek nem pusztán a kész játékra koncentrál, sokkal inkább a fejelsztés folyamatát próbálja kidolgozni.

Addig ne álljunk neki játékot gyártani, amíg nincsenek meg az ideális eszközeink. A valóságban ez a két fázis nem különül el ilyen élesen, de az alaplogika továbbra is áll. Ezen eszközök és rendszerek elkészítése gyakorlatilag a játékmotor funkcionalitásának kibővítését jelentik.

Ehhez elengedhetetlen, hogy saját UI felületeket is készíthessünk. A legegyszerűbb verziója mindennek a [SerializeField] beállítások használata, de külön Editor kódot is rendelhetünk MonoBehaviour és ScriptableObject osztályokhoz, amik egyedi módon szabályozzák a kirajzolást.

Emellett készíthetünk egyedi megjelenítést bármilyen szerializált típushoz, és azt attribútumokkal is módosíthatjuk. Végül teljesen független menürendszereket is építhetünk bármilyen feladatra.

4. ScriptableObject

Ahhoz, hogy egy komponenst írjunk a Unity-ben, amit aztán hozzáadhatunk egy GameObject-hez le kell származtatni az új saját osztályunkat a MonoBehaviour-ból. A motor ezután megadott események hatására automatikusan hívogatja ezen osztályok bizonyos speciális metódusait minden betöltött példányra.

Amit most leírtam az a lapja a Unity programozásnak. Minden kezdő játékprogramozó ezt tanulja meg legelőször. Egy csapda azonban, amibe sok kezdő fejlesztő belefut, hogy kizárólag MonoBehaviour osztályokat írnak. Szinte minden játékhoz elengedhetetlen egyéb (akár sehonnan nem öröklő) osztályok írása is. Most azonban a egy másik Unity ősosztályt tekintünk meg, a ScriptableObject-et.

Ahogy egy MonoBehaviour osztály példányait komponensként tudjuk használni, úgy egy ScriptableObject példányaiból speciális Asset fájlokat tudunk készíteni. Ezen asset-eknek nincsenek olyan eseménymetódusai, mint a MonoBehaviour osztályoknak Pl: Start, Update, mégis sokkal hasznosabbak, mint azt elsőre gondolnánk.

Elsőleges feladata ezen osztályoknak és a belőlük készült asset fájloknak, hogy adatokat tudunk bennük tárolni Scene-en kívül. Azután ezen asset-eket hozzáköthetjük [SerializeField] referenciaként MonoBehaviour komponensekhez vagy egyéb ScriptableObject-ekhez. Miért hasznos ez?

1. Újrahasználhatóság: Egy ScriptableObject-et többször MonoBehaviour-ból is használhatunk. Ezáltal egy beállítás több helyen is felhasználható lesz. Egy adatot egyszer állítunk be, egy helyen kell módosítani, ám a hatása sok objektumon érzékelhető lehet. A ScriptableObject tehát egy hatékony eszköz az adatok duplikálásának kerüléséhez.
2. Játék közbeni szerkeszthetőség: A ScriptableObject-eket nem állnak vissza eredeti állapotba a játék futása végén az editorban, így a fejlesztők bármikor változtathatják azokat anélkül, hogy félniük kéne attól, hogy elveszítik a beállításaikat a futás végeztével.
3. Jobban strukturált projekt: A ScriptableObject-eket könnyen szervezhetjük és rendszerezhetjük, ami javítja a játék átláthatóságát és segíti az architektúra megértését, kezelését.
4. Optimálisabb futás: Az első pontból fakadó előny, hogy a ScriptableObject-ek használatával javítható a játék teljesítménye, mivel azokat a memóriában egyszerre tároljuk, és nem kell többször betölteni őket a játék futása során. Ez kevesebb memóriahasználatot és gyorsabb betöltési időket eredményezhet.

3. Prefab rendszer

Prefabok segítségével egy-egy GameObject-ből asset fájlt készíthetünk annak minden beállításával, gyerek objektumával és a gyerek objektumok beállításaival együtt.

Ez lehetővé teszi a fejlesztők számára a játék elemeinek előre elkészített, újrahasznosítható változatainak létrehozását és használatát.

A Unity Prefab rendszer előnyei gyakorlatilag megegyeznek azokkal, amiket a ScriptableObject-ek kapcsán olvashattatok, mivel mind a két eszköz célja az, hogy nagyobb szabadsága legyen a fejlesztőnek a projekt strukturálásában elkerülve az adatok duplikált, redundáns tárolását.

A prefabok önmagokban is létfontosságú eszközök, szuperfegyverré viszont a motor 2018.3-as verziójával váltak, amikor is a Unity nagyot bővített a Prefab rendszer funkcionalitásán.

Ekkor vezette be a Unity a nested azaz egymásba-ágyazott prefabokat és a variánsokat. Korábban egy prefabon belül nem lehetett egy másik prefab, mint gyerekobjektum. Ennek most már semmi akadálya. Emellett variánsok segítségével különböző változatokat készíthetünk prefabokból, úgy hogy minden egyes adatrúl külön megmondhatjuk, honnan származik. Az eredeti prefabból vagy a felülírt variánsból.

Le a kalappal a Unity megoldása előtt. Sok évig kellett várni rá de az eredmény véleményem szerint logikus, elegáns és kézreálló lett.

2. ProBuilder

A 3D képalkotás és művészet világán belül a játékmotorok és modellező szoftverek két jól elkülönülő sziget. Hagyományosan először 3D-ben megalkotunk egy mesh-t majd importáljuk azt a játékmotorba, hogy felhasználhassuk a világunk építéséhez.

Ennek a munkafolyamatnak megvannak az előnyei és hátrányai is. Mindenképp hasznos, hogy a külön szoftverek egy szűkebb területre tudnak koncentrálni és azon belül széles funkcionalitást kidolgozni. Ám erre nem mindig van szükség. Gyakran nem kell nekünk a sok spéci eszköz a modellezéshez, csak az alapok. Cserébe inkább végeznénk a műveleteket motoron belül korlátozott eszközökkel, de közben megspórolva a szoftverek közti súrlódást, exportálást, importálást.

Pont erre használatos a ProBuilder, ami egy Unity-n belüli egyszerű modellező eszköz.

A Pro Builder-rel a fejlesztők egyszerűen létrehozhatják a 3D modelleket az Editorban, úgy hogy nem kell külső szoftverhez nyúlniuk. Az így készült modellek később is gyorsan és egyszerűen módosíthatók a Scene-en belül.

Leginkább pálya építésére használatos az eszköz és azon belül is prototipizáláshoz. A Pro builder leginkább a pályadizájn kezdeti verzióinak kidolgozásában tud hasznos lenni.

Annak ellenére, hogy nem profi modellező szoftverről beszélünk, csak egy játékmotor Plugin-járól, a ProBuilder a hard surface modeling területén belül szinte minden standard eszközt biztosít. A modellező szoftverekben jól megszokott hagyományos extrude, inset, loop cut és bevel eszközökön kívül az UV szerkesztésben és a Bezier görbe alapú modellezésben is kínál lehetőségeket.

Kimelendők

Mielőtt kihirdetném a személyes kedvencemet nézzünk meg még pár remek eszközt, amik épp hogy csak lemaradtak az ötös listámról

Cinemachine:

Egy dinamikus, procedurális kamera rendszer a Unity-ben, amely lehetővé teszi sima, és reszpanzív kamera mozgás létrehozását kódolás nélkül. A Cinemachine-nel a virtuális kamerát, egy összetett szabályrendszer vezényli számtalan beállítási lehetőséggel.

Shader Sraph:

A Shader Graph egy grafikus programozói eszköz a Unity-ben, amely lehetővé teszi a játékfejlesztők számára, hogy egyszerűen és intuitívan készítsenek saját shadereket. A fejlesztők itt kódolás helyett vizuálisan helyezhetnek el és kapcsolhatnak össze művelet blokkokat. Ennek a megközelítésnek az a legfőb előnye számomra a tradicionális shader programozással szemben, hogy a fejlesztők minden egyes lépés után láthatnak egy előzetes nézetet, ami nagyban tud segíteni a debugolásban.

Animation Curve:

Egy hagyományos, az általános iskolából jól ismert 2D függvény működése elég egyszerű. A függvény vár egy számot, mint bemenet és kiköp magából egy másik számot. Ezt akár ábrázolhatjuk is egy 2D grafikonnal. Függvények használata a programozás minden területén elkerülhetetlen. Azt hogy a bemenet alapján milyen kimenet keletkezik általában egy algoritmus írja le. Sok esetben azonban ez nem ideális. Gyakran ahelyett, hogy egy matematikai képletet dolgoznánk ki ami megadja a megfelelő kimenetet a bemenethez, jobban járunk, ha magát a grafikont állítjuk be manuálisan, amivel közvetlenül megadhatjuk, milyen bemenetre milyen kimenetet várunk.

UI System:

Felhasználói felületek elkerülhetetlenül fontos részei a játékoknak. Két szeparált rendszer is létezik Unity-ben UI készítéséhez: egy régi és egy új (Igazából egy harmadik, mégrégebbi is, de azt jobb elfelejteni). Mindkettőnek megvannak a maga előnyei a másikhoz képest. A részletekbe itt nem folyok bele, de alapvetően mindkét rendszer pár zavaró részlettől eltekintve jól átgondolt.

Új input rendszer:

A billentyűzetről és gamepadról származó inputok lekérdezése és felhasználása az Unity eredeti beépített rendszere segítségével egyszerű és nagyon könnyen megérthető. Sajnos ebből az egyszerűségből fakadóan kevéssé alkalmas komplex rendszerek építésére. Az Unity új Input rendszere ezt a lyukat foltozza be.

1. 2D eszközök

A Unity alapvetően egy 3D engine. Aki megnyitotta és használta már a motort, az pontosan tudja, hogy minden objektumnak 3D koordinátái vannak. Mindazonáltal semmi akadálya annak, hogy 2D játékok építésére használjuk a Unity-t. Ekkor a 3. azaz Z dimenziót egyszerűen figyelmen kívül kell hogy hagyjuk.

Nem csak hogy lehetőséget biztosít a Unity a 2D fejlesztéshez, de talán jobb eszközöket is nyújt hozzá, mint bármilyen kifejezetten 2D versenytársa. Ezen eszközök összességét soroltam első helyre a saját listámon.

Egy kicsit csalás, tudom, eszközök egy egész családját venni fel első helyre, de ez az én listám, azt teszek előre amit akarok. 🙂 A helyzet az, hogy nem tudtam csak egyet választani a 2D-s fejlesztői szerszámosládából. Túl jó a felhozatal.

• 2D karakteranimáció

3D modellezésben sok remek eszközünk van arra, hogy becsontozzunk (rigging) és azokon keresztül animáljunk egy modellt egy folyamattal aminek a neve “Inverse kinematics”. Elviekben mindez ugyanúgy kéne működjön 2D-ben is, de erre a feladatra valahogy szegényesebb a szoftveres felhozatal. Szerencsére Unity alatt nincs is szükség egyéb szoftverhez nyúlni ugyanis motoron belül is remekül menedzslhető a feladat.

• 2D fények

A 2D játékfejlesztés legnagyobb előnye az én szememben, hogy nagy művészeti szabadságot biztosít vizuális téren. Valahogy sokkal több egyedi 2D stílussal lehet találkozni, mint a 3D világban. Ez a változatosság még szembe tűnőbb, ha a korábban kifejezetten 3D-re jellemző fénnyel kapcsolatos eszközök, mint az árnyék és csillogás elérhetők 2D-ben is.

• Tileimapok

Gyakran illeszkedik a 2D játékvilág egy rácsszerkezetre. Ez a rács lehet négyzet, rombusz vagy hatszög alapú. Mindegyik esetben nagy hasznunkra fog válni a Unity csemperendszere, amivel könnyen és gyorsan építhetünk grid alapú pályát.

• Spriteshape

Hogy mi a spriteShape, azt könnyebb megmutatni, mint leírni. Az alábbi rövid gif azt hiszem, magáért beszél és jól szemlélteti az eszköz hasznosságát.

Remélem, a fenti lista meghozta minden olvasó kedvét, hogy legalább egy kicsit kisírletezzen a motorral.