Sikoban 2.0, Legoukkelin paluu

Viimeisen Java-tehtävän aihepiirinä oli tulosten tallentaminen ja näiden näyttäminen JTable-komponentin avulla. JTable on perinteinen taulukkokomponentti – kaikki, jotka ovat vähänkään tutustuneet jonkun taulukkolaskentaohjelman, kuten Exelin, käyttöön tunsivat varmasti olonsa kotoisaksi kuudennen Javan parissa.

”JTable on Swingin monimutkaisin komponentti” [1]. Jos näin todella on, niin se ei ainakaan aiheuttanut minulle juurikaan ylimääräistä päänvaivaa. Päinvastoin, aikaisempi paneelien ja framejen kanssa temppuilu kulutti aikaa ja hermoja huomattavasti JTaulukoita enemmän. Sikobaniin teimme oman Tulostaulukko-komponentin, joka on AbstractTableModel:n aliluokka.

Sinänsä oli hauskaa kehittää edellisellä tehtäväkierroksella luotua peliä, mutta kaiken kaikkiaan kuudes Java-tehtävä oli aika lailla puuduttavaa vääntämistä. Taulukointia ja tallentamista? Blaah. Jäin kaipaamaan tehtävältä jotakin mielenkiintoista kiintopistettä. Jotain mistä olisi hyötyä projektissa (no niin, toki tästäkin oli) ja jotain mikä saisi projektin lähestyessä peruskoodauksen maistumaan vähemmän puulta. Tällainen kiintopiste olisi voinut olla vaikkapa jonkin grafiisen aspektin lisääminen Sikobaniin: pidettiinhän 2D-grafiikasta varta vasten luentokin. Tällaisenaan kuudennen tehtävän sisältö jäi kovin heppoiseksi. Ehkä nämä asiat (JTable, tallennus) olisi voitu jo mahduttaa edelliseen Javaan? Lisäksi jäin hieman ihmettelemään äänien puuttumista ns. pakollisista tehtävistä. Tietokonepeli – vaikkakin kevytrakenteinen sellainen – ilman ääniä on kuin joulukuusi ilman koristeita, eli eipä paljon mitään.

Kukaan ei tietysti ole heristämässä sormea ja kieltämässä omatoimista tutustumista grafiikan kiehtovaan maailmaan. Niinpä päätin lisätä parilla asteella Sikoban-pelini visuaalisuutta ja kehittää siihen muutaman sellaisen graafisen härpäkkeen – Sikoban-animaation.

Animaatio (lat. animatio ‘elävöittäminen’) on tekniikka, jossa elokuva toteutetaan kuva kuvalta [3]. Perinteinen tapa luoda animaatioita on näyttää nopeasti erilaisia kuvia peräkkäin, jolloin saadaan eräänlainen illuusio liikkuvista objekteista. Javalla frame-animaatio on melko yksinkertaista toteuttaa. On myös muita tapoja, kuten java.awt.graphics:n piirto-ominaisuuksien käyttö tai ns. sprite-animaatio.

 

Tein animaatiototeutuksen omaan luokkaansa. Sikobananimaatio.java sisälsi itse asiassa myöskin toisen luokan eli sisäluokan (inner class). Halusin animaatiot näkymään tarvittaessa samaan peli-ikkunaan pelipaneelin tilalle, joten oli luonnollista tehdä Sikobananimaatiosta JPanel:n aliluokka. Animaatio saadaan siten näppärästi esiin poistamalla framesta pelipaneeli ja asettamalla tilalle animaatiopaneeli.

Mikäli kuvatiedostot ovat suuria tai kuvia näytetään verkkoyhteyden yli, saattaa ongelmaksi muodostua kuvien hidas tulostuminen näytölle [2]. Kun kuvien vaihtoväli laskee muutamaan kuvaan sekuntia kohden, ei oikein voida hyvällä tahdollakaan puhua enää animaatioista. En saanut ensin yritelmiäni näkymään lainkaan, joten luulin, että kuvani olivat tiedostokooltaan liian suuria animaation näyttämistä varten. Niinpä tutustuin API:n MediaTracker-luokkaan. Se pakottaa ohjelman odottamaan yhden tai vaihtoehtoisesti kaikkien kuvien latautumista muistiin ennen animaation aloittamista [2].

