SaasteMar 19

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

Show threadjarizleifrMar 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ä.

Show threadjarizleifrMar 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)

Show threadjarizleifrMar 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.

Show threadSaasteMar 19

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

Show threadTurre

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

Mar 19 at 2:55pmWeb