Valtavan suositun tekoälyavusteisen ohjelmointityökalun Claude Coden koko lähdekoodi on vuotanut vahingossa verkkoon
https://dawn.fi/uutiset/2026/03/31/claude-code-lahdekoodi-on-vuotanut-verkkoon
#claudecode #anthropic #tekoäly #ohjelmointi #uutiset #teknologia #tekniikka
GitHub ryhtyy kouluttamaan tekoälyään käyttäjiensä koodilla - käytännöstä pitää erikseen kieltäytyä
Muutos koskee GitHub Copilotin käyttäjiä: jatkossa kaikki Copilotia käyttävät käyttäjät välittävät oletusarvoisesti ohjelmakoodia ja tietoja, joilla Copilotia jatkokoulutetaan.
Tähän on joitain poikkeuksia, kuten yritysten yksityiset repot. Mutta muiden pitää halutessaan kieltäytyä tietojen käytöstä 24.4.2026 mennessä.
#github #githubcopilot #tekoäly #yksityisyys #ohjelmointi #uutiset #teknologia #tekniikka
Jatkoin peliohjelmointiharjoituksia ja olen tutustunut oppaissa ja videoissa usein mainittuun finite-state machine (FSM) ideaan. Useimmissa toteutuksissa ajatuksena on se, että jokainen tila kirjoitetaan erilliseen tiedostoon. Sen päälle on sitten jonkinlainen tilojen kantatoteutus sekä varsinainen state machine, joka hanskaa tilasta toiseen siirtymisen.
Kaunis ajatus on se, että kun koodin pilkkoo tällaisiin pieniin palasiin, se tekee tilojen hallinnasta helpompaa ja jokaisen tilan tarvitsema koodi on selkeästi kapseloituna.
Muutin edellisen harjoituksen koodin noudattamaan FSM:ää ja täytyy kyllä todeta, että minusta ei tullut fani. Ymmärrän hyvin, että tällainen toteutus on paikallaan kun puhutaan valtavista peleistä, jossa erilaisia tiloja on kymmeniä ja pelissä on hahmoja, joilla voi olla erilainen yhdistelmä tiloja. Tälle on epäilemättä paikkansa.
Ainakin tämän yhden kokemuksen perusteella asioiden pilkkominen näin pieniin palasiin toi vaan tarpeetonta kompleksisuutta ja abstrahointia. Koodirivien määrä räjähti käsiin enkä kyllä voi käsi sydämellä sanoa, että toteutus on jotenkin helpompi ymmärtää tai ylläpitää. Kun yhtälöön lisää sen, että nämä tilat ovat joka tapauksessa varsin tiukasti sidottuja hahmoon, joka niitä käyttää, niin saatu hyöty tuntui aika olemattomalta.
Voi toki olla, että toteutin FSM:n ihan päin persettä, mutta tykkäsin itse paljon enemmän toteutuksesta, jossa tilakone oli rakennettu ihan vaan enumeilla ja selkeästi jäsennellyllä koodilla.
Kirjoittelin työchattiin pienen "esseen" nähtyäni videon, jonka näin eilen.
Videossa ohjelmoija kertoo siitä, kuinka AI on pilannut hänen aivonsa, eikä hän yksinkertaisesti kykene enää ajattelemaan omilla aivoillaan. Hänestä on tullut omien sanojensa mukaan ihan hyödytön. Hänelle AI on kuin huume, jota ilman hän ei kykene enää toimimaan.
Päätin julkaista oman kirjoitukseni suomeksi käännettynä myös blogissa. Nykyinen "AI-psykoosi" edustaa minulle ilon ja innostuksen poisoptimointia.
Minun Godot-harjoittelut jatkuvat. Nyt vuorossa oli Super Mario -klooni.
Keskityin tässä tekemään jotakuinkin ehjän kokonaisen maailman, rakentamaan liikkuvat viholliset, joilla on eri tiloja. Tässä sai myös hyvin harjoiteltua interaktioita eri objektien välillä, tilojen hallintaa ja paljon muuta.
Olisihan tuohon voinut laitella lisää animaatioita, ominaisuuksia, ääniä, musiikkia ja muita yksityiskohtia, mutta oppimistavoite tuli tällä raakileellakin saavutettua.
Hauskaa puuhaa! ☺️
Viimeisimmän peliohjelmointiharjoituksen tulos: buginen Pac-Man 
Tämän harjoituksena tarkoituksena oli rakennella jonkinlainen tekoäly vihollisille. Siinä sivussa opin käyttämään tilemapeja. Kuten aikaisemmasta töötistä voi päätellä, tämä antoi hyvää harjoitusta tilojen hallintaan.
Paljon olisi vielä kaikenlaista säädettävää, mutta oppimistavoite toteutui, joten jätän tämän tähän. Videossa näkyy hienosti kuinka keltainen kummitus saa minut kiinni hyödyntämällä bugia 😄
Tämän harjoituksen myötä tuli tutustuttua myös Pac-Man -pelin sisuksiin. Yllättävän monimutkainen pelilogiikka senkin taustalta löytyy! Kiinnostuneet voivat lukea siitä täältä: https://www.gamedeveloper.com/design/the-pac-man-dossier
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 ☺️
Unohdin oman erehdyksen takia käydä tenttimässä Tekoälyn menetelmät -kurssin ja käyn sitä nyt uudestaan. Huomasin heti alkumetreillä, että Tietorakenteet ja algoritmit -kurssin käyminen auttaa huomattavan paljon. Tämän lisäksi tekoälyn kertaaminen helpottaa TRAKin jatkokurssin ohjelmointitehtävää, jossa täytyy toteuttaa jotakin peliä pelaava tekoäly. Meinasin toteuttaa pirkkaversion Umamusumen kaltaisesta pelistä. :D
Minun Godot-seikkailut jatkuvat Asteroids-kloonin parissa. Tässä pääsi harjoittelemaan lisää fysiikkajuttuja, asioiden spawnaamista viewportille, äänitehosteita, animaatioita, musiikkia, pelin eri tilojen hallintaa, valikoita, tyylejä sekä tiedostoon tallentamista ja sieltä lukemista. Kaikki grafiikat, äänet ja musiikit ladattu netin ilmaisista kolosista.
Yllättävän nopeasti nämä peliprojektit muuttuvat varsin monimutkaiseksi spagetiksi, varsinkin kun kokemus tämän puolen ohjelmoinnista on lähes pyöreä nolla.
Ei tämä opettelu kovin mukavaa ja tehokasta kipeänä ole, mutta pälli hajoaa jos makoilen koko päivän sohvalla 🤧
Tarvitsisin Godot-osaajien apua.
Melkein kaikki oppaat käyvät HUD:n rakentamista läpi niin, että HUD piirretään pelialueen päälle. Toisin sanoen pelielementit saattavat jäädä HUD:n taakse.
Miten asia pitäisi hoitaa, jos pelialueen haluaisi olevan HUD:in alapuolella? HUD ei siis tulisi pelialueen päälle eikä koskaan blokkaisi pelielementtejä.
Minkälaista root-nodea tällaisessa pitäisi käyttää ja mistä elementeistä nodepuu pitäisi rakentaa, että tämä on mahdollista?
AfterDawn
Saaste
Emma "Girubert" 🐢