Harjoitustyö

Tällä sivulla kerrotaan yleisesti harjoitustyöstä. Sivu kannattaa toki aluksi lukea huolella läpi, mutta ennen kuin teet mitään, niin muista että olet katsonut ohjeen ja/tai videon:

1. Harjoitustyö tällä kurssilla

  • on osa kurssisuoritusta ja arvioidaan asteikolla hyväksytty/hylätty. Harjoitustyö pitää olla hyväksytty ennen kuin kurssista voi saada arvosanan. Kevät 2021: Erityisen ansiokkaasta harjoitustyöstä voi saada korotuksen arvosanaan. Jos olet sitä mieltä että olet korotuksen ansainnut, ole yhteydessä Antti-Jussiin.
  • tehdään yksin tai parityönä. Mikäli luontaista paria ei löydy, ei sitä kannata ehkä etsiäkään väkisin. Kevät 2021: Kolmen hengen ja sitä isompia ryhmiä ei hyväksytä.
  • sisältää keskimääräisesti opiskelijaa kohti noin 30 tuntia työtä (ks. kurssin työmäärä). Parityönä tehtävän työn määrä on siis keskimäärin 60 tuntia, ks. tarkemmat vaatimukset paritöille alla.
  • on lähtökohtaisesti Jypeli-työkaluilla tehty peli, mutta myös jokin muu ohjelma käy myös.

2. Vaiheistus

Harjoitustyön vaiheet
Harjoitustyön vaiheet

Tarkat aikataulut kurssin kotisivulla

3. Vaatimukset

Pelissä pitää tapahtua jotakin, eli ruudulla pitää tapahtua jotain järkevää, johon käyttäjä voi osallistua.

Työssä on oltava vähintään muutama aliohjelma Jypelin valmiiden aliohjelmien (Main, Begin) lisäksi.

Muut tarkastettavat osa-alueet on lueteltu alla, kohta 3.1.

Parityöt, työnjako: Molempien on annettava kutakuinkin yhtäläinen panos työn ohjelmalliseen toteutukseen. Yksittäisenä varoittavana esimerkkinä mainittakoon epätasapainoinen työnjako, jossa toinen on paneutunut grafiikan tekemiseen ja toinen ohjelmointiin. Tällöin grafiikkaan paneutuneelta osallistujalta voidaan pyytää lisänäyttöjä työn ohjelmalliseen toteutukseen johon parityön toinen osapuoli ei saa osallistua. Lisäksi kummankin tekijän on pystyttävä esittämään riittävän tarkka tuntikirjanpito ja selvitys mitä työajalla on tehty, jotta osaamistavoitteet ohjelmoinnin osalta voidaan todentaa.

Parityöt, työn vaativuus: Työn on oltava vaativampi kuin yksin tehdyn työn, ja tässä työmäärä on tärkein mittari. Ohjaajat käyvät työn läpi tarkastustilaisuudessa ryhmäläisten kanssa. Yksittäistä pelin ominaisuutta joka kaikilta paritöiltä vaadittaisiin ei yleisellä tasolla voi antaa. Näiden kriteerien tarkoitus ei ole vaikeuttaa tekemistä vaan ehkäistä ennalta vapaamatkustamista.

#

3.1 Tarkastettavat osa-alueet

Tämä lista on esitellyn työn muuttaminen "100%" valmiiksi. Huomaa lainausmerkit :-)

