Skip to content
Snippets Groups Projects
Name Last commit Last update
README.md

Semesteroppgave 2 vår 2024

I denne oppgaven skal du lage din helt egen applikasjon!

Du kan velge mellom tre oppgaver (alle gir like mange poeng):

❗ Du skal jobbe ut i fra ett av de repoene du finner i assignments-mappen. IKKE FORK REPOET!!!!!!!!!

Krav

Uansett hva du velger, har vi satt opp noen krav alle må forholde seg til:

  • Du skriver programmet i Java

  • Applikasjonen må være visuell:

    • Når programmet kjøres skal en GUI (Graphical User Interface) komme opp. Det er ikke nok å kun bruke konsollen.
    • Applikasjonen må være laget med Swing (altså samme rammeverk vi har benyttet så langt i kurset, blant annet i Tetris). Du har muligheten til å bruke andre rammeverk for visning ved forespørsel og godkjenning.
    • Det er tillatt med applikasjoner som hovedsakelig er algoritmiske eller utfører beregninger, men applikasjonen må likevel ha et visuelt grensesnitt mot brukeren.
  • Applikasjonen må være interaktiv:

    • En bruker skal kunne klikke med musen eller bruke tastaturet for å interagere med applikasjonen.
  • Applikasjonen må ha en viss kompleksitet:

    • Applikasjonen må ha et visst omfang. Snake er en applikasjon med nok funksjonalitet, mens dette er ikke nok. Vi viser eksempler for hva som er tilstrekkelig kompleksitet senere i oppgaveteksten, på forelesningen 03.04.24 og i Discord-kanalen #ideér
    • Vi forventer at applikasjonen er oppdelt i ulike klasser som representerer ulike elementer av programmet.

❗ Vi forventer at du legger ned minst 25 timer i å lage programmet, men mange vil nok oppleve at de bruker mer tid enn dette og at det kan variere fra oppgave til oppgave.

De forskjellige oppgavene

Tetris

Hvis du ønsker å lage en applikasjon som er basert på tastetrykk, en timer som styrer endringer i programmet og figurer som flyttes rundt i et grid, kan det være en idé å ta utgangspunkt i Tetris.

Noen forslag til applikasjoner du kan lage er:

  • Pacman
  • Labyrintspill
  • Tower defense
  • Space invader

Othello, Tic Tac Toe, Connect Four og Blob Wars

Hvis du ønsker å lage en applikasjon som er basert på å trykke på skjermen, brikker som flytter seg på et spillbrett og logikk rundt dette, kan det være en ide å ta utgangspunkt i Othello, Tic Tac Toe, Connect Four og Blob Wars.

Du får utlevert et komplett rammeverk som støtter de fire nevnte spillene (løsningsforslag sem2 2022), og står fritt til å benytte koden til å lage din egen applikasjon.

Noen forslag til applikasjoner du kan lage er:

Det vil ikke være nok å bare utvide ett av de eksisterende spillene, som for eksempel å lage Connect Five eller lignende. Applikasjonen din må være noe annet enn de fire spillene som alt er implementerte, men utover dette kan du benytte deg av så mye eller lite eksisterende kode i prosjektet ditt som du ønsker.

Start fra scratch

Dersom applikasjonen du ønsker å lage ikke passer inn i noen av de eksisterende rammeverkene, eller du ønsker en større utfordring, kan det være en ide å ta utgangspunkt i et tomt repo (Empty).

Du får utlevert et tomt prosjekt som er klart til å fylles med hva enn du måtte ønske!

Prosjekter som kan være aktuelle her er for eksempel:

  • Spill som ikke er basert på grid, f.eks. RPGs eller platformspill
  • Applikasjoner som ikke er spill, f.eks. databasesystem, planleggingsapplikasjon, såpedesigner eller musikk-editor

Vær bevisst på at det vil være vanskeligere å få hjelp med prosjektet ditt hvis gruppeleder ikke har noe å forholde seg til på forhånd. Åpen oppgave passer godt for de som føler seg noenlunde stødige i emnet, og som har en god ide om hva de ønsker å lage.

