Harjoitustyö

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: Erityisen ansiokkaasta harjoitustyöstä voi saada korotuksen arvosanaan. Jos olet sitä mieltä että olet korotuksen ansainnut, kysy siitä ohjaajalta tai ole tarvittaessa 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. Kolmen hengen ja sitä isompia ryhmiä ei hyväksytä.
• sisältää keskimääräisesti opiskelijaa kohti noin 30 tuntia työtä (ks. Sisu -> Toteutuksen tiedot -> Kuvaukset -> Työmäärä). Parityönä tehtävän työn määrä on siis laskennallisesti 60 tuntia. Tarkemmat vaatimukset paritöille ovat alla.
• voi olla Jypeli-työkaluilla tehty peli, mutta voi olla jokin muukin C#-kielellä tehty komentoriviohjelma. Muita kieliä tai työkaluja ei hyväksytä.

2. Vaiheistus

Tarkat aikataulut kurssin kotisivulla

3. Aikataulu

Harjoitustyö palautetaan vaiheittain. Tarkemmat toteutuskohtaiset ohjeet näet alta.

Mahdollisista aikataulujoustoista (esim. sairauden takia) on aina sovittava ohjaajan kanssa.

4. Vaatimukset

4.1 Suunnitelma

Harjoitustyö täytyy olla suunniteltu ja suunnitelman tulee olla ohjaajan hyväksymä. Katso yllä kohdasta 3, miten omalla opintojaksototeutuksellasi hyväksyminen tapahtuu käytännössä.

Kevään toteutuksilla suunnitelmat tallennetaan GitLabiin, ks. yläpuolelta kohta 3 Aikataulu -> Kevään toteutus.

Syksyn toteutuksilla suunnitelmat tallennetaan TIMiin, ks. yläpuolelta kohta 3 Aikataulu -> Syksyn toteutus.

Kesän toteutuksilla suunnitelmat tallennetaan TIMiin, ks. yläpuolelta kohta 3 Aikataulu -> Kesän toteutus.

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?

Voit katsoa vinkkejä seuraavista esimerkkisuunitelmista:

• Hirsipuu (peli)
• AngryLego (peli)
• Työaikaraportti (ei-peli), katso myös tutoriaali työaikaraporttiin

4.2 Toiminnallisuus

Pelissä pitää tapahtua jotakin, eli ruudulla pitää tapahtua jotain järkevää. Käyttäjän tulee voida osallistua peliin interaktiivisesti esimerkiksi hiiren ja/tai näppäimistön välityksellä.

4.3 Koodi

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

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

4.4 Paritöistä

Kaikki ryhmäläiset käyttävät samaa etävaraston osoitetta. Ks. Git-ohjeet.

Työskentely samanaikaisesti: Jos työtä halutaan työstää yhtä aikaa samassa editorissa, helpoin tapa on käyttää Riderin Code With Me -ominaisuutta. Ominaisuus on Riderissa betakokeilussa. Valitettavasti non-commercial-lisenssillä (oletus tällä kurssilla) session enimmäisaika on 30 minuuttia. Jos anot opiskelijalisenssiä, saat (ilmeisesti) rajattoman käyttöajan.

Parityöt, työnjako: Molempien on annettava kutakuinkin yhtäläinen panos työn ohjelmalliseen toteutukseen. Yksittäisenä varoittavana esimerkkinä mainittakoon parityö, 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.

4.5 Tarkastettavat osa-alueet

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

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 jotakin 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). Myös 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 virheitä eikä varoituksia Riderin oikeassa yläkulmassa.
    • kannattaa hakea ensin Vesan asetukset
13. Ei-pelien tapauksessa osoitettu myös taito testata aliohjelmia.

5. Taulukko + silmukka + funktio – miten saat ne peliisi?

Miksi?

Kun tallennat pelin olioita tai tapahtumia listaan / taulukkoon, voit käsitellä niitä yhdellä silmukalla ja paketoida logiikan omaan funktioon. Näin syntyy sekä selkeää että tehokasta koodia.

Mitä pelidataa kannattaa kerätä? Tässä esimerkkejä.

• Pelaajan syötteet: painetut näppäimet, kosketukset
• Pelimaailman tila: viholliset, kerättävät, esteet
• Tapahtumat: törmäysten tagit, pistemäärät, aikaleimat, ratakierrokset

Tallenna tiedot listaan sitä mukaa kun ne (olio, tapahtuma...) syntyvät.

Millainen funktio voisi olla? Tässä esimerkkejä. Huomaa, että nämä ovat enemmän ideoita siitä, millaiset funktiot voisivat olla pelissä hyödyllisiä.

• Laske aikojen keskiarvo
• Etsi minimi, maksimi tai eniten kerätty esine
• Yhdistele dataa (esim. kaksinpelissä pallon hallinta-aika)
• Erityisesti ei-peleissä jokin muu tiedonkäsittely, johon liittyy sisään menevä aineisto ja siitä tehty laskennallinen tulos

Pidä laskentalogiikka omassa funktiossa, jotta peliluokka pysyy selkeänä.

Milloin dataa käsitellään? Tässä esimerkkejä.

• Kenttä vaihtuu
• Aikaraja ylittyy
• Peli alkaa alusta

Hyödynnä tulokset pelissä Tässä esimerkkejä.

• Näytä pelaajalle (pisteet, tilastot, top-ajat)
• Käynnistä uusi vaikeustaso, jos keskimääräinen kierrosaika laskee
• Palkitse pelaaja, kun kerättyjen esineiden määrä ylittää rajan

🐦‍⬛ Jypelin kirjaston ohjeissa on koodiesimerkkejä, joissa käytetään silmukkaa tai taulukkoa. Nämä eivät sellaisenaan riitä, vaan työssä tulee olla oman ajatustyön tulos.

Mikäli omassa pelissä ei ole taulukkoa/listaa, silmukkaa tai funktiota, pitää ohjaajalle esittää itse tehdyn (ts. työ on tehty omatoimisesti ilman merkittävää apua ohjaajalta tai muilta opiskelijoilta) 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/v/2025/kesa/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.

6. Harjoitustyön aiheesta

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

Muista että voit tehdä muutakin kuin pelin!

6.1 Muu kuin pelimäinen aihe

Vaihtoehtoja ovat esimerkiksi:

• Janat-haaste
• työaikaraportti
• Tuulet netistä

Muita vaihtoehtoja:

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

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
• 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. klikattu hiiren oikealla kutakin kuvaa (tai valittu monta) ja Properties ja sieltä valittu "Copy if newer"

• LumiukkoTaulukolla.cs
• Pong-peli
• Läpsylintu
• AngryLego.cs

• ei-pelin tekijöille:
  • Työaikaraportit
  • Kuvaaja.cs
  • HaeTuulet versiohistoria

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.