Turhautuminen kipusi kliimaksiinsa, kun liikkuva kuva loisti poissaolollaan MediaTracker-olion käytöstä huolimatta. Ongelma löytyikin aivan toisesta suunnasta: kuvat kylläkin piirtyivät juuri niin kuin pitääkin – myöskin ilman MediaTrackeria – mutta framen ulkopuolelle, näkymättömiin. Lopulta löysin virheen vaihtelemalla paneelin kokoa. Ongelman ratkaisemiseen tuhlaantui muutama ylimääräinen tunti ja hajoilemisen puuska, mutta ensimmäistä omaa animaatiotani katsellessani totesin vaivan olleen sen arvoinen.

Laitoin Sikobananimaatio-luokan konstruktorin ottamaan parametrina String-olion. Ideana oli mahdollistaa useiden erilaisten animaatioiden toteutus samaa luokkaa käyttäen. Konstruktorin parametrin perusteella otetaan oikeat kuvat käyttöön kyseistä animaatiota varten. Asetin aiemmin jo mainitun sisäluokan huolehtimaan kuvan näyttämisestä ja perimään luokan Thread, jolloin kuvien vaihtovälin saattoi toteuttaa laittamalla säikeen nukkumaan sopivaksi ajaksi. Totesin, että 60 millisekuntia on sopiva viiveaika.

Sikobanissani on myös ääniefektit featuring Homer Simpson, Austin Powers, Sgt. Hartman (FMJ) ja Samuel L. Jackson. Koitan perehtyä WAV-ääniin projektin aikana hieman tarkemmin – nyt sain äänet toimimaan netistä löytämieni esimerkkien avulla ja palauttamani ratkaisu ei ollut toimivuudestaan huolimatta tyylikkäin mahdollinen ratkaisu.

 

Hyvää joulua!

- Teemu

[1] Vesterholm, Mika. Kyppö, Jorma. Java-ohjelmointi, Talentum, 2006, 6.painos.
[2] Java Coffee Break: Using MediaTracker to help load images
[3] Wikipedia: Animaatio

Linkkeihin viitattu 23.12.2007

Muovipaloja hiekkalaatikossa: Sikoban vers. 1.1

Viidennessä Java-tehtävässä pääsimme harjoittelemaan oman GUI:n rakentamista pienen Sikoban-pelin merkeissä. Pelin perusidea on kevennetty versio perinteikkäästä Sokoban-pelistä. Yhden vokaalin muutos nimessä Sikobaniksi johtui pelin oletusulkoasun sika-teemasta, johon kuitenkin monet – mukaan lukien allekirjoittanut – tekivät omia muutoksia. Oli hienoa nähdä viimeinkin jotain konkreettista, eikä vain sieniä ja ninjoja, jotka vilisevät jossain komentorivin, Eclipsen (tai XEmacsin) ja prosessorin välimaastossa. Toki aikaisemminkin olimme päässeet testaamaan aikaansaannoksiamme graafisilla testiohjelmilla, mutta tällä kertaa pääsimme kuitenkin näkemään oman tuotoksen näyttöruudulla, ja se jos mikä tuntui palkitsevalta.

 

Tehtävä oli mielenkiintoinen kokonaisuus loppuprojektia silmällä pitäen, sillä Sikoban sisälsi juuri niitä elementtejä, joita varmasti minä ja monet muut tarvitsevat tuossa kurssin eeppisessä päätösnäytelmässä – ohjelmointiprojektissa. MouseListener, graafinen käyttöliittymä, musiikit ja Comparable-rajapinta (Java 6) tulevat olemaan tärkeä osa omaa projektiani.

Sikoban-peli koki uudelleensyntymisen pienten kirurgisten toimenpiteiden jälkeen – entiset sika-ikonit löysivät paikkansa pelimaailmasta lego-figuureina, ja vastaavasti seinät lihallistuivat lego-palikoiksi. Tämä teema sopii mielestäni tällaiseen palikkapeliin. Pelin räikeähkö värimaailma tukee tätä lapsellista asetelmaa.

Innostuin erityisesti musiikkien saamisesta peliin ja niinpä ryhdyin tuumasta toimeen vielä varsinaisen tehtävän ollessa kesken. Äänimaailman lisääminen osoittautui kuitenkin suhteellisen helpohkoksi tehtäväksi Head First Java-kirjan ja Googlen löytämien artikkeleiden avulla. Pelin karkkimaiseen tunnelmaan sopi hyvin MIDI-tyyppiset äänet. Toteutus tapahtui MidiSystem-luokan avulla. MidiSystem toteuttaa rajapinnan Sequencer, joka taas on MidiDevice-rajapinnan ns. alirajapinta (subinterface). Oli kyllä aika lailla koominen fiilis, kun pian Haddawayn purkkapoppi tahditti legoukkelin matkaa kohti tuntematonta. Se istui peliin kuin koodaus jouluaattoon (eh, hyvinkö?).

 