Obligatorisk oppfølging

I løpet av denne oppgaven må du møte på gruppetime i uke 15. 16 og 18/19, hvor en av gruppelederne dine registrerer hvor langt du har kommet med prosjektet. Dette er for å forsikre at alle studenter er på rett vei, og for å forhindre at noen tar på seg for mye arbeid med prosjektet sitt.

Det er ditt ansvar å møte på gruppetime. Hvis du er syk skal du kontakte din gruppeleder og informere om dette. Gruppeleder vil ikke purre på deg. Hvis du ikke møter til gruppetime eller kommuniserer med gruppelederen din, vil dette føre til at du får stryk på oppgaven, og du mister muligheten til å ta eksamen i emnet.

Sørg for å orientere deg om hvem din gruppeleder er og hvordan du kan kontakte dem. Informasjon om dette skal gis på første gruppetime.

Meld dere opp til grupper på MittUiB. Det er denne gruppen du må stille på for å få godkjent underveis og vurdering til slutt.

Møte 1 - Oppstart

I uke 15 (08. - 12. april) møter du til oppstartsmøte. Her må du ha gjort de følgende punktene:

  • En idé for programmet. Hva skal programmet ditt være og hvilken funksjonalitet skal det ha?
  • Valg av kodebase (Tetris, Othello/BlobWars/Connect4/TicTacToe, fra scratch)
  • En plan/oversikt av viktigste klassene. Skriv opp hva de viktigste klassene for programmet ditt vil være og si hvilke variabler/metoder de burde inneholde

Ønsker du eksempler på disse kravene så kan du se på forelesningsopptaket fra 03.04.24 på MittUiB.

Stiller du uten å ha gjort dette arbeidet så stryker du oppgaven og dermed emnet.

Møte 2 - Progresjon

I uke 16 (15. - 19. april) møter du til progresjonsmøte. Her må du ha gjort de følgende punktene:

  • Et kjørbart program som viser frem deler av funksjonalitet. Du må kunne kjøre programmet slik at en GUI kommer opp. Her skal noe av den endelige funksjonaliteten vises.
  • 5 tester ferdiglaget. Du må ha testet koden din så langt. Du kan ikke vise frem tester som var i repoet fra før av.

Ønsker du eksempler på disse kravene så kan du se på forelesningsopptaket fra 03.04.24 på MittUiB.

Stiller du uten å ha gjort dette arbeidet så stryker du oppgaven og dermed emnet.

Møte 3 - Vurdering

I uke 16 og 19 (etter fristen) møter du til vurderingsmøte. Her vil gruppelederen din vurdere oppgaven din. Her skal du:

  • Kjør programmet og hvis funksjonalitet
  • Forklar viktigste delene av koden
  • Kjør testene og forklar de viktigste Gruppelederen kommer til å spørre deg spørsmål om koden din som du må kunne besvare for å få poeng.

Poengberegning

Dere vil få tildelt poeng basert på de følgende punktene:

  • Funksjonalitet (3 poeng)

    • Er programmet visuellt og interaktivt?
    • Har du tilstrekkelig kompleksitet? Fungerer ting som de skal?
  • OOP-konsepter (3 poeng)

    • Benytter du deg av de konseptene vi har lært i emnet? Objekter, grensesnitt, enkapsulering, ploymorfisme, iterator, generics, etc.
  • Kodestil (3 poeng)

    • Er koden din lett og lese? Har du fornuftige hjelpemetoder?
  • Dokumentasjon (3 poeng)

    • Har du gode variabelnavn og javadocs som dokumenterer public og protected metoder?
  • Testing (3 poeng)

    • Tester du public/protected metoder? Tester du for hjørnetilfeller?
  • Video (1 poeng)

    • Lag en video hvor du filmer skjermen og viser frem funksjonaliteten av applikasjonen din. Last opp på Youtube (privat om du ønsker) og legg til en lenke til videoen i README.md.

Hva er "tilstrekkelig kompleksitet"?