Alla on tarkastettavien osa-alueiden lista, jonka ohjaajat tulevat tarkastamaan harjoitustyön esittelemisen yhteydessä. Jos ok, niin merkintä tulee TIMiin.

  1. Nimeäminen on johdonmukaista ja noudattelee kurssin koodauskäytänteitä.
  2. Näkyvyys: Aliohjelmien ja attribuuttien näkyvyys tulee olla määritelty (public, private). Julkisia staattisia (public static) muuttujia ei saa olla.
  3. Ei turhia peliluokan attribuutteja. Jos joitain koko peliluokkaan näkyviä arvoja tarvitaan, pyritään käyttämään vakioita (const). Kuvat, äänet, animaatiot ja muut raskaat resurssit on kuitenkin hyvä pitää attribuutteina, jolloin ne ladataan vain kerran pelin aikana. Esim. kuvien olioviitteet voi kiinnittää muuttumattomaksi static readonly määreellä.
  4. Toimii: Ohjelma toimii, ei kaadu ja päättyy asiallisesti. Pelissä pitää tapahtua joakin järkevää, johon käyttäjä voi osallistua interaktiivisesti. Pelissä pitää myös olla tavoite, haaste tai tarina.
  5. Ei toistoa, joka olisi voitu tehdä silmukoilla tai aliohjelmilla. Myöskään aliohjelmien välillä ei saa olla toistoa: esimerkiksi LuoVihu1 ja LuoVihu2, joissa olisi lähes sama koodi kahteen kertaan.
  6. Taulukko: Käytetään taulukkoa tai listaa. Tietorakenteella täytyy olla jokin tarkoitus siten, että sinne tallennetaan useita arvoja, joita todella käytetään pelissä. Tietorakenteen käytön tulee parantaa koodin laatua ja helpottaa koodin lukemista, kirjoittamista tai edelleenkehittämistä. Keinotekoisia tai vailla käyttötarkoitusta olevia tietorakenteita ei hyväksytä. Esimerkkejä.
  7. Silmukka: Ainakin yksi silmukka. Silmukalla täytyy olla jokin tarkoitus siten, että rakenteen avulla luetaan ja/tai käsitellään tietoa. Ei riitä että lisätään "tähtiä taivaalle silmukassa 10 kpl." Silmukalla tulee olla merkitys, joka parantaa koodin laatua ja helpottaa koodin lukemista, kirjoittamista tai edelleenkehittämistä.Esimerkkejä.
  8. Ei turhia literaaleja: Kiinteiden lukuarvojen tai muiden sellaisten arvojen käyttö, jotka heikentävät koodin ylläpidettävyyttä, on kielletty. Et siis saa tehdä koodia kuten if (y < 18), jossa 18 on hyvin todennäköisesti turha literaali. Sen tilalle tulee laittaa muuttuja tai vakio, kuten int pisteraja = 18. Vakiot ilmaistaan const-määreellä.
  9. } + 2 tyhjää: Aliohjelmien loppusulun } jälkeen tasan kaksi tyhjää riviä.
  10. Dokumentaatio: Luokat, aliohjelmat ja attribuutit tulee dokumentoida. Dokumenteissa kuvataan muun muassa sitä, mitä aliohjelmat tekevät, ei miten ne sen tekevät. Luokan alussa tulee olla tekijän nimi ja versio (@author, @version). Attribuutit dokumentoidaan summary-tagein.
  11. Funktio: Pelissä on funktio. Funktio ottaa vastaan parametrin tai parametreja, käsittelee parametrina saatua tietoa, ja palauttaa arvon annetun syötteen perusteella. Funktion täytyy prosessoida tietoa jotenkin; funktiolla täytyy olla jokin todellinen tarkoitus ohjelman kokonaisuuden kannalta. Tyypillisesti funktiossa voi hyödyntää silmukkaa tai taulukkoa/listaa. Esimerkkejä.
  12. Ei-pelien tapauksessa osoitettu myös taito testata aliohjelmia.

Voisiko tuota “Ei turhia literaaleja” -sääntöä vielä vähän täsmentää? Esimerkistä oli ainakin meikäläisen vaikea saada kiinni.

06 Feb 19 (edited 06 Feb 19)

Literaalien osalta varmaan tarkoitettiin esimerkiksi tilannetta, jossa pelissä on useampi kohta jossa käpistellään samaa taulukkoa for-silmukoilla ja for-silmukan rajat on määritetty mielivaltaisesti esimerkiki i < 30 - periaatteella. Jos myöhemmin haluat muuttaa taulukon kokoa, niin joutuisit etsimään jokaisen viittauksen taulukon maksimikokoon, kun homman olisi voinut hoitaa niin, että ohjelman alussa määritellään “taulukonKoko = 30” ja myöhemmin pelkästään tätä muuttamalla voidaan muuttaa kaikkien taulukoiden käsittelytapa, kun ehtona silmukoissa onkin i < taulukonKoko.

28 Feb 19 (edited 01 Dec 20)
#

4. Miten peliin taulukko, silmukka ja funktio?

Käsitellään pelin olioita tai muuttujia

Pelissä voi olla hyötyä siitä, että tietyt oliot tallennetaan myöhempää käyttöä varten tietorakenteeseen, eli nyt taulukkoon tai listaan. Tämän jälkeen koko oliojoukkoon tai joihinkin valikoituihin alkioihin päästään käsiksi pelin aikana, ja voidaan silmukan avulla esimerkiksi:

  • tuhota ruudulla näkyvät viholliset,
  • piilottaa osa kerättävistä esineistä,
  • tai liikuttaa kaikkia esteitä vasemmalle.

Käsitellään tietoa pelin tapahtumista

Lähde pohtimaan asiaa siitä suunnasta, että mitä tietoa pelissä voisi kerätä ja käsitellä. Jos jo peliä suunnitellessa mietit millaista pelidataa olisi kiinnostavaa kerätä, niin sitten tätä dataa on ehkä luontevampi käsitellä ja sovitella osaksi peliä.

