Mastodawn

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 ☺️

Aleksandr Koltsoff Mar 19

@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.

Aleksandr Koltsoff Mar 19

@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".

Mika Happonen Mar 19

@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...

Mika Happonen Mar 19

@saaste Ite opin ohjelmoimaan pelikoodaamisen kautta niin itselle "ei pelien" ymmärtämiseen meni aikaa :D

Esim. peleissä "front- ja backend" on aika yhdessä integroituneita ja softapuolella ne on taas selkeästi erillään ja monesti jopa tehty eri kielillä.

jarizleifr Mar 19

@mika @saaste Toki riippuu ihan siitä miten tota haluaa lähestyä. Oma peli mitä oon duunaillut on C:llä toteutettu moottori ja simulaatiokerros, joka ekspoussaa Lua-API:n "fronttia" varten, et voin kirjoittaa kaiken käyttöliittymäkoodin Fennelillä ja kaiken pelilogiikan C:llä.

Varmaan vois enemmänkin ulkoistaa skriptaukselle halutessaan, mut toi käli oli just semmonen asia minkä halusin pitää täysin erillään ite pelistä.

Pystyn jopa ajamaan testejä pelisimulaatiota vasten ku se on erillään.

jarizleifr Mar 19

@saaste Mun suosikki edelleen peliarkkitehtuurissa on vaan hyväksyä tosiasiat ja kohdella koko peliä yhtenä isona möykkynä tilaa ja kirjoittaa kaikki logiikka semmosina transformereina jotka tekee jotain rajattuja muutoksia siihen tilaan.

Kaiken mitä on oppinut enkapsuloinnista ja olio-ohjelmoinnista voi heittää välittömästi romukoppaan, koska semmoset tilanteet missä objekti A:n pitää päästä kiinni objekti B:n sisuksiin ja päinvastoin, on hyvin tyypillisiä peleissä.

jarizleifr Mar 19

@saaste Ensimmäinen virhe minkä jokainen tekee, on yrittää mallintaa pelin entiteettejä objekteina, koska se tuntuu intuitiiviselta ratkaisulta, et mulla on tässä Map, Player, Monster ja Item ja ne on kaikki enkapsuloitu omiksi jutuikseen.

Ja lopulta ne on kaikki jumalobjekteja jotka ekspoussaa _kaiken_ koska peleissä kaikki tila koskettaa kaikkea.

Mun rogueliken koko simulaatio toimii tähän tyyliin:

ai.run(ctx)
actions.run(ctx)
time.run(ctx)
death.run(ctx)
initiative.run(ctx)
spawn.run(ctx)

jarizleifr Mar 19

@saaste Et sen sijaan et yrittäis mallintaa objekteja, mallintaa "konsepteja", joista jokainen on oma prosessinsa ja tekee jonku yhen selkeän asian sille statelle.

Entiteetit on vaan dataa. Ne ei tee mitään yksinään.

@jarizleifr Ihan jo tällä pienellä harjoittelullakin on tullut huomattua, että tuollainen liiallinen objekteihin keskittyminen ei toimi. Eikä myöskään liian pitkälle viety kapselointi. Juuri tuo "kaikki vaikuttaa kaikkeen" aiheuttaa sen, että asoita on pakko avata muualle maailmalle tai tuloksena on ihan hirveetä spagettia.

Tosin spagetti on vaihtoehto aina, tekipä koodia miten vaan 😅

@saaste @jarizleifr Mä oon kans tykästynyt tuollaiseen ecs-tyyliseen ajatteluun. Pelejä en oo ikinä tehny, mut tuollaista sekamelskan hallintaa on kiva tehdä myös tylsiä webbijuttuja koodaillessa :)

jarizleifr Mar 19

@bestest @saaste Mixinit on kans tosi kiva tapa hallita tota kaaosta, et voi vaan lisätä ja poistaa kokonaisia toiminnallisuuksia objekteista runtimena, jos vaan sattuu semmosessa ympäristössä työskentelemään mikä niitä natiivisti tukee.

Tosin jos on jo ECS:ää tottunu käyttämään ni nää tämmöset tuntuu vähän leluratkaisuilta.

Itekin pari ECS-toteutusta skrätsistä huvikseni tehneenä, vaikee nähdä et käyttäis mitään muuta jos tietää jo etukäteen, et kompleksisuutta on tiedossa.

@jarizleifr @saaste Oon miettinyt, että pitäs ihan testata miten datan hilloaminen kantaan tuollein ecs-mäisesti toimii verrattuna normiperusjuttuihin. Käyttötarkoitus olisi luokkaa normi-webbijuttu. Taulut olis sit komponentteja.

Isolla datamäärällä ja kaikenlaisilla käyttötarkoituksilla.

Jotkut asiat vaatii mielipuolisia joineja, mut sehän on se sql:n suola.

Onko tallentaminen nopeampaa? Entä haku? Laajentaminen? Alterit?

@saaste @jarizleifr Mielenkiintoista pohdintaa. Askartelin vähän Pacman-tyyppisen pelin kanssa Pythonilla n. 10v sitten ja ällistelin näitä samoja juttuja että eihän nää oliohommat toimi yhtään.

Aiemmat pelikehityshommat oli 80-luvulta C64:n Basicilla, sillä nyt tietysti ei ollut mahdollistakaan tehdä muuta kuin spagettia. Mutta huvittavaa on miten helposti siihen päätyy näillä hianommillakin ohjelmointikielillä.