Eksempler på programmer som er innenfor kravet til kompleksitet når de kommer i sin enkleste form:

  • Hangman med en ordentlig figur og sikkelig ordbok
  • Snake
  • Tron Light Cycles for to spillere (se også video av orginalen fra 1982).
  • Pong med poeng og to spillere

Du finner flere eksempler i forelesningen 03.04.24 og på Discord-kanalen #ideér.

Eksempler på programmer som er utenfor kravet til kompleksitet når de kommer i sin aller enkleste form:

  • Sprettende ball i vinduet som kan flyttes med museklikk eller piltaster.
  • Klikk på en prikk som periodisk dukker opp for å samle poeng.
  • Figur som beveger seg i labyrint, men uten noen tilhørende historie.

Med andre ord, applikasjonen må være noe mer enn bare et enkelt eksempel på en funksjonalitet -- det må ha en helhet, en historie, eller en rikhet ved seg.

Hvis du er usikker, ta en prat med din gruppeleder eller spør på Discord-kanalen #ideér.

Arbeid i par

I utgangspunktet er oppgaven individuell, men dersom dere er to personer med sterkt ønske å samarbeide som et par, tillater vi dette. Du bør i så fall samarbeide men en partner du kan jobbe med slik at begge parter har faglig utbytte av samarbeidet uten at utviklingen av applikasjonen blir skjevfordelt. Rammene for et slikt samarbeid:

  • Dere må begge gå på samme gruppetime og møter gruppeleder sammen.
  • Dere må begge skrive all koden selv (altså i to kopier, én kopi hver) uten å kopiere maskinelt mellom kodene.
  • Dere må levere inn koden individuelt.
  • Vurdering av oppgaven gjøres individuelt.

Du må kunne forklare alt av koden ved vurdering. Hvis du da har bare kopiert fra noen andre og ikke skjønner hvordan koden fungerer så vil du ikke motta noen poeng.

Det er ikke tillatt å samarbeide i større grupper. Dersom dere ønsker å arbeide i par, gi beskjed om dette til deres gruppeledere, så vil dere bli flyttet til samme gruppe dersom dere ikke allerede er det.

Øvrig samarbeid

Det er alltid tillatt å be om hjelp av og gi hjelp til noen som ikke lager det samme som deg selv.

Plagiat og ressurser på internett

Det er kjempeviktig å tydelig markere og kreditere all kode du ikke har skrevet selv. Å glemme å sitere opphavet til kopiert kode er plagiat, og vil ha alvorlige konsekvenser, jamfør universitetets policy om juks.

  • Dersom du har kopiert en metode, skriv en kommentar om opphavet i begynnelsen av metoden.
  • Dersom du har kopiert en hel klasse, skriv øverst i filen hvor klassen kommer fra.

Når dere siterer, skriv hvor dere har koden fra, hvem som er opphaver og når koden ble hentet. F.eks.:

// Hentet fra: https://www.youtube.com/watch?v=lw3Vz6WsomM
// Opphaver: Sondre Sæther Bolland. Hentet: 05.04.24
public void foo()  {
    System.out.println("kake");
}

Du kan benytte kode du ikke har skrevet selv så mye du ønsker. Den delen av koden som er kopiert vil imidlertid ikke inngå som en del av vurderingsgrunnlaget med mindre den er vesentlig omarbeidet for å passe med sin nye kontekst.

Begge overnevnte punkter gjelder også kode som er skrevet ved å følge detaljerte tutorials.

Du har lov til å bruke kode fra laboppgavene og semesteroppgaven. Kode som du selv har skrevet her trenger du ikke å sitere, men om du bruker noe av den utleverte koden uten vesentlige endringer så må du sitere.

Benytt gjerne kunstig intelligens. AI-verktøy som CoPilot, Ghostwriter og ChatGPT er tillatt. Dersom du kopierer et større avsnitt eller en klasse fra ChatGPT, skriv en kommentar om dette.

Uansett opphav er det er forventet at du kan forklare all koden i ditt eget repositorie.