Taulukkoon tai listaan voi kerätä tietoa esimerkiksi:

  • pelaajan painamista painikkeista,
  • kerätyistä tavaroista,
  • törmäävien objektien "tägeistä",
  • kenttien pistemääristä,
  • tapahtumien aikaleimoista,
  • ratojen suoritusajoista,
  • tai jostakin muista pelitilanteista.

Sopivan hetken tullen voidaan ottaa tämä tietojoukko, käsitellä se jotenkin silmukan avulla ja hyödyntää tätä käsiteltyä tietoa pelissä. Luontevia käännekohtia ovat esimerkiksi kentän vaihtuminen, pistemäärän tai aikarajan ylittyminen, tai pelin alusta alkaminen.

Käsittely voi tarkoittaa vaikkapa suoritusaikojen keskiarvon, kuljetun matkan tai kentän loppupisteiden laskemista, pienimmän tai suurimman lukumäärän etsimistä, kaksinpelissä pallon hallinta-aikojen yhteenlaskua, ja niin edelleen. Tämän toiminnallisuuden erottaminen omaksi funktiokseen voisi olla hyvä idea.

Keksi tapa, jolla voisit hyödyntää tällaisia tietoja pelissäsi. Yksinkertaisin tapa on tietysti näyttää laskettu tieto käyttäjälle. Toisaalta voisi olla hienoa jos tietoa voisi hyödyntää tavalla, joka on oleellinen osa pelin toimintaa.

Jypelin kirjaston ohjeissa on koodiesimerkkejä, joissa käytetään silmukkaa tai taulukkoa. Nämä eivät sellaisenaan riitä täyttämään vaatimuksia silmukasta ja taulukosta, koska ne eivät ole oman ajatustyön tulosta.

Mikäli omassa pelissä ei ole taulukkoa/listaa, silmukkaa tai funktiota, pitää ohjaajalla esittää täysin itse tehdyn demotehtävän vastaus, missä em. asioiden osaaminen on näytetty. Tästä voi laittaa vaikka kommentin omaan harjoitustyöhön tyyliin:

// TODO: taulukko, ks: https://tim.jyu.fi/answers/kurssit/tie/ohj1/2021s/demot/demo7?answerNumber=1&task=matriisiensumma&user=vesal

Linkin saa otettua demotehtävän vierellä olevasta pienestä Link-linkistä klikkaamalla sitä hiiren oikealla painikkeella, ja kopioimalla linkin osoite.

5. Versiohallinta

Harjoitustyön koko Solution sekä harjoitustyön suunnitelmakuva tallennetaan versiohallintaan.

6. Aikataulut

Harjoitustyön aikataulun muodostavat neljä virstanpylvästä

Vain syksyn kurssilla: Jos näyttää ajoissa, eli vähintään 3 pv ennen takarajaa (takarajat alla boldilla, bonus siis aina viimeistään tiistaina), saa yhden kurssin lisäpisteen/ HT vaihe.

  • Vaihe 1: Suunnitelma TIMissä demo 5 deadlineä edeltävään perjantaihin mennessä. Suunnitelma on kirjoitettu TIMiin ja kuva laitettu versiohallintaan. Esittele suunnitelmasi ohjaajalle. Varaa aika Korpista.
  • Vaihe 2: 50 % valmis demo 8 deadlineä edeltävään pe mennessä . Työstä on tehty noin puolet ominaisuuksien ja työmäärän osalta. Esittele työsi ohjaajalle ja varaa sitä varten aika, tai tule ryhmäohjaukseen. Työn pitää olla versiohallinnassa. Jos tämä vaihe on pahasti kesken, tarkastaja palauttaa työn opiskelijalle ja antaa 7 päivää aikaa tehdä korjaukset, jonka jälkeen vaihe tarkastetaan uudelleen.
  • Esittely: 90 % valmis julkiseen esittelytilaisuuteen mennessä, jolloin jokainen esittelee työnsä muille opiskelijoille. Työt esitellään max 15 hengen ryhmissä. Tarkoitus on antaa ja saada palautetta, jotta vielä viimeisiä pikku viilauksia voidaan tehdä ennen työn lopullista hyväksymistä.
  • Vaihe 3: "100%" valmis ja hyväksyttäminen ohjaajalla ennen kurssin ensimmäistä tenttiä. Tämän vaiheessa ohjaaja tarkastaa, että työn muodolliset vaatimukset täyttyvät, ja että opiskelija on tehnyt itse harkkatyönsä kurssin pelisääntöjen mukaisesti. Varaa aika ohjaajalta.

Etäopiskelijoille on Esittely-kohtaan omat ohjeet, tosin syksyllä 2020 kaikki menevät samalla tavalla etänä.

Ymmärränkö oikein, että vaiheen 3 eli ohjaajalle esittelyn voi tehdä ennen kuin tuon julkisen muille esittelyn?

VL: joo, ei tuolla järjestyksellä ole väliä!

