Tässä kun on sairausloman ohessa tullut leikittyä peliohjelmoinnin kanssa niin minulla on fiilis, että yksi sen pirullisimpia haasteita on tilojen hallinta. Toki niitä on muitakin, mutta tuo on sellainen, joka nyrjäyttää omat aivoni tosi helposti.

Tavallisten sovellusten toiminta on usein verrattain lineaarista. Asia A käynnistää prosessin, jossa toteutuu asiat B, C, D, E ja F. Ne voivat suoriutua yhtä aikaa, mutta ison osan ajasta asioilla on alku ja selkeä loppu.

Peliohjelmointi ei ole lainkaan tällaista. Siinä sinulla on miljoona asiaa, jotka kaikki elävät omaa elämäänsä. Monilla asioilla ei ole alkua ja loppua. Ne ovat kaiken aikaa olemassa ja vaihtelevat tekemisiään ja toimintalogiikoitaan milloin mistäkin syystä. Eivätkä ne toimi eristyksissä, vaan asiat voivat reagoida toistensa tekemisiin, maailmassa tapahtuviin asioihin ja niin edelleen.

Tämä eri tiloissa olevien asioiden hallinta ja vastuun jakaminen saa ainakin minun pään ihan pyörälle. Teen yhden ratkaisun, ja kun peliin tulee uusi ominaisuus, tajuan, ettei vanha ratkaisu toimikaan ja joudun kirjoittamaan sen uusiksi. Tekeminen on jatkuvaa koodin refaktorointia ja uudelleen suunnittelua.

Toki minun kokemusta värittää kokemattomuus. Vaikka olen vääntänyt koodia vuosia, en ole peliohjelmoija. Pelien ongelmat ovat minulle ihan uusia ☺️

#ohjelmointi

@saaste Mä kokeilin vuosia sit yrittää opiskella unityllä jotain ja isoin haaste itselle oli se ettei kukaan oikein missään selittäny et mitä se unity oikeasti tekee ja mihin se moottorin sisäinen malli perustuu. Et tavallaan se koulutusmateriaali lähestyi kaikkea sen editorin ja propsien kautta ja sit "asiat vaan toimi itsekseen!". Oli ihan superhämmentävää itselle moinen lähestyminen tässä vaiheessa elämää (en sano etteikö se toimis normi-ihmisille).

@nihkeys @saaste Tää on mulla vähän saanut jättämään Godotin opettelun. Materiaali on semmoista "teet tälleen niin sitten ruudulle tulee juttuja", ja mä haluisin kuvauksen miten se koko moottori toimii.

Ja videoista en voi opetella ohjelmointia.

@pare @nihkeys Itseäni noi asiat ei jotenkin yhtään kiinnosta. Voin opetella uuden frameworkin ilman, että minun on ymmärrettävä miten se framework on rakennettu. Minulle riittää, että se toimii. Tai voin opetella uuden ohjelmointikielen ymmärtämättä, että miten sen kääntäjä toimii.

Suhtaudun Goditiin samalla tavalla. Se on minulle läjä työkaluja. Kunhan dokumentaatio ja oppaat kertovat, mitä ne työkalut toimivat, minulle on yhdentekevää miten ne on toteutettu.

Toki sen himmelin syvempi ymmärrys on tarpeen ja hyödyksi sitten, jos alkaa tehdä vaativampia pelejä, mutta nyt kun tavoitteena on opetella "pelien tekemistä" eikä "Godotia" niin tyydyn potkimaan renkaita enkä kurkistele konepellin alle 😄

@saaste @nihkeys Näinkin! Mutta mun aivot haluaa tietää, että mitä yhteyksiä on olemassa ja miten ne toimii! Taikalaatikot on vähän hankalia, ja mun kokemuksella menee helposti rikki, niin sitten kuitenkin helpottaa, jos ymmärtää, miten ne toimii.

Jossain kohtaa ylläpidin yhtä Java-GraphQL-systeemiä, jossa oli hienoa taikuutta. Kunnes se ei toiminutkaan ja selvittely oli hankalaa.

@pare @saaste Luulen et mulle ehkä isoin kynnys oli se että kaikki ne abstraktiot mitä olen vuosikymmenten aikana oppinu, ei mikään oikein osunu sille tontille missä Unity halusi elää. Ja aivot jatkuvasti halusi ymmärtää asioiden suhteita käyttäen jo opittuja abstraktioita sen sijaan että olisi vaan lähteny tyhjästä "asiat vain on näin"-tavalla.

Godotia en ole kokeillut. Sen kanssa ehkä voisikin käyttää enemmän aikaa kun pääsis katsomaan lähdekoodia suoraan ja sais "tuon hoidettua pois".

@nihkeys @pare @saaste Jos haluaa täyden hallinnan/tykkää enemmän systeemeistä niin Monogame on melkein parempi valinta. Siinä pääsee tekemään ite enemmän juttuja ja ei ole niin "bloated" kuin Godot.

Ite tein sillä pelin ja oli ihan kiva työkalu, mutta näin jälkikäteen tykkään ennemmän, että pelimoottori tarjoaa juttuja valmiiksi ja kaikkea ei tarvitse tehdä ite/ymmärtää.

@nihkeys @saaste Yks ratkaisiu olisi toki selvittää ja kirjoittaa fiksu opas...