MIDI-kirjainlyhennelmä tulee sanoista Musical Instrument Digital Interface eli vapaasti suomennettuna “Musiikkilaitteiden digitaalinen rajapinta” [1]. MIDI on sikäli varteenotettava musiikkiformaatti, että MIDI-tiedostot ovat kooltaan vain pikkuriikkiisen osan vastaavista digitoiduista äänitiedostoista. Toisaalta heikkoutena on, että vaikka MIDI:llä voidaan toistaa mitä hilpeimpiä synteettisiä ääniä, formaatti ei kykene lainkaan toistamaan laulua tai ihmisen ääntä ylipäätäänsä [2]. Äänen laatu riippuu myös käytössä olevasta laitteistosta – MIDI-ääni voikin kuulostaa erilaiselta eri tietokoneilla.

”MIDI-datan tallentamiseen ja muokkaamiseen tarkoitettuja laitteita kutsutaan sekvenssereiksi.” [1]. Kun Javalla halutaan toistaa MIDI-tiedostoja, instantioidaan valmiista luokkakirjastosta sekvensseri-olio seuraavasti:

Sequencer sekvensseri = MidiSystem.getSequencer();

Tämän jälkeen osoitetaan sekvensserille jokin valmis MIDI-tiedosto.

sekvensseri.setSequence(MidiSystem.getSequence(midimusa));

Tässä midimusa on viitemuuttuja, joka sisältää viitteen johonkin Midi-tiedostoon. Sellainen voisi olla vaikkapa new File (”biisi.mid”).

sekvensseri.open();

sekvensseri.start();

Tämän jälkeen pitäisi jo hilpeän musiikin kantautua ulos kaiuttimista, kunhan on muistettu varautua catchaamaan tarvittaessa ne useat sekvensserin poikkeukset, jotka saattaavat tulla vastaan. Musiikin pysäyttäminen taas tapahtuu Sequencer-rajapinnan stop-metodilla. Kun midin toistoa ei enää tarvita, suljetaan sekvensseri kutsumalla close-metodia, joka on määritelty MidiDevice-rajapinnassa. Tämä on tärkeää, sillä on syytä vapauttaa järjestelmän nyt jo tarpeettomalle sekvensserille varaamat resurssit [3]. Lisäsin peliin myös mahdollisuuden vaihtaa taustamusiikkia valikosta käsin. Laitoin kolmisoluiseen taulukkoon viitemuuttujat äänitiedostojen nimiin, jolloin aina musiikkia vaihdettaessa haetaan taulukon seuraava alkio File:n parametriksi, joka taas edelleen syötetään MidiSystemin getSequence-metodin parametriksi.

Sikobania tehdessä tuli koko ajan mieleen toinen toistaan vauhdikkaampia (ja vähemmän toteutuskelpoisia) ideoita, jotka jäivät tuossa vaiheessa valitettavasti aikalailla kehitysasteelle kovasta yrityksestä huolimatta. Toisaalta sain osan näistä sekundasuunnitelmista toteutettua seuraavassa Java-tehtävässä – ja toivottavasti sitten projektin lomassa viimeistäänkin loput, sikäli kun ne omaan projektiini sopivat.

- Teemu

[1] Äänipää, MIDI
[2] Mindprod.com, Java Glossary
[3] Java API SE 5.0
Linkkeihin on viitattu 20.12.2007

Joulu tulee, koulu loppuu, mutta java ei :)

Lauantaina oli viimeisen java-kotitehtävän palautus-deadline. Olin ensimmäistä kertaa ylpeä aikaansaannoksestani, vaikka sikobaniini jäikin ainakin yksi bugi Huomasin taas kerran, että ongelmiin voi keksiä itsekin ratkaisun. Jos sattuu löytämään ongelman. Tässä vaiheessa olen ymmärtänyt, kuinka tärkeää koodaamisessa on taito löytää virheitä. Vaikka ei heti tietäisikään, miten ongelman saa poistettua, asiaa auttaa huomattavasti se, että tietää, missä kohdassa logiikka kusee. Ratkaisu saattaa kuitenkin löytyä yllättävän nopeasti.

