Žaidimų kūrimas su Unity

Kodėl Unity, o ne kas nors kitas?

Jei kada nors galvojai apie žaidimų kūrimą, greičiausiai susidūrei su klausimu: kurį variklį rinktis? Unreal Engine atrodo galingas ir vizualiai įspūdingas, Godot – atviro kodo ir lengvas, o Unity… Unity yra kažkur per vidurį, bet tuo pačiu metu – visur. Ir tai nėra atsitiktinumas.

Unity šiandien naudoja apie 50% mobiliųjų žaidimų kūrėjų pasaulyje. Tai nėra tik statistika – tai realybė, kurią jauti, kai atsisiunti kokį nors indie žaidimą iš „App Store” ar „Google Play”. Didžioji tikimybė, kad jis sukurtas būtent šiuo varikliu. Tačiau Unity nėra vien tik mobiliųjų žaidimų reikalas – juo kuriami PC žaidimai, konsolių projektai, VR/AR aplikacijos ir net architektūrinės vizualizacijos.

Pagrindinis Unity privalumas pradedantiesiems – žema įėjimo riba. Tai nereiškia, kad jis paprastas. Tai reiškia, kad galima pradėti kažką kurti per pirmą dieną ir nesijausti visiškai pasiklydusiu. Unreal Engine su savo vizualiniais „Blueprints” irgi bando tą patį, bet C++ pagrindas ir sunkesnė aplinka daro jį sudėtingesniu pasirinkimu tiems, kas tik pradeda.

Be to, Unity turi vieną iš geriausių dokumentacijų žaidimų kūrimo pasaulyje. Ne tobulą – kartais rasi pasenusios informacijos ar neaiškių paaiškinimų – bet pakankamai gerą, kad galėtum išspręsti daugumą problemų be ilgų Google paieškų.

Pirmieji žingsniai: aplinka ir projekto struktūra

Prieš pradedant bet kokį projektą, reikia suprasti, kaip Unity aplinka veikia. Tai ne ta situacija, kur tiesiog atsidari programą ir pradedi. Čia yra tam tikra logika, kurią reikia įsisavinti, ir kuo greičiau tai padarysi, tuo mažiau laiko praleisi spręsdamas keistus klaidų pranešimus.

Unity Editor susideda iš kelių pagrindinių langų:

• Scene View – čia matai ir redaguoji savo žaidimo pasaulį vizualiai
• Game View – tai, ką matys žaidėjas paleidus žaidimą
• Hierarchy – visų objektų sąrašas dabartinėje scenoje
• Inspector – pasirinkto objekto savybės ir komponentai
• Project – visi tavo projekto failai, tekstūros, skriptai, prefabai
• Console – klaidos, įspėjimai ir debug žinutės

Projekto struktūra yra vienas tų dalykų, kuriuos pradedantieji dažnai ignoruoja ir vėliau gailisi. Kai projektas mažas, atrodo, kad viskas gerai. Kai jis auga, chaotiška failų struktūra tampa tikru košmaru. Rekomenduoju iš karto susikurti tokią aplankalų struktūrą:

Assets/
├── Scripts/
├── Prefabs/
├── Materials/
├── Textures/
├── Audio/
├── Scenes/
└── Animations/

Tai nėra vienintelis teisingas būdas, bet tai yra logiškas pradinis taškas. Svarbiausia – nuoseklumas. Jei pradedi laikyti skriptus vienoje vietoje, laikyk juos ten visada.

Dar vienas svarbus dalykas – Version Control. Naudok Git nuo pirmos dienos. Net jei dirbi vienas. Net jei projektas mažas. Unity su Git kartais elgiasi šiek tiek keistai dėl binarinių failų, todėl rekomenduoju į .gitignore įtraukti Library/, Temp/ ir Logs/ aplankus. Unity juos regeneruoja automatiškai, tad saugoti juos repozitorijoje nėra prasmės.

C# Unity kontekste: ką reikia žinoti

Unity naudoja C# kaip pagrindinę skriptavimo kalbą. Tai gera žinia – C# yra stipriai tipizuota, objektiškai orientuota kalba su puikia IDE palaikymu. Bloga žinia – Unity C# turi tam tikrų specifinių dalykų, kurie gali suklaidinti tuos, kas jau moka „grynąjį” C#.

