Taitaapi kurssi jo olla loppumaan päin! Loppupuheenvuoron paikka. Ensiksi OLO-sessioista. Etenkin alussa tällä tavoin lähes viikottain työskentely tuntui turhalta, turhauttavalta, epämielenkiintoiselta ja tarpeettomalta. Porukkaa oli paljon, suutaan ei viitsinyt tuntemattomien, itseään enemmän tietävien henkilöiden keskuudessa paljoa availla, seitsemän askeleen menetelmä ei tuntunut toimivan ja muutenkin kokonaisfiilis OLOja kohtaan oli vähintäänkin nihkeä. Toisen kierroksen jälkeen tapaukset alkoivat kuitenkin tuntua huomattavan paljon mielenkiintoisemmilta, ja kolmoskierroksen kohdalla porukkaa karsiutui paljon pois, jättäen tiiviimmän ja paremmin toimivan ryhmän jälkeensä. Olisi varmaankin ollut hyvä, jos jo alusta asti ilmapiiri olisi ollut tälläinen, mutta toimintaperiaatteen epämääräisyys ja yleinen negatiivisuus heikensi kokonaisuutta.
OLO-sessioiden virikkeissä ei aluksi ollut itselle mitään uutta – eikä kieltämättä loppuakaan kohti hirveän paljoa – mutta ryhmän sisäinen keskustelu ja itse tutkittavat asiat toivat erittäin paljon syvyyttä tapausten luomille pohjille. Itse pidin paljon siitä, että opin hieman pintaraapaisua tarkemmin monenlaisia asioita. Ryhmä alkoi toimimaan loppua kohden varsin autonomisesti, ja ainakin itse tulin siinä vaiheessa OLO-tapaamisiin ennemminkin mielenkiinnosta kuin pakosta. Jos se muutos olisi tapahtunut jo aiemmin, olisi kurssilla varmasti ollut kokonaisuutena positiivisempi ilmapiiri – mm. tuotantotalouden ykköskurssilla tehtiin koko kurssin ajan laajaa ryhmätyötä hyvin pienen ryhmän kesken, ja se tuntui toimivan heti alussa paremmin. Tiedä sitten käytännön järjestelyjen hankaluuksista.
Mielestäni tietokoneiden sisäisen toiminnan ja ohjelmistojen suunnittelujen pääpiirteiden ymmärtäminen on hyvä jokaisen tietotekniikan opiskelijan osata, ja siitä tuli myös tällä kurssilla opittua niin aiheiden kuin harjoitusten muodossa. Kokonaisuus pysyi hyvin kasassa ja perusteltua itkemistä kuunneltiin mielestäni hyvin. Toisaalta, palautteen määrän perusteella voisi päätellä, että parannettavaakin on vielä paljon. Kieltämättä moni harjoitustehtävä tuntui hieman kohtuuttomankin laajalta tai epäselkeältä, ja deadlinet alkoivat ajoittain tulla kovastikin vastaan (nimim. useampi kierros yhä palauttamatta). Kuitenkin mielestäni kurssi oli käymisen arvoinen – kiitos kaikille sitä toteuttaneille siitä! 🙂
OLO-sessiot olivat ihan uudenlainen tapa käydä läpi uusia asioita. Alkuhankaluuksien (niin mitä meidän pitäisi tehdä?) jälkeen ryhmätapaamiset olivat ihan kivoja; itselläni ainaakaan ei ollut mitään stressiä ryhmästä, asiat otettiin varsin rennosti. Ehkä liiankin rennosti järjestäjien mieleen, arvelen ma, mutta parempi olla mukavempaa kuin oppia hitusen enemmän ja ahdistella viikottaista tapaamista.
Tärkeimmät asiat sessioilta oli jo suurinpiirtein tiedossa. Ei kurssi tietenkään pelkkää kierrätystavaraa ollut, sillä tulee kuitenkin nyt mieleen esimerkiksi MVC, mikä tavallaan oli tiedossa mutta tavallaan ei. Kuten palautelappuja täytettäessä viimeisellä kokoontumisella todettiin, ei ollut mitään absoluuttisen turhaa asiaa jonka olisi voinut kokonaan jättää pois. Tai noh, Platon…
Tehtävissä oli tekemistä. Ensimmäisestä (nollannesta) jäi tosin vähän karvas maku, kun oma liiankin verboosi miellekartta ei ollut ihan assarien mieleen. Ja “ensimmäisessäkin” meni ensimmäisellä kertaa ohi tehtävänannon painotus UML-kaavion esseeosuudesta, joka ei siis ollut tarpeeksi verboosi. Toinen tehtävä oli jännä kohinasimuloinnin ja virheeneston kanssa, ja kolmas tehtävä… kolmas tehtävä oli sitten jotain. Kuvien filtteröinti oli loppujen lopuksi ihan mielenkiintoista, vaikka tämä vähän “kokenutkin” koodaaja löysi monta mutkaa matkasta. Sokoban-klooni oli itselleni vähän turhan raskas, kun päätin että seinien tulee sovittautua vieressä olevien seinien perusteella! eikä kunnia antanut perääntyä. Voi niitä konditionaaleja ja match-caseja. Huh huh. Viimeinen kierros, pelikokoelma, tämä “tee tämä, ja tee se miten tahdot” ultimaallinen taitojen osoitus. Eh, täytyy tunnustaa että vika kierros ei ole ihan vielä valmis, mutta on ihan hyvä idea antaa vapaat kädet opiskelijalle, ja mikäs sen parempi (oikeasti) harjoitus kuin koodata muutama tuttu peli itse.
Loppujen lopuksi, vaikka kurssin huomaa olevan uusi ja sen kanssa on ollut vähän sähinää (ne irc-logit ovat viihdyttävää luettavaa jos osaa tilanteesta irtautua), en voi väittää etteikö kurssi ole ollut minulle hyödyksi. Kiitän kaikkia jotka ovat tässä olleet mukana.
Joten! Hyvää joulua ja aivan loistavaa uutta vuotta!
Toiseksi viimeisen tapaamisemme alussa käsittelimme kuvan varsinaisesti piirtämiseen liittyviä aiheita. Olimme jälleen kahden viikon ajan keränneet informaatiota erinäisistä asioista, ja tässä ovat lopputulokset tiivistettyinä:
Animaatio:
Animaatiot ovat käytännössä peräkkäin näytetty sarja kuvia, joita tarpeeksi nopeasti vaihtamalla saadaan ihmiselle luotua illuusio liikkeestä. Usein sanotaan, että kuvia on tietty määrä sekunnissa (frames per second), ja sen avulla voidaan hieman vertailla animaatioiden sulavuutta. Toteutustapoja on Scalassa useita, mutta yksinkertaisinta lienee päivittää näytölle piirrettävien Image-olioiden kuvaa tarvittaessa. Siinä on kuitenkin lukuisia puutteita – uudelleenpiirrettäessä ei voida suorittaa muuta ohjelmakoodia, animaation ajoitus oikeaan aikaan on vaivalloisempaa ja etenkin pelien toteuttaminen näin on ongelmallista.
Monella tapaa parempi ratkaisu olisi hyödyntää säikeitä. Luomalla Thread -olio ja jättämällä animaatioiden ylläpitäminen täysin sen huoleksi, saadaan ajoitus paljon helpommin toteutettua, samanaikaisesti suoritettua muiden objektien ohjelmakoodia sekä renderöidä kuvaa efekteillä haluttaessa. Kuitenkin sykronointi pääohjelman koodin suorittamisen vaiheiden kanssa voi olla erittäin olennaista tällä tavoin.
Canvasia käyttävä Graphics2D on hidas, kun piirrettäviä kuvaolioita on paljon. OpenGL on nopeampi monissa tilanteissa, ja muut menetelmät voivat olla tilanteesta riippuen vielä nopeampiakin. Tämä tuskin tulee kuitenkaan ongelmaksi, ellei luoda ohjelmia esimerkiksi puhelimille tms.
2D-grafiikka Scalassa
Scalassa ei ole natiiveja grafiisia ominaisuuksia, vaan kaikki piirtämistoiminnot tulevat suoraan Javan kirjastoista. Abstract Window Toolkit eli AWT ja Swing ovat Javan kaksi 2D-grafiikan kannalta erittäin olennaista pakettia. Niissä on paljon samanlaisia piirto-ominaisuuksia ja ne osittain käyttävät samoja luokkiakin, mutta erittäin olennainen ero tulee käyttöliittymän suunnittelun kanssa.
AWT ottaa käyttöliittymän ikkunaelementtien tyylit suoraan käyttöjärjestelmän omista tyyleistä, kun taas Swing piirtää ikkunaelementit omista tyyleistään. Muun muassa ongelmia aiheuttaa AWTia käyttävien ohjelmien porttaus, sillä eri käyttöjärjestelmissä ikkunaelementit voivat näyttää hyvinkin erilaisilta. Swingillä tehdyt ohjelmat sen sijaan näyttävät huomattavasti yhtenäisemmiltä eri käyttöjärjestelmien välillä. Tästä on etua, sillä ikkunaelementtien tyyli sisältää informaatiota mm. siitä, minkä kokoisia ja näköisiä erilaiset napit ja valikot ovat. Jos ero on kovin suuri, voi tarkkaan suunniteltu käyttöliittymä näyttää huonolta tai jopa aiheuttaa hankaluuksia muilla tietokoneilla käytettäessä.
Swing
Swing on Scalan peruskirjasto, jonka avulla on helppo rakentaa monenlaisia käyttöliittymiä. Sen luokat sisältävät määrittelyjä ja metodeja mm. nappuloiden, tekstikenttien, valikoiden ja valintalaatikoiden luomiseen ja käyttöön. Nämä käyttöliittymäelementit sitten jaetaan paneeleihin, joilla voidaan tarkemmin valikoida niiden sijaintia ruudulla.
Ne osaavat myös kuunnella erilaisia inputin tapahtumia, kuten hiirellä klikkausta tai näppäimistön käyttöä, ja heittävät tiedon käyttäjän tekemistä asioista tapahtumakuuntelijalle. Kuuntelija sitten suorittaa erilaisia metodeja riippuen siitä, mitä tapahtui ja missä. Tällä tavoin saadaan esimerkiksi toimintoja käyttöliittymässä olevaa nappia painettaessa.
OpenGLja renderöinti
Open Graphics Library, eli OpenGL on ohjelmistorajapinta, joka sisältää lukuisan määrän funktioita 2D- ja 3D-grafiikan luomiselle. Se on käyttäjästä ja käyttöjärjestelmästä riippumaton, sillä OpenGL-funktiot pelkästään käsittelevät kuvien tehokasta renderöintiä. Puhtaasti grafiikkaa käsittelevänä kirjastona OpenGL:n avulla ei siis pysty hoitamaan esimerkiksi standardien mukaisten ikkunakomponenttien tekoa, elementtien kuuntelemista tai muita vastaavia toimintoja. Vaihtoehtoisia rajapintoja on myös; pienempiä kuvien renderöintiin pureutuvia kirjastoja on lukuisia, ja eräs olennainen kilpailija on Microsoftin DirectX.
Renderöinti on kuvadatan luomista aiemman datan avulla, noudattaen tietynlaista mallia. 3D-grafiikan yhteydessä termillä viitataan mm. realististen valoefektien kirkkauksien laskemiseen. Videoiden renderöinnissä voidaan kuvasarjan jokaiseen kuvaan lisätä jonkinlainen efekti erilaisten filttereiden avulla, jotta saadaan esimerkiksi kuvasta terävämpää tai poistettua epähaluttuja asioita siististi. Esimerkiksi pelien yhteydessä reaaliaikaisesti useita kuvia peräjälkeen renderöidessä joudutaan säästelemään efektien hienoudesta, sillä aikaa yksittäisen kuvan luomiseen saattaa olla vain sekunnin murto-osa.
Nyt se sitten alkaa olla viimeisiä taputteluja vaille valmis, Studio 1 -kurssi nimittäin. Ei voi muuta sanoa kuin, että “Huh, huh!”. Tuohon kiteytyykin päällimmäiset tuntemukseni kurssin suorittamisen jälkeen. Vaikka tuosta lausahduksesta varmaan moni päätteleekin, että olen helpottunut kurssin ollessa ohi, niin toisaalta hyvillä mielin todeta oppineeni kurssilla todella paljon ohjelmoinnista, ja siksi tästä kurssista jäi minulle hyvät fiilikset. Haluan nyt heti kiittää ryhmäni jäseniä ja assaria Johannesta yhteisistä OLO-hetkistä. Teidän kanssa oli mukava oloilla ja suorittaa kurssia!
Ensimmäisissä OLO-tapaamisissa ei kukaan oikein tiennyt, miten ryhmissä pitäisi työskennellä ja mitä ylipäätänsä kurssilta olisi saattanut odottaa. Tämän tiedon puutteen tuoman alkuhämmennyksen voitettuamme, ryhmässämme syntyi joka viikko hyväntuulista ja vilkasta keskustelua silloisella hetkellä työn alla olleista aiheista. Itselleni, ohjelmoinnin vasta-alkajalle, moni asia oli ja on edelleen tietotekniikan osalta uutta ja vierasta, mutta pyrin OLO-sessioissamme imemään mahdollisimman paljon tietoa itseeni, ja mielestäni siinä hyvin onnistuinkin. Ryhmämme vanhemmat ja muutkin tietoteknisesti tietävämmät jäsenet pitivät kyllä huolen siitä, että sain joka viikko uutta tietoa muistiini. Vaikka informaatiotulva olikin OLOjen osalta suuri, ei tiedon janoni hiipunut silti yhtään, sillä alan kiinnostavuuden kautta uutta, ja välillä myös vähän hämmentävää asiaa oli mielekästä oppia. Harmittavaa oli, että OLO-ryhmämme jäsenten määrä kutistui kursin edetessä lopulta puoleen alkuperäisestä vahvuudesta. Ryhmän koon pieneneminen aiheutti keskusteluiden monipuolisuuden katoamista ja sen, että OLO-tapaamisiin valmisteltavat esitykset muuttuivat jokaisen osalla aihealueiltaan laajemmiksi, minkä seurauksena moneen asiaan saatiin vain pintaraapaisu.
Suurimman osan kurssin suorittamisen vaatimasta ajasta veivät OLOjen sijaan kuitenkin itse harjoitustyöt, joiden tekeminen tuotti ainakin itselläni välillä harmaita hiuksia, kun kaikki tehtävänannot eivät olleet aivan sieltä selkeimmästä päästä. Olisin toivonut ehkä vähän aloittelijaystävällisempää ohjeistusta tehtävien osalta, mutta varmasti tämän kurssin tarkoituksena oli osoittaa ja totuttaa opiskelijat siihen, että työelämässäkään asiakkaan ohjelmalle antamat kriteerit ja ohjeet eivät aina ole yksiselitteisiä. Itse opin sen tämän kurssin myötä, sillä samaan aikaan Studion kanssa rinnakkain suoritetulla Ohjelmointi 1 -kurssilla kaikki asiat selitettiin kädestä kiinni pitäen, jotta myös tällaiset ohjelmointitaidoiltaan vajavaiset opiskelijat ymmärtäisivät käsiteltävät asiat. Se peruskurssin tarkoituksena onkin ja hyvä niin, joten siihen verrattuna tämä Studio 1 oli kuin toiselta planeetalta tempaistu. Tämä kurssi oli nimittäin vaikeustasoltaan ja työmäärältään täysin omaa luokkaansa, jos sitä vertaa muihin tähän mennessä suorittamiini yliopistokursseihin.
Harjoitustöiden osalta ensimmäisen kierroksen UML-kaavion sisältö ja merkitys ohjelmoinnissa eivät vieläkään ole hahmottunut minulle aivan kokonaan. Tämän lisäksi myös kolmannen kierroksen filtterit tuntuivat aluksi ylipääsemättömän vaikeilta toteuttaa, ja koodaamista ei yhtään helpottanut heti tehtävänannon alussa käsitelty Fourier-muunnos, joka tuntui täysin heprealta. Tähän kierrokseen kului minulla varmasti eniten aikaa muihin tehtäviin nähden, luukun ottamatta kurssin päättänyttä grande finaalia, johon oli aikaisemmista kierroksista poikkeavasti annettu aikaa kolme viikkoa ja jonka pisteytys myös erosi muista tehtävistä. Tuota kuudennen kierroksen peliohjelmointia oli mielestäni ehdottomasti hauskinta ja mukavinta tehdä, sillä siinä pääsi työstämään graafista käyttöliittymää sekä ilmettä koodin kautta ja oman työn tuloksen näki heti. Tehtävän toteuttamiseen annettiin myös muutamaa ohjeistusta lukuun ottamatta vapaat kädet, joten edellisten kierrosten tapaan ei tarvinnut tuskailla valmiiden koodin pätkien kanssa. Ohjelmoinnin aloittaminen “tyhjästä” ei kuitenkaan ollut helppoa vasta-alkajalle (minulle), eikä mielestäni sellaista pitäisi edes vielä vaatia tässä vaiheessa opintoja.
Studio- ja Ohjelmointi 1 -kurssilla oli myös havaittavissa ajoittaisia synkronointiongelmia, sillä esimerkiksi silmukat ja GUI käsiteltiin täällä Studiossa ennen kuin niitä oli nähtykään peruskurssilla. Mielestäni asiat olisi ensin pitänyt opiskella peruskurssilla ja vasta sitten soveltaa Studiossa, sillä esimerkiksi silmukat kasvattivat toisen kierroksen koodauksen ja dekooodauksen vaikeustasoa entisestään. Toisaalta niiden käytön opettelu Ohjelmointi 1:ssä tuntui naurettavan helpolta Studion harjoitustyön jälkeen.
Kurssin ehkä yksi mieleenpainuvimmista kokemuksista oli yli puolen vuorokauden mittaiset lauantain deadlinea edeltävien perjantaiden koodaussessiot Paniikissa, ja joskus ihan oikeasti paniikissa, kun jokin tehtävän osa ei meinannut aueta. Muutamana perjantaina sessiot venyivät jopa yön yli aamuun, kun deadlinet hengittivät pahasti niskaan. En ollut kuitenkaan ollut yksin tässä tilanteessa, sillä Paniikissa oli myös muita kohtalotovereita, joiden henkisellä tuella jaksoin suorittaa kurssin kunnialla loppuun asti. Yhdessä panikointi lievitti ainakin minun stressiäni tehtävien suhteen, kuitenkaan sitä kokonaan poistamatta. Luulen, että myös kaverini ovat tunteneet osaltaan osin samoin.
Nyt lopulta voin rehellisesti sanoa oppineeni näiden kahden ohjelmointikurssin myötä koodaamaan ainakin perustasolla, sillä ennen elokuista Espooseen muuttoani en ollut kirjoittanut riviäkään koodia, saati sitten kuullut Scalasta, muista ohjelmointikielistä senkin edestä. Tämä Studio-kurssi on konkretisoinut huomattavasti käsitystäni ohjelmoinnista, sillä “oikeassa elämässä” ohjelmointiin ei anneta vaiheittaisia ohjeita, vaan koodin tuottaminen pitää aloittaa puhtaalta pöydältä. Kurssin avulla opin myös todella paljon yleistä tietoa ja vähän enemmänkin tietotekniikasta, jonka takia ylipäätänsä hakeuduin Otaniemeen.
Tähän on hyvä lopettaa, ja lopuksi haluan toivottaa kaikille oikein hyvää, rauhallista ja lämmintä joulua! Etenkin tuota lämpöä tuntuu täällä eteläisessä Suomessa vielä riittävän, mutta toivottavasti jouluksi saadaan pientä pakkasta ja valkea maa! 🙂
Kurssin viidennen kierroksen harjoitustyön aiheena oli ohjelmoida yksinkertaistettu versio klassikoksi muodostuneesta Sokoban-ongelmanratkaisupelistä. Sokobanissa pelaaja siirtelee laatikoita tai muita vastaavia esteitä ennalta määrättyihin paikkoihin, ja pelin läpäistäkseen pelaajan on saatava siirrettyä kaikki laatikot merkityille paikoille. Pelin osatehtävien ratkaisemiseksi pelaajan täytyy aina miettiä, millaisia seurauksia tietyn esteen siirtämisellä on jatkoa ajatellen.
Scala-muotoinen ohjelmointitehtävämme oli tosiaankin karsittu versio alkuperäisestä esikuvastaan, sillä meidän versiossamme pelin osatehtävien läpäisemiseksi riitti ainoastaan esteiden siirteleminen pois kulkuväylältä siten, että pelaaja pääse maaliin. Tämän kertainen koodaustehtävä oli täysin erilainen kuin edellisen kierroksen kuvasuotimien kanssa puuhastelu. Kuvakoodauksen jäljiltä minulla, jolla ei ennen Otaniemeen ja Tikille tuloa ollut mitään aikaisempaa kokemusta ohjelmoinnista, oli varsin kaksijakoiset tuntemukset ohjelmoinnista. Toisaalta oli onnistunut fiilis, kun olin saanut aluksi ylipääsemättömän vaikealta tuntuneen tehtävän kunnialla tehtyä. Toisaalta oli vähän sekavat tuntemukset siitä, että tälläistako ohjelmointi sitten ylipäätänsä tulee olemaan, sekavaa ja raskasta. Onneksi tämän viidennen kierroksen Sokoban oli lähempänä sitä, mitä olin ehkä jonkin verran ohjelmoinnilta odottanutkin, vaikka sisältyyhän koodaamiseen paljon muutakin kuin graafisten käyttöliittymien parissa työskentelyä.
Tämän kertaisen näpyttelyn tehtävänanto oli jo mielestäni sitä tasoa, jota voisi ohjeistukselta odottaakin; selkeä ja kattava. Lisäksi kierrokseen liittyvän OLO-tapaamisen virike antoi perustietoa piirtämiseen tarkoitetun Graphics2D-luokan käytöstä, jota hyödynnettiin Sokobanin graafisen ilmeen muodostamisessa. Ohjelmointi 1 -kurssilla graafisia käyttöliittymiä oli jo aikaisemmin sivuutettu hiukan, mutta sen enemmin niistä tiedoista ei tässä tehtävässä ollut apua. Näillä perusteilla ryhdyin tuottamaan tehtävän vaatimaa koodia ja aluksi tehtävä tuntuikin haastavalta, mutta kun aiheesta sai kunnon otteen ja teki omaa etsivän työtä, alkoi koodia syntyä tasaiseen tahtiin. Tehtävän suorittamisen kannalta varmasti eniten haasteita tuotti siis se, että Scalan Swing-kirjaston oma dokumentaatio ei näin aloittelevan ohjelmoijan näkökulmasta ole se kaikkein selkein ja yksinkertaisin opas. Pulmien ratkaisemiseksi jouduinkin käyttämään huomattavan paljon Googlea apunani, jotta Eclipsen antamista virheviesteistä päästiin eroon. Assareiden antamaa apua ei pidä sitäkään yhtään vähätellä, sillä ilman heitä tämän kurssin suorittamisesta ei yksinkertaisesti tulisi yhtään mitään. Tehtävä itsessään ei siis loppujen lopuksi ollut edes kovin vaikea, mutta ensikertalaisen alkuhaparoinnit tuottivat aluksi mutkia matkaan eikä tehtävänannon kuvan mukaiselta reaktioltakaan voitu välttyä, mutta onneksi virheet oli helposti löydettävissä ja korjattavissa. Suurimmat ongelmat johtuivatkin siis Swing-kirjaston dokumentaation auttamattomasta köyhyydestä, tai ehkä en vain osannut hyödyntää sen kaikkea potentiaalia.
Tehtävän palauttamisen jälkeen miettiessäni, mitä kierroksesta oli jäänyt käteen, pystyin rehellisesti toteamaan, että aika paljonkin. Opin nimittäin käyttämään Graphics2D:tä ja Scalan Swingiä perustasolla, ja näitähän tullaan hyödyntämään myös kurssin seuraavalla ja samalla myös kurssin päättävällä ohjelmointikierroksella, jossa koodataaan yhteensä kolme pientä peliä ja omien mieltymysten sekä taitojen mukaan myös lisäpelejä.
Tässä vielä lopuksi kuvakaappaus omasta tuotoksestani tältä harjoituskierrokselta. Aikaansaannokseni ei kuitenkaan ole se kaikkein kaunein monipuolisin toteutus, jonka tehtävänannon puitteissa olisi voinut koodata, mutta aikaa on aina rajallinen määrä ja haasteiden tuomat viivästykset syövät sitä yleensä yllättävän paljon. Nyt voin kuitenkin luottavaisin mielin jatkaa kohti finaalikierrosta. 🙂
Viimeisen OLO-session angendana oli kuudennen eli kurssin päättävän kierroksen (GUI) purku ja lopuksi ryhmän jäsenten yhteisen palautelomakkeen täyttäminen. Kun kaikki ryhmän jäsenet olivat saapuneet paikalle kävimme heti purkamaan viimeisen tapauksen sisältöä. Edellisellä kerrallahan tutkittavaksi aiheiksi oli valikoitunut käytettävyystestit, hidden test ja käyttöjärjestelmille laaditut interaktion suositukset, joista edelleen tarkasteltiin Windows Phonen ja Androidin ominaisuuksia. Seuraavassa lyhyesti, mitä saimme aiheesta irti.
Videopelien oudot ominaisuudet
– Tyyppi 1 – Debug-toiminnot:
Joihinkin peleihin on kehitysprojektin jäljiltä jäänyt erilaisia debug-toimintoja. Esimerkiksi Windows XP:n Space Cadet -pinball pelissä pelin aikana kirjoitettu “hidden test” avaa useita eri debug-ominaisuuksia. Palloa on mun muassa mahdollista liikuttaa hiirellä ja pistesaldo on mahdollista muuttaa arvoon 1,000,000,000. Lisäksi on esimerkiksi mahdollista katsoa pelin viemän muistin määrä ja kehysnopeus. Tarkemmin Pinballin “hakkeroinnista” on kerrottu tämän linkin takana.
– Tyyppi 2 – Pelin tekijöillä oli tylsää tai he halusivat välittää jonkin viestin:
Avoimesta pelimaailmastaana tunnettu Grand Theft Auto -pelisarja on tästä mainio esimerkki. Esimerkiksi GTA IV – pelissä New Yorkin edustalla sijaitsevalla, Liberty Islandin saarella Vapaudenpatsas on kaikkea muuta kuin pelkkä viaton patsas. Vapaudenpatsaan ovikyltissä nimittäin lukee…
“No Hidden Content this way”
…ja mitä patsaan sisältä paljastuukaan…
“Heart of the City”
Eivätkä patsaan kasvotkaan taida ihan vastata esikuvaansa…
Jos kiinnostuksesi heräsi, aiheesta löytyy enemmän tietoa tämän linkin takaa.
– Tyyppi 3 – Pelin tekijät olivat laiskoja tai budjetti loppui kesken:
Seuraava video kertoo luultavasti kaiken tarvittavan siitä, mitä seurauksia tällä voi olla.
Sittemmin huippusuosion saavuttanut Creepy Watson on myöhemmissä saman studion Sheerlock Holmes -peleissä jätetty tarkoituskella enalleen.
Käytettävyystestit
Käytettävyystestaus on prosessi, jossa käyttäjien avulla arvioidaan tietyn tuotteen käytettävyysongelmia, esimerkkinä käyttöliittymien testaus. Tuotteen kohderyhmästä valitaan käyttäjiä, jotaka testaavat tuotetta valvotuissa olosuhteissa. Pelkkä mielipiteiden keräämien ei ole käytettävyystestausta, vaan olennaista on nimenomaan myös testin systemaattinen tarkkailu. Käyttäjien toiminnasta voidaan päätellä, mitkä asiat esimerkiksi juurikin käyttöliittymän käytössä aiheuttavat ongelmia ja mitkä taas luonnistuivat helposti.
Vuorovaikutus käyttäjien kanssa antaa suoraa palautetta siitä, mtien tuotetta kannattaa kehittää eteenpäin. Tarkoituksena ei välttämättä ole löytää joka ikistä ongelmaa tai todistaa nitä tieteellisesti.
Testiin osallistuu usein muutamia käyttäjiä, koska parilla ei saada tarkkoja tuloksia ja todella suuret ryhmät vaatiavat paljon resursseja. Testillä on tarkkailijoita tyypillisesti yhdestä kolmeen, ja he voivat olla joko taustahavannoitsijoita tai näkymättömissä.
Käyttöjärjestelmien interaktion suositukset
Tarkastelun kohteina oleiden moobilialustoiden Windows Phonen ja Androidin sovelluskehittäjille annettuissa ohjeissa on monia yhtäläläisyyksiä, mutta vähintään yhtä paljon löytyy myös poikkeavaisuuksia.
Alustoiden varmasti tärkein omien sovellusten yhtäläisyys on appien ulkoasu. Valmistajat haluavat säilyttää niissä samat piirteet, jotta sovellusten käyttäminen olisi kautta linjan helppoa ja intuitiivista. Windowsilla ulkoasun määrittely on ehkä kuitenkin Androidia vähän tiukempaa. Android-alustalla sovelluksilla ei nimittäin aiemmin ollut ulkoasun määräviä kriteereitä, mutta sittemmin Google on halunnut järjestelmänsä ulkoasuun yhdenmukaista logiikkaa. Molemmille käyttöjärjestelmile yhteistä on myös omien sovelluksien johdonmukainen käytettävyys. Tämä tarkoittaa sitä, että jos esimerkiksi sovelluksessa olevalla painikkeella on tietty toiminto, täytyy vastaavan ulkoasun omaavan painikkeen suorittaa toisessa ohjelmassa samankaltaiset toimenpiteet.
Mobiilialustoiden eroavaisuuksia mainitakseni Windows Phonen sovelluksissa painotetaan liikettä ja elävyyttä, kun taas Androidin puolella asiat pitäisi ilmaista mielummin kuvien avulla kuin tekstillä, kertoohan kuva tunnetusti enemmän kuin tuhat sanaa. Androidilla myös tiedon nopea käytettävyys on avainasemassa, mikä tarkoittaa sitä, että käyttäjän syöttämää tietoa pitäisi tallentaa laitteen musitiin, jotta sama tieto on myöhemmin nopeasti saatavilla. Tällä pyritään siihen, että samaa asiaa ei tarvitsisi kertoa laitteelle joka kerta uudelleen. Windowsin kehittäjille annetaan puolestaan ohjeeksi sovelluksen ongelmaton eri ympäristöissä; onhan Windows alun alkaen ollut PC-tietokoneiden käyttöjärjestelmä eikä mobiilikäyttöjärjestelmä.
Tämän linkin takaa löytyy vielä pääpiirteet Androidin appien kehittämiseen annetuista ohjeista, joiden avulla sovellusten kehittäjät voivat laatia käyttäjäystävällisiä ohjelmia.
Tämän kertaiseen OLO-tapaamiseen oli tosiaan kokoontunut noin puolet ryhmämme alkuperäisestä vahvuudesta. Tenttiviikkoa eletään, mutta liekö katoon muitakin syitä – mene ja tiedä. Saimme kuitenkin viiden hengen voimin pohjustettua seuraavaa aihetta eli web-teknologioita, joiden tiimoilta syntyikin mukavasti keskustelua. Kun viisi päätä “lyötiin yhteen”, post-it-lapuille saatiin stormattua seuraavia asioita:
(Klikkaa isommaksi)
Ja näistä asioista seuraavalle OLO-sessiolle tutkittaviksi aiheiksi valikoitui kuvan mukaisesti:
Ensimmäisen session tuotokset purettuamme ryhdyimme pohtimaan olioihin liittyviä asioita. Post-it -lapuille kertyi paljon näkyvyyteen, periytymiseen, pakettistruktuuriin ja olio-ohjelmointiin liittyvää käsitteistöä. Sivusimme myös olioiden ideaa, sekä olio-ohjelmoinnin vaikutusta ohjelmointiin kokonaisuutena.
yolol10 
