{!!!#- {id="Dixsjg7NbllG" .huomautus .hidden-print visible="%%'ohj1s19d11vika'|belongs%%" nocache="true"} **HUOMIO!** [Olen laittanut sinulle sähköpostia otsikolla: Ohj1: täydennä d11 kuntoon tai ota yhteyttä]{.red}. Laitathan kuntoon tai otat yhteyttä! !!!}

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 2020: 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 2020: 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.

Saako netistä ladattuja kuvia käyttää harjoitustyössä? Ajattelin vain varmistaa.

VL: jos ne ovat sellaisia, joihin on oikeus. Satunnaiseen kuvaan ei ole oikeutta.

20 Nov 18 (edited 20 Nov 18)

2. 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 2.1.

Parityöt: 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. Lisäksi kummankin tekijän on pystyttävä esittämään riittävän tarkka tuntikirjanpito ja selvitys mitä työajalla on tehty. 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.

{}
#

2.1 Tarkastettavat osa-alueet

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

  1. Nimeäminen on johdonmukaista ja noudattelee kurssin koodauskäytänteitä. Aliohjelmien ja attribuuttien näkyvyys tulee olla määritelty (public, private).
  2. Toimii: Ohjelma toimii, ei kaadu ja päättyy asiallisesti. Pelissä pitää tapahtua jotakin, eli ohjelmassa pitää tapahtua jotain järkevää, johon käyttäjä voi osallistua interaktiivisesti. Pelissä pitää myös olla tavoite, haaste tai tarina.
  3. Ei turhia peliluokan attribuutteja. Jos jotain koko peliluokkaan näkyviä arvoja tarvitaan, pyritään käyttämään vakioita (const). Esim. kuvien olioviitteet voi kiinnittää muuttumattomaksi static readonly määreellä.
  4. Ei julkisia staattisia (public static) muuttujia. Jokaiselle attribuutille, vakiolle ja aliohjelmalle on määriteltävä näkyvyys (public, protected, private).
  5. Ei toistoa, joka olisi voitu tehdä silmukoilla tai aliohjelmilla. Myöskään aliohjelmien välillä ei saa olla toistoa (esimerkiksi LuoVihu1, LuoVihu2).
  6. Taulukko: Käytetään taulukkoa tai listaa. Tietorakenteella täytyy olla jokin tarkoitus siten, että sinne tallennetaan tosiasiallisesti useita arvoja, joita todella käytetään pelissä. Edelleenn, tietorakenteen käytön tulee parantaa koodin laatua, selkeyttää tai helpottaa koodin lukemista 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 tosiasiallisesti 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, helpottaa lukemista, kirjoittamista tai koodin 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. Suomennettuna: et siis saa tehdä koodia esim: (y < 18) jossa 18 on hyvin todennäköisesti turha literaali, sen tilalle tulee laittaa muuttuja tai vakio. Vakiot tulee ilmaista const-määreellä.
  9. } + 2 tyhjää: Aliohjelmien loppusulun } jälkeen tasan kaksi tyhjää riviä
  10. Dokumentaatio: Luokkien, aliohjelmien ja metodien tulee olla dokumentoituja. Dokumenteissa kuvataan sitä, mitä aliohjelmat tekevät. Luokan alussa tulee olla tekijän nimi ja versio (@author, @version)
  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)

Voisiko myös taulukon käyttöä tässä tarkoituksessa täsmentää tai antaa jotain esimerkkejä?

21 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
{}
#

3. Miten peliin taulukko, silmukka ja funktio?

Lähde pohtimaan asiaa siitä suunnasta että mitä tietoa pelissä voisi kerätä ja käsitellä. Jos lähdet alusta asti suunnittelemaan peliäsi pelidatan keräämisen näkökulmasta (ts. mikä pelidata olisi kiinnostavaa), niin sitten tätä dataa on ehkä luontevampi myös käsitellä.

Esimerkkejä: taulukkoon tai listaan voi kerätä tietoa

  • pelaajan liikkeistä (mitä painiketta on painanut),
  • kerätyistä tavaroista,
  • törmäyksistä objekteihin,
  • tai jostakin muista pelitilanteista.

