A tanulási folyamatból következik, hogy a fejlesztő hibát fog okozni a programban, mégpedig elég sokat. A fejlődés során kitapasztaljuk, hogy hogyan érdemes fejleszteni, de ez nem egy gyors folyamat. A sok-sok próbálgatás és felfedezőút helyett érdemes a már bejárt utakat választani, mert így nagyon sok fejfájástól kíméljük meg magunkat, nem beszélve arról, hogy nagyon sok időt megspórolhatunk. Ha már tapasztaltabbak leszünk, természetesen kipróbálhatunk új munkafolyamatokat, de az alapokkal jobb, ha már az elején tisztában vagyunk.

Ebben a leírásban megpróbáljuk összefoglalni a leggyakrabban elkövetett hibákat. Megtudhatjuk, hogy miért nem érdemes bizonyos gyakorlatokat követni és mi lenne helyettük a jó megoldás.

A leggyakoribb fejlesztő hiba: fejesugrás a fejlesztésbe

A tervezés unalmas lehet, de fontos, hogy időt szánjunk rá. Nincs is annál rosszabb és időrablóbb, mint amikor kiderül, hogy bizonyos játékelemek, vagy maga a koncepció nem fog úgy működni, mint ahogyan azt az elején képzeltük. Egy ilyen hiba nagyon sok átalakítást hoz magával, nagyon sok kódot kell újraírni. Legrosszabb esetben az alapoktól kell újra felépíteni a játékunkat.

fejlesztő tervezés

fejlesztő tervezés

Gondos tervezést követően is előfordulhat, hogy valami szépen mutat a tervezőasztalon, de a valóságban már nem lesz egészen olyan. A tervezési fázis ennek ellenére fontos, mert minimalizálja a hibalehetőséget. Ha esetleg becsúszik valami probléma, akkor is csak kisebb korrekciókra lehet szükség.

Csapatban való munka során kiemelten fontos lépés a tervezés, hiszen a rögtönzés ilyenkor biztos recept a káoszra.

Érdekel a játékfejlesztés? Gyere el bemutató napunkra

Fejlesztő optimalizáció hiánya

Van egy csúcstelefonod? Hasít rajta a játék? Ez nagyszerű, de a játékosok nagyon kis százaléka rendelkezik csúcskategóriás eszközzel. Egy komolyabb játék csak kompromisszumokkal fog futni gyengébb gépen, de a fejlesztő feladata, hogy a legtöbbet kihozza a rendelkezésre álló erőforrásokból.

fejlesztő optimalizáció

fejlesztő optimalizáció

Amit vegyünk számításba:

  • Majdnem kész a projekt. Újra kell alkotni vagy módosítani kell pár modellt az optimalizáció jegyében. Esetleg át kell rendezni a scene-t. Mennyi időt is vitt ez el?
  • Módosítanunk kell egy szkripten ahhoz, hogy javítsuk a teljesítményt, de emiatt másik kettőt is módosítani kell. Hmmm… úgy néz ki, hogy egy harmadikat is kicsit módosítani kell. És így ismét nagyon sok idő ment el.

Ha hasonló szituáció kerülünk, akkor az azt jelenti, hogy sok technikai adósságot (technical debt) hagytunk magunk után. Érdemes már az elejétől törekedni a jó minőségű, gyors kódra. A projekt végén történő ellenőrzés során az az igazi, ha már csak apró finomításokra és optimalizálásra van csak szükségünk.

Fejlesztő hibák felderítése

Már az első fejlesztő napunktól kezdve fogunk hibákat tapasztalni. A hibák és a figyelmeztetések sokaságára számítsunk egy komolyabb kódnál. A Unity szerencsére sokat segít abban, hogy megtaláljuk és kijavítsuk a hibákat. A Unity szerkesztője sokszor ad jó tippet arra, hogy hogyan is lehetne javítani a kódot, ezért érdemes megfontolni a javaslatokat.

fejlesztő error

fejlesztő error

Az esetek többségében egyszerűen orvosolható problémáról van szó. Inspector nézetben csak pár dolgot át kell rendezni, vagy egy paramétere hibás egy gameobject-nek és más hasonló apróságok. Régen frissített asset-ek vagy szkriptek használatánál viszont már könnyen lehet, hogy sok időt fogunk tölteni hibakereséssel. Mindig törekedjünk a Unity verziónkkal is tesztelt asset-ek használatára.

Problémák a fizikával

Számos kis dolog van, ami miatt a fizika furán működhet. Ha bizarr dolgokat tapasztalunk, az alábbiakat nézzük meg elsőként:

  • Ellenőrizzük az elírásokat. Például ne-e írtunk véletlenül “OnColisionEnter()“-t OnCollisionEnter() helyett.
  • Ügyeljünk a 2D/3D közti különbségre. Ha 2D-ben dolgozunk, ne felejtsük el, hogy a 2D-hez készült függvényeket használjuk, mint például OnCollisionEnter2D(). Ha lehagytuk a “2D”-t, a kód nem fog működni, de nem fogunk látni se hibát, se figyelmeztetést.
  • Ha ezek után is furcsán működik a fizika, ellenőrizzük a scale beállítását a gameobject-eknek. Törekedjünk az (1, 1, 1)-es értékekre ott, ahol lehet.
  • Amennyiben egy gameobject rendelkezik RigidBody komponenssel, és szeretnénk mozgatni, kerüljük a transform paraméter kézi módosítását. Mozgatás esetén legtöbbször az AddForce hozza a legjobb, legélethűbb eredményt.

Unity fejlesztő képességeinek hiányos ismerete

fejlesztő unity

fejlesztő unity

A Unity segíti a fejlesztést, de ehhez ismernünk kell a képességeit is ahhoz, hogy ki tudjuk aknázni. Az Asset Store-t is érdemes felfedeznünk. A sok asset között biztosan találunk olyat, amelyre szükségünk lehet. Nem kell újra feltalálnunk a kereket, sok funkciót készen megkapunk, esetleg kisebb módosításokra lehet csak szükségünk.

Bónusz tippek

A gyorsabb és fájdalommentesebb fejlesztés érdekében pár tipp és trükk:

  • Szokjuk meg, hogy minden 15-20 percben mentünk. Ha lefagy a gép, áramszünet, vagy idegenek inváziója van, akkor ne vesszen oda a napi munkánk. A scene újrarendezését is érdemes megúszni, mert ugyanolyan valószínűleg már úgysem lesz.
  • Rakjunk csalásokat a játékba. Csalás alatt itt a GTA-ban megszokott csalásokra kell gondolni, mint például halhatatlanság, végtelen lőszer. Sokkal gyorsabban fogunk tudni tesztelni.
  • Szkript-ek elnevezésénél mindenképpen használjunk valamilyen sémát. Nagyon meg tudja gyorsítani a munkát, ha tudjuk pontosan már a név alapján, hogy éppen melyik szkriptbe mászunk bele. Gyorsan átnevezni az F2 gombbal tudunk. Ez a gyorsbillentyű működik minden név esetében, legyen szó metódusról vagy változóról.

A leírtak már kiállták az idők próbáját, ezért is érdemes fentiek alapján dolgoznunk. Kezdőként pedig az a legjobb, ha már eleve így szokjuk meg a játékfejlesztés folyamatát, utána már minden ösztönösen fog menni.

Forrás: TheAppGuruz

Skeldar