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

Harjoitustyön vaiheet
Harjoitustyön vaiheet

Tarkat aikataulut kurssin kotisivulla

# aikataulut

3. Aikataulu

Harjoitustyö palautetaan neljässä vaiheessa. Tarkemmat toteutuskohtaiset ohjeet näet alta.

Kevään toteutus

Syksyn toteutus

Kesän toteutus (2023)

Avoimen yliopiston toteutus

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

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?

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.

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.

# htosat

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). 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.
  13. Ei-pelien tapauksessa osoitettu myös taito testata aliohjelmia.
# taulukko-silmukka-funktio

5. 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ää 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/2024k/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.

# suunnittelu

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!

# muukuinpeli

6.1 Muu kuin pelimäinen aihe

Vaihtoehtoja ovat esimerkiksi:

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.

# vinkkeja

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"
# Plugin2
# Plugin1
# lisaht

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.