Pats svarbiausias konceptas – MonoBehaviour. Tai bazinė klasė, iš kurios paveldi beveik visi Unity skriptai. Ji suteikia prieigą prie gyvavimo ciklo metodų:

public class PlayerController : MonoBehaviour
{
    void Awake()
    {
        // Iškviečiamas prieš Start(), net jei objektas išjungtas
    }
    
    void Start()
    {
        // Iškviečiamas vieną kartą, kai objektas aktyvuojamas
    }
    
    void Update()
    {
        // Iškviečiamas kiekvieną kadrą
    }
    
    void FixedUpdate()
    {
        // Iškviečiamas fiksuotais intervalais, naudok fizikai
    }
}

Čia yra viena dažna klaida, kurią daro pradedantieji: jie deda fizikos logiką į Update() vietoj FixedUpdate(). Skirtumas yra svarbus. Update() iškviečiamas tiek kartų, kiek yra kadrų per sekundę – tai gali būti 30, 60 ar 144 kartai. FixedUpdate() iškviečiamas fiksuotu dažniu (pagal nutylėjimą 50 kartų per sekundę), nepriklausomai nuo kadrų dažnio. Fizikos skaičiavimai turi būti nuoseklūs, todėl jie turi eiti per FixedUpdate().

Kitas svarbus dalykas – Coroutines. Tai Unity būdas atlikti asinchronines operacijas be sudėtingų thread’ų. Pavyzdžiui, jei nori, kad kažkas įvyktų po 2 sekundžių:

IEnumerator WaitAndDoSomething()
{
    yield return new WaitForSeconds(2f);
    Debug.Log("Du sekundi praėjo!");
}

// Paleidimas:
StartCoroutine(WaitAndDoSomething());

Coroutines yra labai naudingos, bet turi ir trūkumų – jas sunkiau debuginti, ir jos gali sukelti atminties nutekėjimą, jei nėra tinkamai valdomos. Šiuolaikiniuose Unity projektuose vis dažniau naudojamas UniTask paketas arba Unity Awaitable sistema, kuri leidžia naudoti tikrąjį async/await sintaksę.

Fizika, animacijos ir vizualinis pasaulis

Unity turi du fizikos variklius: PhysX 3D fizikai ir Box2D 2D fizikai. Abiem atvejais principas panašus – objektams pridedi Rigidbody komponentą, ir Unity pradeda juos valdyti pagal fizikos dėsnius.

Tačiau čia yra subtilybių. Jei nori judinti objektą, turintį Rigidbody, nenaudok Transform.position tiesiogiai – tai „teleportuoja” objektą ir sulaužo fizikos skaičiavimus. Vietoj to naudok:

• Rigidbody.MovePosition() – sklandus judėjimas su kolizijomis
• Rigidbody.AddForce() – jėgos pridėjimas fizikos simuliacijai
• Rigidbody.velocity – tiesioginis greičio nustatymas

Animacijos sistemoje Unity naudoja Animator su Animation State Machine. Tai vizualinis įrankis, leidžiantis sukurti animacijų perėjimus pagal tam tikras sąlygas. Pavyzdžiui, personažas pereina iš „Idle” į „Run” animaciją, kai greitis viršija tam tikrą ribą. Iš kodo tai valdoma per parametrus:

Animator animator = GetComponent<Animator>();
animator.SetFloat("Speed", currentSpeed);
animator.SetBool("IsJumping", isJumping);
animator.SetTrigger("Attack");

Vizualiniam pasauliui Unity siūlo du rendering pipeline’us: Universal Render Pipeline (URP) ir High Definition Render Pipeline (HDRP). Yra ir senasis Built-in pipeline, bet naujiems projektams jo rinktis neverta. URP yra geras pasirinkimas daugumai žaidimų – jis veikia gerai tiek mobiliuosiuose, tiek PC. HDRP skirtas aukštos kokybės vizualizacijoms, bet reikalauja galingesnės aparatinės įrangos.

Svarbus patarimas: jei pradedi naują projektą, iš karto nuspręsk, kurį pipeline naudosi. Perjungimas vėliau yra skausmingas procesas – visi materialai turi būti konvertuoti, ir ne visada automatiškai.

Žaidimų architektūra: kaip nesukurti spaghetti kodo