20 Nov 18 (edited 21 Oct 20)

Aikataulujoustoista sovittava erikseen ohjaajien kanssa. Perustelluista syistä voidaan tehdä oma aikataulu.

#

7. Harjoitustyön suunnittelu

Ennen harjoitustyön toteuttamista tehdään suunnitelma. Suunnitelma tehdään TIMiin ja kuva(t) laitetaan versiohallintaan, ja suunnitelma hyväksytetään ohjaajalla ennen varsinaisen työn aloittamista. Varaa aika Korpista.

Jos et keksi, minkä tyylisen pelin haluaisit tehdä, katso esimerkkejä, millaisia pelejä Jypelillä voi tehdä.

Suunnittelemattomia harjoitustöitä ei hyväksytä.

Suunnitelmassa pitää olla ainakin seuraavat asiat (soveltaen ei-peliharjoitustyöhön):

  1. Tekijöiden nimet
  2. Pelin nimi
  3. Harjoitustyö osoite gitissä
  4. Pelaajien lukumäärä (1-4)
  5. Pelin taustatarina tai kuvaus pelin teemasta
  6. Pelin idea ja tavoitteet
  7. Hahmotelma pelistä (kuva tai kuvia paperilla käsin tai tietokoneella piirrettynä)
  8. Jonkinlainen kuvaus siitä, miten peli etenee
  9. Pelissä olevat oliot, niiden toiminnot ja missä suhteessa ne ovat toisiinsa
  10. Toteutuksen suunnitelma: mitä tekisin ja missä järjestyksessä? Millä aikataululla?

Myöskään pelimallit-sivulla olevat facebook-linkit eivät toimi (esim. tasohyppelypelien kohdalla).

Jypelin Tracissa olevan pelimallit-sivun sisältö taitaa olla päivitetty 8 vuotta sitten. TIM-sivu jypelin ohjeet on tuotu sieltä, ja päivitys on työn alla. -JuhoK

03 Feb 21 (edited 06 Feb 21)
#

7.1 Muu kuin pelimäinen aihe

Harjoitustyö voi olla myös muu kuin peli.
Yksi esimerkki voisi olla vaikkapa lukea tiedostosta suomenkielinen teksti ja lasketaan mitä vokaalia on eniten. Tai työ voi olla tietyn WWW-sivun lukeminen ja sieltä tiettyjen tietojen käsittely yksinkertaiseen muotoon. Esimerkiksi joltakin sääsivulta päivän tuuliarvojen maksimi ja keskiarvo.

Inspraatiota voi myös hakea Työaikaraportti -tutorialista tai vaikkapa täältä http://nifty.stanford.edu/. Katso tuolta CS1-tasoiset tehtävät, niiden pitäisi (suurelta osin) olla tämän kurssin osaamistavoitteiden mukaisia. Näissäkin tapauksissa suunnitelma tulee kuitenkin hyväksyttää ohjaajalla.

Ei-pelien tapauksessa ohjelmaan tehdyt testattavissa olevat aliohjelmat tulee testata.

Muun kuin peliharjoitustyön tekemiseen on omat itseopiskelututoriaalit.

#

7.2 Vinkkejä harjoitustyön aloitukseen

  • Aloita vaikka pistämällä kentälle jotakin olioita
  • MontaPalloa.cs
  • Jos peli on tasohyppelymäinen, luo uusi projekti kohdasta Jypeli -> Tasohyppely
  • Seuraavassa videossa on esitelty kuinka kuvia käytetään. Sitä ennen (ks sisällön tuominen peliin) on
    1. piirretty/haettu tarvittavat kuvat, muista tekijänoikeus
    2. tehty projektiin Content-niminen kansio ja kopioitu kuvat sinne
    3. hiiren oikealla kutakin juvaa (tai valittu monta) ja Properties ja sieltä valittu "Copy if newer)
#
#
#

8. Kurssin lisäosat

Kurssin lisäosana voi suorittaa itseopiskeluna seuraavat lisäkurssit:

  • ITKP106
    • 1 op - kurssilla tehty peli mobiilipeliksi
    • +1 op - mobiilipeli julkaistu kauppapaikassa
  • ITKP1070
    • 1 op - graafinen käyttöliittymä harjoitustyöhön (ei-peliharjoitustyön tekijöille) tai graafinen käyttöliittymä jonkin pelissä olevan tiedoston käsittelemiseksi (peliharjoitustyön tekijöille)
    • +1 op - em graafinen käyttöliittymä myös puhelimessa toimivaksi
    • +1 op - em. puhelinkäyttöliittymä julkaistu kauppapaikassa

Lue tarkemmat ohjeet kumpaankin kurssin liittyen.

These are the current permissions for this document; please modify if needed. You can always modify these permissions from the manage page.