Tieto voi olla aikaleimoja, etäisyyksiä, törmäysten kohteina olevien objektien “tägejä”, tms. Kun peli on päättynyt (tai kenttä vaihtuu, peli alkaa alusta, tms.) niin voidaan ottaa tämä tietojoukko, käsitellä se jollakin tavalla (esim. hakea keskiarvo, pienin, suurin, kuljettu matka, eniten tägättyjä objekteja, kaksinpelissä laskea vaikkapa pallon hallinta-aikaa jne.) ja hyödyntää tätä käsiteltyä tietoa pelissä. Yksinkertaisin tapa on tietysti näyttää laskettu tieto/tiedot käyttäjälle, mutta parhaassa tapauksessa tietoa voisi hyödyntää jollakin muullakin tavalla joka tuo peliin aidosti lisää sisältöä.

{}

Mikäli omassa pelissä ei ole taulukkoa/listaa tai silmukkaa, 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/2020s/demot/demo7?answerNumber=1&task=matriisiensumma&user=vesal

Linkin saa otettua demotehtävän vierellä olevasta pienestä Link-linkistä.

4. Versiohallinta

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

5. Vaiheistus

Harjoitustyön vaiheet
Harjoitustyön vaiheet

5.1 Aikataulut

Mitä jos harjoitustyön ensimmäinen varsinainen esittely (ei suunnitelman esittely) on jäänyt tekemättä ja deadline on mennyt?
VL: sitten äkkiä ohjaajiin yhteyttä ja näyttämään…

15 Nov 19 (edited 15 Nov 19)
{}

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ä . Esittele työsi ohjaajalle ja varaa sitä varten aika (toissijaisesti ohjauksissa = ohjaaja katsoo jos ei ole ryhmäohjauksissa neuvottavien kanssa kiirettä. Tällöin on turha pitää Kiire-kylttiä esillä.). Työn pitää olla versiohallinnassa.
  • 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ä. HUOM. Tarkista pelisi toimivuus eri näyttöresoluutioilla ennen esittelytilaisuutta.
  • 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 tai tule ohjauksiin.

Etäopiskelijoille on Esittely-kohtaan omat ohjeet.

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 20 Nov 18)

Miten harkkatyön hyväksyttäminen etänä onnistuu käytännössä?

30 Jan 19

Kohdan 3.1 lopussa on linkki etäopiskelijoiden ohjeisiin. -AJL

30 Jan 19

Milloin siis on tuo julkinen esittelytilaisuus, jolloin pitää olla 90% pelistä valmis?

09 Mar 20

Milloin siis on tuo julkinen esittelytilaisuus, jolloin pitää olla 90% pelistä valmis?

19 Mar 20

Katso luennon 20 viimeiset n. 5min. Ei ole vielä lyöty lukkoon, mutta huhtikuun alkupuolella kuulemma deadline.

20 Mar 20 (edited 20 Mar 20)
{!!!Jokainen aikaraja, josta opiskelija myöhästyy ennakkoon ilmoittamatta (ja ilman hyvää syytä, kuten sairastuminen), aiheuttaa puolen numeron tiputuksen kurssin kokonaisarvosanaan jokaiselta alkavalta myöhästymisviikolta. Lisäksi opiskelija, joka ei ole (ilman hyvää syytä) palauttanut versionhallintaan vähintään lähes esittelykelpoista harjoitustyötään ennen tenttiä, saa automaattisesti hylätyn arvosanan kurssista. !!!} {!!! Mikäli opiskelija myöhästyy yllä kuvatusta vaiheistuksesta sen takia että esittely- tai ohjausaikoja ei ole tarjolla, niin siitä ei rangaista opiskelijaa. !!!}
{}
{}
#

6. 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. Pelaajien lukumäärä (1-4)
  4. Pelin taustatarina tai kuvaus pelin teemasta
  5. Pelin idea ja tavoitteet
  6. Hahmotelma pelistä (kuva tai kuvia paperilla käsin tai tietokoneella piirrettynä)
  7. Jonkinlainen kuvaus siitä, miten peli etenee
  8. Pelissä olevat oliot, niiden toiminnot ja missä suhteessa ne ovat toisiinsa
  9. Toteutuksen suunnitelma: mitä tekisin ja missä järjestyksessä? Millä aikataululla?
{}
#

6.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.

#

6.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
{}
#
#
#

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