Tai turbūt svarbiausia tema, apie kurią rašoma mažiausiai pradedantiesiems skirtose pamokose. Visi moko, kaip padaryti, kad personažas judėtų. Niekas nemoko, kaip struktūruoti kodą taip, kad po šešių mėnesių galėtum jį suprasti.

Dažniausia klaida – vienas milžiniškas GameManager skriptas, kuris valdo viską: žaidėjo sveikatą, priešų AI, UI atnaujinimą, garso efektus ir dar dešimt kitų dalykų. Tai vadinamasis „God Object” antipattern, ir jis yra tikras pragaras, kai reikia kažką pakeisti ar pridėti.

Yra kelios architektūros, kurios gerai veikia Unity kontekste:

ScriptableObject-based architektūra – Unity ScriptableObjects leidžia saugoti duomenis ir logiką atskirai nuo scenos objektų. Tai puiku žaidimų duomenims (ginklų statistika, personažų savybės) ir net event sistemoms. Ryan Hipple’s „Game Architecture with Scriptable Objects” GDC pranešimas yra privalomas žiūrėjimui.

Event-driven architektūra – vietoj to, kad objektai tiesiogiai referencuotų vienas kitą, jie komunikuoja per events. Unity turi savo UnityEvent sistemą, bet daugelis kūrėjų renkasi paprastesnius C# events arba ScriptableObject-based event kanalus.

MVC/MVP pattern – ypač naudingas UI sistemoms. Model laiko duomenis, View rodo juos, Controller/Presenter valdo logiką tarp jų.

Praktiškai, net jei nenori gilintis į sudėtingas architektūras, laikykis bent šių taisyklių:

• Vienas skriptas – viena atsakomybė
• Venkite GameObject.Find() – tai lėta ir trapi
• Naudokite [SerializeField] vietoj public laukų, kai nereikia išorinio priėjimo
• Komentuokite ne tai, ką kodas daro, o kodėl

Optimizacija: kai žaidimas pradeda strigt

Anksčiau ar vėliau susidursi su situacija, kai žaidimas veikia lėtai. Gal FPS krenta, gal yra stutter’iai, gal žaidimas tiesiog jaučiasi „sunkus”. Prieš pradedant optimizuoti, reikia suprasti vieną svarbų principą: niekada neoptimizuok spėliodamas. Naudok Profiler.

Unity Profiler (Window → Analysis → Profiler) parodo tiksliai, kur eikvojamas laikas ir atmintis. Dažniausios problemos, kurias rasi:

Garbage Collection – C# automatiškai valdo atmintį, bet GC pauzės gali sukelti matomus freeze’us. Problemos šaltinis dažnai yra kodo, kuris kiekvieną kadrą sukuria naujus objektus. Pavyzdžiui, string concatenation su + operatoriumi sukuria naują string objektą kiekvieną kartą. Vietoj to naudok StringBuilder arba string.Format().

Draw Calls – kiekvieną kartą, kai GPU turi piešti ką nors nauja, tai yra draw call. Per daug draw calls = lėtas rendering. Sprendimai: GPU Instancing panašiems objektams, Sprite Atlases 2D žaidimams, LOD (Level of Detail) sistemoms 3D žaidimams.

Physics – per daug collider’ių ar sudėtingos Mesh Collider formos gali stipriai sulėtinti fizikos skaičiavimus. Naudok paprastas geometrines formas (Box, Sphere, Capsule) kai tik įmanoma. Taip pat peržiūrėk Physics Layer Collision Matrix – galbūt kai kurie sluoksniai visai neturi tikrinti kolizijų tarpusavyje.

Object Pooling – jei žaidime dažnai kuriami ir naikinami objektai (kulkos, efektai, priešai), kiekvienas Instantiate() ir Destroy() yra brangus. Object Pooling – tai technika, kai objektai nėra naikinami, o tiesiog išjungiami ir vėl panaudojami. Unity 2021+ turi įmontuotą ObjectPool<T> klasę, kuri tai palengvina.

Asset Store ir ekosistema: ką verta naudoti

Unity Asset Store yra ir palaiminimas, ir prakeiksmas. Viena vertus, galima rasti beveik viską – nuo pilnų žaidimų šablonų iki specifinių įrankių. Kita vertus, lengva nusipirkti krūvą assetų, kurių niekada nepanaudosi, arba sukurti projektą, kuris yra tik kitų žmonių darbų mozaika.

Keletas assetų/paketų, kurie tikrai verti dėmesio:

