Harjoitustyö

Harjoitustyö

• on osa kurssisuoritusta ja arvioidaan asteikolla hyväksytty/hylätty. Harjoitustyö pitää olla hyväksytty ennen kuin kurssista voi saada arvosanan.
• 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 27 tuntia työtä. Parityönä tehtävän työn määrä on siis laskennallisesti 54 tuntia. Katso tarkat vaatimukset paritöille alla.
• voi olla Jypeli-työkaluilla tehty peli, mutta voi olla jokin muukin C#-kielellä tehty komentoriviohjelma. Muita kieliä ei hyväksytä.

1. Vaiheet ja aikataulu

Harjoitustyöhön kuuluu kolme vaihetta, jotka on listattu alla.

Harjoitustyön vaiheet palautetaan esittelemällä ne ohjaajalle. Voit esittää harjoitustyösi pääteohjauksissa tai sopimalla erillinen ohjausaika sähköpostitse (ohj1-opet@tim.jyu.fi).

Vaiheet tulee palauttaa valitsemasi opintojaksototeutuksen aikataulun mukaisesti.

2. Vaatimukset

2.1 Suunnitelma

Harjoitustyö täytyy olla suunniteltu ja suunnitelman tulee olla ohjaajan hyväksymä. Suunnitelmat tallennetaan GitLabiin, ks. yläpuolelta vaiheen 1 tarkistuslista.

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

1. Tekijöiden nimet
2. Pelin nimi
3. Harjoitustyön 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

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

2.3 Koodi

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

Muut tarkastettavat osa-alueet on lueteltu alempana kohdassa "Tarkastettavat osa-alueet".

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

2.5 Tarkastettavat osa-alueet

Alla on tarkastettavien osa-alueiden lista, jonka ohjaajat tulevat tarkastamaan harjoitustyön esittelemisen yhteydessä.

1. Nimeäminen on johdonmukaista ja noudattaa 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. Muista asentaa kurssin Rider-asetukset

13. Ei-pelien tapauksessa osoitettu myös taito testata aliohjelmia.

3. Usein kysytyt kysymykset ja muut vinkit