~~NOTOC~~
{{ prog:images:banner_monopoly.jpg |}}

====== Fra OOA til Implementering (Del 2) ======

===== Baggrund =====
I del 1 af denne opgave arbejdede du med **objektorienteret analyse og design (OOA/D)** af et spil.  
Du udviklede et **UML-klassediagram** og beskrev, hvordan spillet kunne struktureres i klasser, objekter og relationer.

I denne del (Del 2) skal du **implementere dit spil i Processing**, med udgangspunkt i din analyse og dit UML-diagram.

----

===== Formål =====
Formålet med denne opgave er at:
  * Overføre din **OOA og UML** til et konkret program i **C#** / **Processing**
  * Arbejde **objektorienteret** i praksis (klasser, objekter, relationer)
  * **Inddrage mindst ét eksternt bibliotek** til at udvide spillets funktionalitet
  * Dokumentere og **reflektere over din implementering** og dine designvalg

----

===== Tidsramme =====
Du har ca. **10–12 lektioner** til at gennemføre denne del af projektet.  
Spillet skal derfor være **afgrænset i kompleksitet**, men stadig vise forståelse for OOP og spilstruktur.
(obs: du kan blive nødt til at afgrænse funktionaliteten, for at nå i mål)

----

===== Opgavebeskrivelse =====
Ud fra din eksisterende OOA (fra del 1) skal du:

  * Implementere et spil i **Processing**
  * Bruge din **UML-model** som udgangspunkt for kodestrukturen
  * Inddrage **mindst ét eksternt bibliotek**
  * Dokumentere dine designvalg og eventuelle ændringer i forhold til UML-analysen

----

===== Krav til projektet =====

==== 1. Objektorienteret struktur ====
  * Programmet skal bestå af **flere klasser** (min. 3–4)  
  * Hver klasse skal have et klart **ansvar** (f.eks. styring, objekt, spiller, fjende, UI)  
  * Klassenes **samarbejde** skal afspejle din analyse (UML fra del 1)

==== 2. Funktionalitet ====
  * Spillet skal være **interaktivt** (brugeren skal kunne påvirke spillet)
  * Der skal være **spil-logik** (f.eks. regler, point, tab/vind, bevægelse, kollisioner)
  * Der skal anvendes **mindst ét eksternt bibliotek**, fx:
    * **ControlP5** – GUI (knapper, sliders, inputfelter)
    * **Toxiclibs** – fysik og partikeleffekter
    * **Video** – brug af kamera eller videoinput
    * TouchOSC
    * Tramontana

==== 3. Dokumentation ====
  * Indsæt din **problemformulering** (teknisk og kort)
  * Medtag dit **UML-diagram** (evt. opdateret fra del 1)
  * Beskriv kort:
    * Hvilke ændringer du lavede fra din oprindelige plan
    * Hvordan du har arbejdet objektorienteret i praksis
    * Hvordan biblioteket blev anvendt

----

===== Gruppearbejde =====
**I skal arbejde i grupper af to til tre personer**.  

  * UML og problemformulering laves fælles
  * Koden opdeles, så hver elev har sit eget ansvarsområde (f.eks. en klasse eller subsystem)
  * Det skal fremgå tydeligt, hvem der har implementeret hvad  

----


===== Evaluering (vejledende kriterier) =====

^ Kategori ^ Fokus ^
| **OOA → Kode** | I hvor høj grad afspejler implementeringen UML-designet fra del 1? |
| **Kodekvalitet** | Er koden opdelt i meningsfulde klasser med tydelig ansvarsfordeling? |
| **Brug af bibliotek** | Udnytter spillet biblioteket på en relevant måde? |
| **Funktionalitet og spiloplevelse** | Er spillet interaktivt, stabilt. (sjovt/underholdende at bruge?) |
| **Dokumentation & refleksion** | Er ændringer, valg og læring beskrevet og begrundet? |

----

===== Aflevering =====
Afleveringen skal indeholde:
  * Koden til spillet 
    * Metode 1: (Processing-projektmappe zippes til én fil og uploades) Højreclick -> Send to -> Zip
    * Metode 2: Link til det __specifikke Git commit__ sættes ind i rapport.
  * Et dokument med:
    * Problemformulering
    * UML-diagram (det originale, samt det opdaterede)
    * Designbeskrivelse (OOA) og refleksion

----