DOTween – animacijų ir tweening biblioteka. Jei reikia sklandžiai animuoti UI elementus, objektų pozicijas ar spalvas, DOTween yra de facto standartas Unity bendruomenėje. Nemokama versija yra visiškai pakankama daugumai projektų.

Cinemachine – kamerų sistema, kuri yra Unity paketo dalis. Leidžia sukurti sudėtingą kameros elgesį be kodo. Virtual Cameras, Follow targets, Noise – visa tai galima sukonfigūruoti vizualiai.

TextMeshPro – šiuolaikinis teksto rendering Unity. Jei dar naudoji senąjį UI Text komponentą, pereik prie TextMeshPro. Jis yra daug lankstesnis, palaiko custom šriftus, outline efektus ir kitus dalykus be papildomo kodo.

UniTask – jei nori naudoti tikrąjį async/await Unity, šis paketas yra geriausias pasirinkimas. Jis pakeičia Coroutines daug elegantiškesniu sprendimu ir veikia geriau su atminties valdymu.

Dėl mokamų assetų – prieš pirkdamas, visada patikrink recenzijas, paskutinio atnaujinimo datą ir ar paketas palaiko tavo Unity versiją. Nemažai assetų yra apleisti ir nebesuderinami su naujesnėmis Unity versijomis.

Nuo prototipo iki išleisto žaidimo: realybė be rožinių akinių

Žaidimų kūrimas su Unity yra puikus kelias – bet svarbu suprasti, kad kelias nuo „aš išmokau Unity” iki „aš išleidau žaidimą” yra ilgas ir pilnas netikėtų posūkių. Statistika yra negailestinga: didžioji dalis pradėtų žaidimų niekada nebūna baigti.

Pirmasis patarimas – pradėk mažai. Ne „aš sukursiu atvirą pasaulį su RPG elementais ir multiplayer”. Pradėk nuo žaidimo, kurį galima baigti per savaitę ar dvi. Pong. Platformer su penkiais lygiais. Paprastas puzzle žaidimas. Baigtas mažas žaidimas yra be galo vertingesnis nei nebaigtas ambicingas projektas.

Antrasis dalykas – playtesting. Duok savo žaidimą žaisti kitiems žmonėms kuo anksčiau. Tai skauda – ypač kai matai, kaip žmonės nesupranta to, kas tau atrodo akivaizdu. Bet tai yra vertingiausia informacija, kurią gali gauti. Unity turi integruotą Unity Gaming Services platformą su Playtest funkcija, bet net paprastas Discord serveris su draugais gali padėti.

Trečias dalykas – monetizacija ir platforma. Jei planuoji išleisti žaidimą, reikia apgalvoti šiuos klausimus daug anksčiau nei atrodo reikalinga. Steam leidimas kainuoja 100 USD ir reikalauja Steamworks SDK integracijos. Mobiliesiems reikia laikytis Apple ir Google gairių, kurios nuolat keičiasi. Unity pats turėjo nemažai kontraversijų dėl savo kainų politikos – 2023 metais jie bandė įvesti „Runtime Fee” mokestį už kiekvieną žaidimo instaliaciją, kas sukėlė didelį pasipiktinimą bendruomenėje. Galiausiai jie atsitraukė, bet tai parodė, kad reikia sekti Unity verslo sprendimus.

Galiausiai – bendruomenė. Unity bendruomenė yra viena aktyviausių žaidimų kūrimo pasaulyje. Unity Forums, Reddit r/Unity3D, Discord serveriai – visa tai yra puikūs šaltiniai, kai užstrigi. Tačiau svarbiau yra ne tik klausti, bet ir dalintis savo darbu. Game jams – tokios kaip Ludum Dare ar itch.io Game Jam – yra puikus būdas susipažinti su kitais kūrėjais ir priversti save baigti projektą per ribotą laiką.

Unity nėra tobulas įrankis. Jis turi savo keistybių, savo ribojimų ir savo istorinių sprendimų, kurių neįmanoma suprasti be konteksto. Bet jis yra realus, plačiai naudojamas ir turi ekosistemą, kuri leidžia vieniems žmonėms sukurti tai, kas anksčiau reikalavo didelių komandų. Ir tai, galiausiai, yra svarbiausia – ne kurį variklį naudoji, o ar baigi tai, ką pradedi.