Godot yra jėga
Godot yra žaidimų kūrimo variklis. Aš sukūriau žaidimą, kurį galite įsigyti čia.
Šituo tekstu norėčiau pasidalinti savo įspūdžiais apie Godot ir mano patirtį kuriant žaidimą.
Kodėl Godot?
Jeigu tai nėra jūsų pirmas tekstas, galbūt žinote, kad aš kartas nuo karto mėgstu sukurti žaidimus. Aš dažniausiai kuriu labai paprastus žaidimus ir kartais jie tampa neįtikėtinai populiarūs. Mano mėgstamiausia kalba yra Javascript, o variklis, kurį dažniausiai naudojau žaidimų kūrimui – Phaser.
Aš pats labiausiai mėgstu žaisti web žaidimus, tai kaip ir viskas išspręsta ar ne?
Šiais laikais yra labai madinga kurti žaidimus Steam, plius youtube pradėjo man rekomenduoti įvairių indy kūrėjų video, taigi aš pagalvojau: kodėl negalėčiau sukurti žaidimo Steam? Pirmas žaidimas tikrai neuždirbs man milijonų (būkim realistai), bet tai bus įdomi patirtis.
Yra būdų kaip interneto svetaines perkelti į programas. Iš principo supakuoji interneto svetainę kartu su chrome naršykle į vieną failą ir čia tau programėlė. Toks būdas nėra elegantiškas ir jis manęs nežavėjo. Reikėjo kito būdo ir tai reiškė, kad turėsiu išmokti naują įrankį.
Kaip ir kiekvienas save gerbiantis žmogus, pirmiausiai pabandžiau Unity. Unity privalumai, kad jie turi be proto didelę bendruomenę ir daug gerų gidų pradedantiesiems. Bet man Unity nepatiko.
Mane labai nustebino, kad Unity neturi kodo redaktoriaus. Jeigu esi programuotojas, galbūt turi savo mėgstamiausią kodo redaktorių ir jame gali dirbti. Aš neturiu, bet ne problema susirasti. Nemokamu yra daugiau nei dešimt, o pridėjus mokamus, tai iš viso meleonai.
Aš supratau, kodėl programuotojams būtina turėti du monitorius: dirbi su dviem programom iš karto. Kodo redaktoriuje rašai kodą ir tuomet Unity žiūri rezultatus. Su vienu monitoriumi, turi nuolatos spaudinėti alt+tab, kas realiai yra tas pats kaip laikyti ranką ant skruzdėlyno. Kas jaučia tame malonumą?
Dalykas, kuris mane baisiai erzino, kad kiekvieną kartą paspaudus ctrl+s, Unity turėdavo perkompiliuoti žaidimą ir tai užtrukdavo apie minutę. Kitaip sakant, jeigu dirbi 8 valandas (pilną darbo dieną), tai prarandi 1,5 valandos ant perkompiliavimo. Aš įsivaizduoju, kad jeigu turite galingą kompiuterį, tai tas procesas užtrunka sekundę, mano kompiuteris yra kažkur 5 metų senumo.
Kitas dalykas, kuris man nepatiko, tai žaidimų eksportavimas. Aš sukūriau savo pirmą žaidimą pagal gidą. Realiai ten nieko nėra, žaidime gal mažiau nei 100 eilučių kodo. Tokio žaidimo eksportas užtruko daugiau nei pusvalandį. Kodėl?!
Po tokios malonios patirties su Unity, nelabai optimistiškai nusiteikęs, nusprendžiau pabandyti Godot. Godot mane maloniai nustebino. Jis turi integruotą kodo redaktorių. Žaidimo eksportavimas užtrunka trumpiau nei 5 minutes ir kiekvieną kartą paspaudus ctrl+s nereikia perkompiliuoti žaidimo. Ko dar žmogus gali norėti?
Godot teoriškai palaiko dvi kalbas C# ir GDscript. Aš esu dirbęs su C# universiteto laikais, kas yra prieš visą amžinybę, bet vieną kartą išmokęs važiuoti dviračiu, niekada nepamirši. Tuo pačiu, jeigu nori daryti karjerą žaidimų kūrime, būtų logiška praktikuotis C#, todėl aš, savaime suprantama, pasirinkau GDscript.
Žmonės sako, kad GDscript yra panaši į Python, negaliu komentuoti, nes niekada taip ir neišmokau Python.
Godot privalumai
1) Įsivaizduokite, kad pasileidote žaidimą ir pamatėte bugą. Jūs galite pataisyti kodą, išsaugoti ir jūsų naujai parašytas kodas iš karto veiks žaidime. Jums nereikia žaidimo pasileisti iš naujo. Kosmosas, ane?
2) Teoriškai Godot sukurtą žaidimą galima eksportuoti į bet kurią platformą. Aš pats išbandžiau tik Windows ir Web, ir turiu pasakyti, kad eksportai nėra lygiaverčiai. Mano žaidime į jūsų gatvę ateina pirkėjai. Piko metu jų gali būti 1000. Windows žaidimo atveju mano kompiuteris pradeda laginti kažkur virš 500, tačiau naršyklės atveju tai jau prasideda virš 200. Windows kodas kažkaip yra geresnis.
3) Aš negaliu patikėti, kaip lengva padaryti vertimus. Nėra priežasties, kodėl jūsų kuriamas žaidimas neturėtų anglų ir lietuvių kalbos. Problema su vertimais į italų kalbą, kad jūs nemokate italų kalbos.
Norint naudoti vertimus, pirmiausiai susikuri Google Sheet (Excel) failą. Pirmas stulpelis raktinė frazė, antras – angliškas vertimas, trečias – lietuviškas vertimas. Eksportuojate failą kaip CSV, drag&drop į Godot ir jums automatiškai sugeneruojami vertimų failai. Nustatymuose pažymite, kokius failus naudoti ir vertimai vyksta automatiškai.
Mygtuko tekste suvedate raktinę frazę ir jinai bus rodoma teisingai priklausomai nuo pasirinktos kalbos. Jeigu norite vertimus naudoti iš kodo, tuomet reikia naudoti TR funkciją. Taip paprasta!
4) Godot redaktorius iš karto pastebi sintaksės klaidas. Programuotojai gali pasakyti, kad žino geresnių kodo redaktorių, bet man tai geriausias su kuriuo teko dirbti.
5) Žaidimo kūrimas Godot nėra tik programavimas. Maždaug 50% yra drag&drop kur reikia susitampyti komponentus. Apie tai pakalbėsime prie trūkumų. Tai nėra gamemaker ar panašus įrankis, kur galima būtų 100% žaidimo sukurti tik drag&drop, kodą rašyti vis tiek reikia, bet pagrindinis Godot elementas yra scena. Man sunku įsivaizduoti, kad scena būtų sudaryta tik iš vieno objekto. 5 objektai turbūt yra vidurkis mažoms scenoms, bet teoriškai vieną sceną gali sudaryti šimtas ar net daugiau objektų. Kiekvienas objektas teoriškai gali turėti po savo kodo failą. Realybėje taip nebus, bet teoriškai įmanoma. Privalumas, prie kurio aš taip ilgai vedu yra paveldėjimas.
Jeigu esate susidūrę su objektiniu programavimu, tai žinote, kad paveldėjimas leidžia naudoti tėvinės klasės metodus ir kintamuosius. Kaip ir viskas labai paprasta. Išskyrus, kad Godot, tai yra daug smagiau. Jūs galite perrašyti paveldėtą metodą, kas yra gerai, bet nieko nestebina. Jūs galite praplėsti paveldėtą metodą t. y. bus įvykdytas originalus kodas ir jūsų naujai parašytas kodas. Jėga ar ne? Jūs galite sukurti paveldėtą sceną. Tarkim, originali scena turi 50 objektų ir 10 klasių. Paveldėjusi scena iš karto gauna visus objektus ir klases, bet jūs taip pat galite pridėti naujų objektų, klasių arba praplėsti esamų funkcionalumą. Kosmosas, ane?
Pavyzdžiui mano žaidime yra pagrindinis lygis, kur jūs galite atlikti visus veiksmus. Tuomet paveldėtas lygis paveldi visą funkcionalumą ir pakeistas tik vienas dalykas: lygio perėjimo sąlygos. Viename lygyje reikia pastatyti tris restoranus, kitame lygyje reikia parduoti prekių už 1,200 eurų. Visas pagrindas yra tas pats ir skiriasi tik keli metodai. Tai yra nerealiai smagu.
Godot trūkumai
1) Pradėkime nuo tokio nelabai trūkumo, bet pripratimo klausimo. GDscript yra kalba pagrįsta tabais, jeigu netyčia kur nors ne ten padėjote tarpą, eilutė iš karto raudonuoja ir kodas neveikia. Iš kitos pusės, tai verčia jūs rašyti tvarkingą kodą ar bent jau kažkiek tvarkingą.
Labai keista, kai eilutės gale nereikia rašyti kabliataškio ar if sąlygos apskliausti. Javascript gali parašyti viską vienoje eilutė ir tai veikia. Čia taip neveiks.
2) Kaip jau minėjau pradžioje aš ateinu iš javascript/Phaser pasaulio. Tame pasaulyje viskas yra kodas. Iš principo kaip tu kuri žaidimą, tai rašai ilgą funkciją, kol supranti, kad dalį kodo reikia panaudoti antrą kartą, tuomet savo didžiąją funkciją išskaidai į mažesnes ir toliau rašai ilgą funkciją. Taip kartoji kol pabaigi žaidimą. Tuomet paskutinį kartą peržiūri kodą ir jį išskaidai, kad taptų geriau skaitomas. Tai yra tobulas Agile, nemanau, kad kas nors priartėja prie šito.
Kaip jau užsiminiau anksčiau, Godot nėra tik programavimas. Kas reiškia, kad jūs negalite tiesiog sėsti ir kurti žaidimo, o eigoje išsiaiškinti ką darote. Prieš pradėdami kurti žaidimą, turite susikurti aiškią struktūrą. O kad galėtumėte susikurti aiškią struktūrą turite žinoti labai tiksliai kaip jūsų žaidimas veiks. Kiekvienos smulkmenos žinoti nebūtina, bet pagrindinius bruožus privaloma.
Niekas nesako, kad negalima tobulinti ar keisti struktūros darbo eigoje, bet labiausiai tikėtina, kad rezultatas bus spageti. Nenoriu sakyti, spageti kodas, nes tai nėra tik programavimas.
Godot kintamuosius galima apsirašyti kode ir po to juos keisti iš inspektoriaus. Tai yra problema, nes jeigu pamatote, kad kažkokia reikšmė yra 2x didesnė nei turėtų būti, jūs nežinote kur ieškoti klaidos: kode ar inspektoriuje, ir reikia patikrinti abi vietas.
3) Jeigu esate dirbę su HTML ir CSS, tai jūs esate įpratę, kad kiekvienas elementas turi paraštes (margins) ir atitraukimus (paddings). Godot atveju, vietoj to turite marginContainer. Kitaip sakant, jeigu HTML formą su gražiu dizainu norėtumėte perkelti į Godot, jums reikėtų maždaug 2x daugiau objektų/elementų, nes kiekvieną kartą, kai nustatėte paraštes ar atitraukimus, jums reikėtų naudoti marginContainer.
4) Nors teoriškai, visi objektai turi savo savybes, kurias galima redaguoti per inspektorių nerašant kodo. Man teko susidurti keletu atveju, kur neradau reikalingų savybių inspektoriuje ir paprašius pagalbos DI, gavau kodo gabalą. Kitaip sakant, yra tam tikros objektų savybės, kurias kažkodėl galima keisti tik per kodą.
5) Yra keistų bugų, kurie neturi nieko bendro su mano kodu. Pavyzdžiui, žaidime galima pastatyti autobusų stotelę ir tuomet atvažiuoja autobusas. Vienas bugas buvo toks, kad vietoj to, kad autobusas važiuotu gatve, jis važiavo šaligatviu. Mano kodas niekaip negalėjo sukelti tokio bugo, bet vienintelis sprendimas, kurį aš radau, perrašyti visą autobuso logiką nuo nulio. Galima problema: kaip skirtingi objektai sąveikauja tarpusavyje. Autobusas nėra tik judantis paveiksliukas, bet scena sudaryti iš 10 objektų ir galbūt vienas iš jų kažkaip keistai sąveikavo su autobusu stotele ar dar kokiu nors kitu žaidimo objektu.
Dalykai, kurių vis dar nežinau
Kaip jau minėjau truputi aukščiau, dirbant su Godot labai svarbu pasirinkti teisingą struktūrą. Tai liečia tiek scenos struktūrą, tiek failų struktūrą. Savaime suprantama, jūs norite paveiksliukų failus laikyti paveiksliukų kataloge, kodo – kodo, duomenų – duomenų. Bet tai nėra gera failų struktūrą. Mano žaidime yra 60 paveiksliukų, ar jūs manote, kad yra gera idėja laikyti viską viename kataloge?
Dar įdomiau yra su kodu. Nes kodą sudaro scenos failai (tscn) ir skripto failai (gd). Ar jie turėtų būti viename kataloge ar skirtinguose. Mano žaidime yra 56 scenos. Laikyti visą viename kataloge bloga idėja. Mano žaidime yra 105 skripto failai, kas reiškia, kad kiekviena scena vidutiniškai turi po du failus.
Kuriant web žaidimus labai svarbu, kad būtų kuo mažiau užklausų į serverį, taigi, sprite yra geriausias būdas. Ir nors Godot teoriškai galima naudoti sprite (aš naudoju), bet nemanau, kad tai yra teisingas būdas. Paprasti paveiksliukai Godot atveju atrodo kaip teisingesnis sprendimas sukeliantis mažiau galvos skausmo. Jeigu aš būčiau naudojęs paveiksliukus, o ne sprite, tai vietoj 60, aš jų turėčiau virš 300. Vėl gi kyla klausimas: kokia turėtų būti teisinga struktūra?
Kiek laiko užtruko sukurti žaidimą?
Žaidimas nėra didelis. Iš viso tik 40 lygių. Vis dėl to sakyčiau, kad žaidimą sukurti užtruko be proto ilgai.
Atsakymas: kiek laiko užtruko sukurti žaidimą - nėra labai paprastas.
Pirmiausiai aš sukūriau Phaser žaidimo versiją. Ir ta versija sukurti man užtruko 4 mėnesius. Vienas mėnesis buvo sunaudotas iliustracijoms. Taip pat savaitę ar dvi sugaišau balansavimui ir idėjai: kokios parduotuvės turėtų būti, kiek jos turėtų kainuoti.
Aš negalėjau panaudoti kodo, bet idėja, skaičiai ir visi paveiksliukai buvo panaudoti galutinėje versijoje. Galutinėje versijoje yra šiek tiek pakeitimų, šiek tiek naujų paveiksliukų, bet pagrindinis darbas buvo atliktas kuriant Phaser versiją.
Toliau aš sukūriau demo versiją. Tai man užtruko apie 2,5 mėnesio.
Galiausiai aš demo versiją praplėčiau iki galutinio rezultato. Tai man užtruko 2 mėnesius.
Taigi, galutinis rezultatas sakyčiau yra 6 mėnesiai. Aišku, reiktų suprasti, kad aš nedirbau po 8 valandas per dieną, kiekvieną dieną. Gera diena yra, kai žaidimui skirdavau po 4 valandas. Taip pat buvo dienų, ypač kai jau matai, kad jau beveik užbaigei ir nori greičiau užbaigti, kai sėdi po 12 valandų, dvi dienas iš eilės. Bet tokių dienų buvo nedaug.
Kuriant šį žaidimą man teko susidurti su daugybę naujų dalykų, aš daug išmokau. Aš manau, kad jeigu kurčiau tokį patį žaidimą dabar, tai galėčiau jį padaryti greičiau. Ne daug, greičiau, tik kokiu mėnesiu.
Apskritai, kurti žaidimą vienam yra keistas procesas. Pradžioje visą laiką skiri kodo rašymui, bet proceso eigoje tai keičiasi. Projekto gale 90% skiri žaisti savo žaidimui ir kodo rašymo būna labai ne daug.
Kas toliau?
Baigiau savo eksperimentą, tai laikas grįžti prie Phaser? Ne, tiesa pasakius, Godot man labai patinka. Galėjote tą atspėti iš pavadinimo. Aš širdyje esu web žaidimų žaidėjas ir kūrėjas, bet, manau, kad nuo šiol juos kursiu su Godot. Taip, aš manau, kad Godot kurti žaidimus yra sudėtingiau ir užtrunka ilgiau, bet taip pat žymiai smagiau.
Jeigu perskaitėte iki galo, mano žaidimą galite rasti čia. Ir būtinai apie jį papasakokite savo draugams.
PS. Aš taip pat žaidimui sukūriau CV, nes kodėl gi ne? Pažiūrėkite, tikrai smagu.