Koin viimeisen tehtävän varsin hyödylliseksi omaa projektiani ajatellen. Ainakin tulosten tallentamisen harjoittelusta tulee varmasti olemaan hyötyä projektia koodatessa. Toteutin 6-tehtävässä tulostaulukon niin, että se avautui uuteen ikkunaan, ja jäin miettimään, miten sen voisi omassa pelissä toteuttaa *jännemmin*. Mielestäni Tulostaulukko-luokan käyttäminen JTablen “data modelina” tuntui aika yksinkertaiselta ja mukavalta, joten todennäköisesti oman projektini tuloslistan toteutus tulee olemaan melko samanlainen.

Seuraavaksi pitäisi aloittaa se kauan odotettu ja pelätty ohjelmointiprojekti. Suunnitelmassani pääsin jo aika pitkälle luokkien ja metodien pohdinnassa, mutta varsinkin nyt, yhtä javatehtävää rikkaampana, tuntuu että suunnitelma saattaa vielä paisua ja muutenkin muuttua hiukan Aloittaminen ei kuitenkaan tunnu ylivoimaiselta; kunhan C1:n viimeinen välikoe on ohitse, aloitan koodaamisen. Todennäköisesti tämänhetkinen luottavainen olo haihtuu ennemmin tai myöhemmin. Kuitenkin odotan jo projektin haasteiden kimppuun pääsemistä

Edelleen tsemppiä ja jaksamista kaikille (jee me saatiin korotettua bottidokumentaatioarvosanaa! jaksetaan kirjoitella vielä blogiinkin, esim puuttuvista OLO-tapauksista

- Asta

Projektin suunnittelusta

Eilen oli sitten projektisuunnitelmanpalautus. Ihan hyvä että se tuli jo nyt, vaikka aluks tuntu et nytkö sitä jo pitää alkaa ajatella. Mut siinä tajus aikataulua miettiessä, että eihän sitä aikaa kyllä kauheesti ole enää.. Ja et miten paljo siinä on omaa suunnittelua, kun ei olekaan enää valmiita ohjeita, mitä luokkia ja metodeita pitää tehdä..

Sain vähän aikaa miettiä esimerkiks luokkarakennetta, että siitä tulis edes jotenki järkevä. Varsinkin viimeisimmästä ohjelmointiharjotuksesta sain vinkkejä siihen , millasille toiminnoille kannattaa perustaa oma luokka ja miten ne on toisiinsa yhteydessä. Mutta hyvin suunniteltu on jo puoliksi tehty, siispä kannattaa uhrata suunnitteluun aikaa.  Vielä vähän aikaa sitten kyllä ajattelin, että siinähän se koodatessa suunnitelmakin etenee, mutta olis saattanu tulla aika sekavaa jälkeä siinä. Myös tulevia haasteita tuli mieleen aika ahdistavan paljon.. Projektissa tulee tarvitsemaan monia semmosia asioita, joihin en oo aiemmin törmänny ja joiden toteutuksesta ei oo mitään hajua.

Sitten kun seuraava, siis viimeinen!, ohjelmointiharjotuksen deadline  on ohi, olis tarkotus alkaa heti pian puuhaamaan projektia. Tavallaan sitä odottaa, mutta enemmän se kammoksuttaa. Mutta nyt kun sen ajoissa aloitan ja sitten säännöllisesti yritän sitä tehdä, niin toivon ettei mulle taas tule viimehetkien paniikkia, niinku yleensä.

Anu

Kässee X: And then there were none…

Jo jokunen tovi sitten palautettiin kurssin viimeiset teoriatehtävät: käsitekartat ja esseet (kässeet). Lienee siis aika pohtia mitä näistä hilpeistä perjantai-illan viihdyttäjistä jäi todella käteen. Risut ja ruusut, ohdakkeet ja tulppaanit. Osuus koostui viidestä eri tehtävästä, joiden aihepiirit käsittelivät jotakin erityistä Java-ohjelmoinnin osa-aluetta. Opimmeko sitten sitä ohjelmointia kirjoittamalla paatosta olioista ja säikeistä? Kannattiko avata kalakirja? Arvostelustakin olisi jotakin sanottavaa, mutta pitäydyn tässä nyt kuitenkin lähinnä teoriatehtävien mielekkyydessä ja hyödyllisyydessä.

Teoriatehtävät olivat virkistävä säväys muuten niin ohjelmointi- ja matematiikkapainotteisessa syksyssä. Esseetehtävä ohjelmointikurssilla kuulostaa varmasti monen ulkopuolisen mielestä ideana aluksi vähän huvittavalta, mutta pienen sulattelun jälkeen se alkaa tuntua ihan järkevältä ajatukselta: kokonaisuuksien hallinta edellyttää vankkaa tietopohjaa.

Mikä on informaatioverkostojen ohjelmointikurssin idea ylipäätänsä? Minulla ei ole nyt tallessa syksyllä postitettua Studio1:n mainoslehtistä, mutta muistaakseni siinä painotettiin kurssin olevan lähinnä pohjana tulevia opintoja varten: ensisijaisesti infolaisista ei kouluteta koodareita, vaan kurssin tarkoitus on taata tarpeeksi laaja yleissivistys ohjelmoinnista ja ohjelman kehitysprosessista.

Essee- ja käsitekarttatehtävät ovatkin oiva lääke tällaiseen datanörttisivistymättömyyteen. Ja sitä paitsi – mihinkäs muualle kirjallinen tuottaminen sopisi kuin infolle? Onhan meillä muutenkin opintoja varsin laajalta skaalalta. Esseetehtävä koodauksen lomassa ei ainakaan heikennä tätä vaikutelmaa. Ripaus suolaa keitokseen, sivistystä kansalle, humanismia, luovuutta, Danten jumalainen näytelmä, suo, kuokka ja Jussi? Meni jo hiukan ylitse, mutta ehkä aavistuksen verran sinne päin kuitenkin.

Edellä viittasin teoriatehtäviin lähinnä essee-muodossa, mutta eipäs unohdeta ystäviämme viivoja, nuolia ja käsitteitä – tuttavallisemmin siis käsitekarttoja. Käsitteiden yhdistäminen toisiinsa vaatii yllättävän paljon asioiden hahmottamista. Vähän kuin yrittäisi koota palapeliä, mutta kirjaamalla lisäksi aina palojen väliin niiden välisen suhteen. Monesti käsitekartan teko veikin hieman yllättäen esseen kirjoitusta enemmän aikaa.

Kahden ensimmäisen tehtävän jälkeen jokainen sai itse valita kumpaan tehtäväformaattiin meinasi kallistua (ja kompastua?). Monelle Javaan jo kyllästymään ehtineelle löytyi kuitenkin varteenotettava, ei välttämättä moraalisesti kovin hyväksyttävä, oikotie: teoriatehtävän pystyi loihtimaan pikaisella aikataululla vilkuilemalla edellisvuosien portfolioista vastaavia tuotoksia. Mutta eipä siinä, aivan samalla tavalla nekin voivat olla lähteitä muun kirjallisuuden seassa, vaikka tuskin kovinkaan moni mainitsi näitä lähdeluettelossaan.

Esseen taas periaatteessa pystyi kirjoittamaan välttämättä asioita niinkään hahmottamatta, ns. nollat taulussa. Monesti esseen kirjoitus tuntuikin lähinnä lähdekirjallisuuden referoinnilta, mikä tietysti saattoi olla ihan hyväkin lähtökohta.

 

Ensimmäinen tehtävä oli lähestulkoon lähtölaukaus Studio1:lle. Tehtävässä tutustuttiin Java-ohjelmoinnin peruskäsitteisiin. Mielestäni se oli aika lailla välttämätön etappi syksyn koodaustaipaleelle. Kunnollinen perehtyminen helpotti ohjelmoinnin ensiaskeleita. Oliot ja luokat tulivat tutuksi esseekirjoittamisen muodossa.

Seuraaksi oli luvassa pakollinen käsitekarttatehtävä. Ympäristö oli varsin luonnollinen tietotyypit-aiheelle, ja niinpä integerit, booleanit ja arraylistit muuntuivat viivapalloviidakkoon ilman suurempia kasvukipuja. Swingiä ja säikeitä käsittelin myös käsitekarttamuodossa, kun taas poikkeukset löysivät tiensä tehtäväpalautuslaatikkoon esseekonseptissa.

Varsin harmillista oli kuitenkin alhainen painotus kurssiarvostelussa. Tässä olisi mielestäni hyvin paljon korjattavaa. Kahden prosentin sääntö (the 2%) vakiintui käsitteeksi phuksien keskuuteen ja sillä jaksettiin kyllä mehustella phuksien omalla IRC-kanavalla tiuhaan tahtiin aina ennen seuraavan teoriatehtävän palautuspäivää. Itse näin jälkikäteen voin sanoa siltikin käyttäneeni aivan liikaa aikaa kässee-tehtäviin ohjelmointitehtäviin verrattuna ottaen huomioon painoarvon arvostelussa – valitettavasti.

Miten tilannetta sitten voisi parantaa tulevaisuudessa? Helpoin ratkaisu olisi yksinkertaisesti lisätä esseetehtävien painoarvoa. Tai ehkäpä teoriatehtävät voisi liittää arvostelussa kiinteäksi osaksi ohjelmointitehtäviä, jolloin teoriatehtävä korreloisi suoraan Java-tehtävän arvosanaan. Yksi (huonompi?) vaihtoehto olisi jakaa Studio1-kurssi kahteen erilliseen arvosanaan – ohjelmointiosaan ja Studio1-osaan – aivan samalla tavalla kuin ne on nytkin jaoteltu erikseen kurssitarjottimella. Nykyinen arvostelusysteemi on kuitenkin niin turhauttava, että päättävien tahojen olisi syytä harkita muutoksia (mitä ne sitten ikinä ovatkaan) ihan vakavalta pohjalta.

Kaikesta huolimatta kässeistä jäi minulle – nippa nappa – plus-merkkinen fiilis. Koodauksen ilosanoman julistaminen teoriatehtävien muodossa tuki melko hyvin ohjelmointitehtävia ja paikkasi aukkoja Java-tietämyksessä. Ilman niitä ainakin jotkut asiat olisivat jääneet varsin vähälle ymmärrykselle.

Ja pelkästään se jos mikä on jo riittävä syy teoriatehtävien olemassaololle.

- Teemu

Mikä meni vikaan / mitä olisi voinut tehdä toisin

Näin jälkeenpäin on myös aina hyvä spekuloida mitä olisi voinut tehdä toisin.

Ensinnäkin ainakin suurin osa muista ryhmistä oli hyödyntänyt omissa boteissaan rajapintoja; meillä taas kaikki ominaisuudet sijaitsivat omissa luokissaan. Siksi aina kun haluttiin lisätä toiminto / muokata jotakin toimintoa, vaadittiin muutos myös Hepalon-luokkaan, minkä takia muutoksia ei voinut tehdä kesken kaiken. Tämä oli aika ärsyttävää etenkin testausvaiheessa.

Toinen asia, jonka olisi voinut toteuttaa toisinkin, oli alkometri-toiminnon sijaitseminen Hepalon-luokassa. Tämä ei vaikuttanut botin toimintaan millään tavoin, mutta ainakin koodista olisi tullut hieman selkeämpi jos jokainen toiminto olisi saanut oman luokan. Samoin alkometrin olisi voinut toteuttaa jonkin valmiin laskurin avulla, vaikka näin yksinkertaisessa laskussa toimi myös itse kehitelty kaava.

+ aika moni muukin juttu kusi, lisäillään niitä vielä tähän, aikaahan meillä riittää…

-Ulla

Botti Hepalonin rakenne

Toteutusalustana käytimme Paul Muttonin kehittämää PircBot-sovelluskehystä, joka tarjoaa rajapinnan IRC-protokollan ja Javan välille. Aluksi teimme erillisen HepalonMain-luokan, joka luo uuden Hepalonin, ottaa yhteyden IRC-serveriin ja joinaa Hepalonin !hepalonsorkat-kanavalle.

Luokka Hepalon, jonka periytimme luokasta PircBot, sisältää botin varsinaiset viestitoiminnot. Luontimetodi asettaa botin nimeksi Hepalon, ja onMessage-metodi tutkii kanavalle lähetettyjä viestejä. Jos viesti sisältää tietyn tekstinpätkän (esim. hevonen tai !help) metodi lähettää kanavalle määrätynlaisen viestin sendMessage-metodin avulla. Metodi ottaa parametrinaan kanavan ja lähettäjän, joten sillä voidaan “vastata” viestin lähettäjälle. Riippuen viestin sisällöstä metodi kutsuu tietyn ominaisuuden luokalta vastaukseen tarvitsemiaan tietoja.

Ominaisuudet ovat siis pääosin omissa luokissaan. Hevosiin liittyvä keskustelu ja alkometri on toteutettu Hepalonissa sendMessage-metodin sisällä, mikä ei välttämättä ollut siistein ratkaisu, mutta toimintojen yksinkertaisuuden ja koodin lyhyyden takia päädyimme tekemään niin.

- Asta

Juutupe

Botin yksi ehkä hyödyllisimmistä ominaisuuksista oli YouTube-ominaisuus, joka toimi siten, että havaitessaan kanavalla tekstin seassa youtube-linkin, Hepalon-botti haki videon otsikon sekä katsojamäärän. Tämän perusteella fiksu ihminen voi sitten päätellä, että kannattaako kyseinen linkki avata työpaikalla…

Ominaisuus oli toteuteutettu omaan luokkaansa. Konstruktorissa alustettiin url-niminen attribuutti. Sen arvoksi tallennettiin “http://www.youtube.com/watch?v=”. Otsikon ja katsojamäärän etsiminen toteutettiin omilla metodeillaan. BufferedReader reader = URLReader(url + address); Tässä määritellään url, josta haluttuja tietoja ruvetaan etsimään. Address-muuttuja liitetään urlin perään, se on tässä tapauksessa, jokin epämääräinen kasa kirjaimia ja numeroita, joka poimitaan käyttäjän pasteamasta youtube-linkistä. Oikea otsikko löydetään etsimällä yksinkertaisesti tekstinpätkä <title> ja </title> tagien välistä. Katsojamäärä toimii täysin samalla periaatteella, vain etsittävä tekstinpätkä on tällä kertaa “viewCount”. Tämän jälkeen Hepalon-luokassa etsittiin kanavan viesteistä viestiä, joka sisältää “youtube.com” Aluksi ongelmana oli viestit, jotka sisälsivät muutakin tekstiä kuin pelkän linkin. Tämä ratkesi siten että, tallennettiin kyseinen message kokonaisuudessaan taulukkoon sanoiksi splitattuna. Sen jälkeen käytiin for-loopilla taulukko läpi, etsien sanaa, joka alkaa “http://” Seuraavaksi etsittiin http://-sanasta tämä mystinen kirjain-numero-härpäke ja tallennettiin address-muutujaan. Katsojamäärän etsiminen onnistui ongelmatta. Nyt vain luotiin uusi YouTube-olio ja kutsuttiin sille näitä metodeja ja lähetettiin vastaukset kanavalle.

-Olli

Athenessa tapahtuu!

Mehän haluttiin bottiin oikeasti hyödyllisiä ominaisuuksia, jotka tarjoavat jotakin käyttistä infolaisille. Botti ei siis saanut olla pelkkä ärsyttävä toistaja, lelu tai ylipäänsä mikään turha tyhjäntoimittaja. Rakas kiltamme Athene on äärimmäisen aktiivinen lähes kaikkien jäsenten osalta, ja killan tapahtumiin otetaan aktiivisesti osaa suurillakin joukoilla. Päättelimme, että tällainen tapahtumankertoja voisi olla kaikille hyödyksi, sillä kukaan ei voi muistaa, mitä seuraavaksi tapahtuu, ja missä.

Loimme ominaisuuden !tapahtuma. Tällä komennolla botti etsii Athenen tapahtumakalenterista seuraavan tapahtuman ja kertoo sen kysyjälle. Koodiin otimme mallia Vesan toteuttamasta Mogaripostaus-etsijästä. Käytimme bufferedReader-lukijaa, joka etsi sivulta ensimmäisen tummennetun rivin, toisin sanoen koodinpätkän <br><br><b><p>, ja lopettaa kyseisen rivin lukemisen, kun vastaan tulee </b>. Tämä tekstinpätkä sitten tulostetaan kysyjälle vastaukseksi. Ominaisuus tehtiin omaan Tapahtuma-luokkaansa ja toteutettiin Hepalon-luokassa luomalla uusi olio aina kun joku lähettää IRC-kanavalle viestin “!tapahtuma”. Tämä tapahtumaolio sitten kutsuu Tapahtuma-luokan metodia, joka tulostaa tekstin kanavalle.

Samaan aiheeseen liittyen keksimme toisen ominaisuuden. Mitä kaikki Athenelaiset tekevät tapahtumien jälkeen? -No irkkaavat! Ja missä kunnossa kaikki siinä vaiheessa ovat? -No ihan helvetin moisessa kännissä!

Tämä innosti meitä tekemään ominaisuuden, joka kertoo irkissä aamuyöstä, tai milloin tahansa, oleskelevalle sankarille promillemäärän ja tämänhetkisen olotilan, jos sankarimme ei sitä itse huomaa. Ominaisuus toimii syöttämällä komento !alkometri m/n(sukupuoli) 70(paino, kg) 5(annosmäärä). Teimme toiminnolle vielä “apuviestin”, joka tulostuu, jos komento on syötetty jotenkin väärin.

Toteutimme alkometrin Hepalon-luokkaan. Perusteluja tälle ratkaisulle voisi keksiä vaikkapa millä mitalla, mutta siisteyden takia sekin olisi voinut olla toteutettuna omassa luokassaan. Alkometrin “loimme” itse. Arvoja ei siis syötetä minkään sivuston valmiiseen laskukaavaan, vaan itsekoodaamamme kaava laskee promillemäärän sukupuolen, painon ja nautitun annosmäärän perusteella. Annosmäärä on tietysti vähän kyseenalainen: kukaan ei kuitenkaan muista kuinka monta annosta on juonut, ja tuloskin on totuudenmukainen vain, jos kaikki annokset on nautittu lyhyen aikavälin sisällä. Tämä ei kuitenkaan estä toimintoa olemasta äärimmäisen hauska.

Itse toteutus sujui nopeasti ja sujuvasti. Ongelmiin ei juurikaan tarvinnut pysähtyä. Laskukaava ei ole kovin vaikea, käytimme netistä löytynyttä peruskaavaa. Ja neljännessä ohjelmointitehtävässä käytetty lauseen splittaus ja parsetus olivat avuksi, kun botti tarkistaa onko komento syötetty oikein.

Viimeisin lisäys bottikoodiin oli Matti-luokka, joka kaikille kiinnostuneille tai muuten vain tarvetta lisäsanonnoille tunteville antaa valmiin repliikin random-generaattorilla Matti Nykäsen arkistoiduista lausahduksista. Internet, tuo hyvä ystävämme, tarjosi pitkän litanian tällaisia lyhyitä ja hieman pidempiä Matin suusta tulleita pätkiä. Sieltä sitten kopioitiin luokkaan lista lauseita, joista botti arpoo satunnaisesti yhden. Tämä toiminto on hyödyllinen ja ennen kaikkea erittäin tarpeellinen siinä vaiheessa, kun kaikki on jo sanottu ja jotain kuitenkin pitäisi keksiä, ettei tuppisuina istuttaisi, edes irkissä. Matilla kun on aina jotain sanottavaa.

-Meri

Pelihimoa joulupöydässä..

Kohta koittaa aika, kun kaikki tentit ovat ohi, ja joulukinkku sulaa vatsassa. Joulurauha on julistettu, maassa on loskaa ja kaikilla rauhallinen mieli, kunnes.. Studio1-projekti pamahtaa päälle! Viisas aloittaa suunnittelun ja toteutuksen jo ennen tenttiviikkoa, tyhmä vasta joulun jälkeen.

Kukin voi kuvitella, kuulunko minä ryhmään ennaltaviisaat.

Projektin kohde ja aihe-ehdotus on joka tapauksessa jätettävä jo ennen tenttiviikkoa. Itse ehdotin, että teen projektikseni kasinopelin. Niille, jotka eivät tiedä, Kasino on korttipeli, jossa kerätään pisteitä kunnes joku pelaajista saavuttaa niitä 16. Jokaisella kierroksella käytetään yksi korttipakka ja pisteitä on jaossa ainakin 10, joskus enemmänkin. Oheisesta linkistä utelias pääsee katsomaan aiheen kuvausta Ohjelmoinnin peruskurssi Y1:n projektisivulta.

Kuten jotkut tietävät, kävin Informaatioverkostojen ohjelmointikurssin jo kaksi vuotta sitten. Tuolloin tein projektini samasta aiheesta, mutta toteutus jäi melkoisen torsoksi. Peli oli niin kuiva tekstiversiona, etten meinannut itsekään jaksaa pelata sitä läpi. Tällä kerralla tarkoituksenani on ainakin
- toteuttaa täysin toimiva peli ja
- tehdä pelille graafinen käyttöliittymä.

Lisäksi, mahdollisuuksien mukaan aion

- mahdollistaa pelaamisen 1-N tietokonevastustajaa tai muita ihmisiä vastaan (samalta näytöltä, tietty)
- lisäillä tilpehööriä kuten pelaajien kasvokuvien lataamista peliin, ääniä, pistelaskun tallentamista high scoresiin jne.

Lisään myöhemmin blogiin luonnoksen siitä, miltä pelin tulisi valmiina näyttää. Nyt ajattelin painua unten maille. Näkemisiin!
/Henri