{
"llm" : {
"feedback" : "# Exercise: parking\n\nLlm Evaluation ist für diese Aufgabe deaktiviert. Entferne die .llmignore Datei vom Package der Aufgabe.\n\n\n# Exercise: labyrinth\n\n### Correctness\n- `TryStraightFirst` macht keinen Schritt, nachdem du links/rechts gedreht hast; wenn vorne zu ist, links aber frei ist, drehst du nur und bleibst im selben Feld (in der nächsten Iteration prüfst du dann wieder neu). In der Aufgabenbeschreibung soll in dem Fall (links/rechts) auch wirklich gegangen werden.\n- `TryStraightFirst` implementiert den Fall „Sollte das alles nicht gehen, soll die Figur rechtsum kehrt machen“ nicht. Wenn vorne/links/rechts zu sind, endet deine Schleifeniteration ohne Aktion und du landest in einer Endlosschleife.\n- `BacktrackingAlgorithm` entspricht nicht der geforderten Schnittstelle-Idee: Dein Algorithmus hängt an einem konkreten `Labyrinth`-Objekt (Konstruktor-Parameter + Feld) und nutzt `labyrinth.goalAt(...)`/`labyrinth.rows()`/`cols()`. Laut Aufgabe soll `navigate` nur über das übergebene `Figure`-Objekt funktionieren.\n- In `BacktrackingAlgorithm` beendest du die Rekursion bei Zielerreichung mit `labyrinth.goalAt(row,col)` statt über `figure.isGoalReached()`. Damit umgehst du die vorgesehene Abfrage über das Interface.\n- In `BacktrackingAlgorithm` kann dein „Zurückgehen“ (`turnLeft`/`turnLeft`/`moveForward`/...) in Situationen passieren, in denen der Rückweg in dieser Blickrichtung nicht mehr frei ist (weil deine Orientierung/Position durch andere Rekursionszweige inzwischen anders ist). Dann kann `moveForward()` in eine Wand laufen und ein `GameOver` auslösen.\n- In `LabyrinthApp` erstellst du ein `BacktrackingAlgorithm` mit `new Labyrinth(MAPS[1])`, spielst dann aber alle Levels mit jeweils einem anderen `LabyrinthGame` (und damit einem anderen Labyrinth). Dein Algorithmus verwendet intern trotzdem das eine Labyrinth aus `MAPS[1]`, wodurch Levels und „besucht“-Matrix nicht zum aktuellen Spiel passen.\n\n### Suggestion\n- Überlege bei `TryStraightFirst`: Wenn du dich entscheidest „links“ oder „rechts“ zu versuchen, was muss danach unmittelbar passieren, damit es wirklich ein „Versuch“ ist und nicht nur eine Drehung?\n- Für den „rechtsum kehrt“-Fall: Füge einen `else`-Zweig ein, der genau dann greift, wenn keine der drei Richtungen frei ist, und ändere die Orientierung entsprechend.\n- Für `BacktrackingAlgorithm`: Prüfe, wie du alle Informationen, die du brauchst (Ziel erreicht, freie Wege), ausschließlich über Methoden von `Figure` bekommen kannst, ohne `Labyrinth` direkt zu kennen.\n- Statt `goalAt(row,col)`: Nutze die vorgesehene Zielprüfung über die Figur – so bleibt der Algorithmus unabhängig vom konkreten Labyrinth.\n- Beim Backtracking: Achte darauf, dass „zurückgehen“ immer den exakt umgekehrten Schritt macht (inkl. korrekt wiederhergestellter Richtung), bevor du den nächsten Abzweig ausprobierst. Teste gedanklich: „Bin ich nach dem Zurückgehen garantiert wieder im gleichen Feld und mit gleicher Richtung wie vor dem Schritt?“\n- In `LabyrinthApp`: Der Algorithmus sollte zu jedem Level auf der jeweils aktuellen `Figure` arbeiten. Wenn du eine „besucht“-Struktur brauchst, initialisiere sie so, dass sie zum aktuellen Level passt (nicht zu einem fest verdrahteten anderen Map-Index).\n\n### Code Style\n- In `BacktrackingAlgorithm.navigate` sind große auskommentierte Codeblöcke; besser entfernen, sobald du dich für einen Ansatz entschieden hast.\n- `BacktrackingAlgorithm` hat ein Feld `labyrinth`, das nur dazu dient, am Interface vorbei auf Map/Goal zuzugreifen; das macht die Klasse unnötig gekoppelt und schwer testbar.\n- Mehrfach wiederholte Sequenzen zum „zurücklaufen“ (4 Zeilen) kommen dreimal vor; das schreit nach einer kleinen Hilfsmethode, damit du dich nicht vertippst und Änderungen nur an einer Stelle machen musst.\n- Variablennamen wie `besucht` sind ok, aber `row`/`col` werden einmal als Dimensionen und einmal als aktuelle Position verwendet; unterschiedliche Namen (z.B. `rows/cols` vs. `r/c`) würden Verwechslungen vermeiden.\n\n\n# Exercise: swissmap\n\n### Correctness\n- In `Lake`, `Mountain` (und auch `SwissMap`) verwendest du andere Resource-Pfade als in der Aufgabenstellung/Library erwartet (z. B. `\"swissmap_img/...\"` statt `\"swissmap/...\"`). Wenn diese Bilder im vorgegebenen `resources`-Ordner nicht unter genau diesen Pfaden liegen, werden die Objekte bzw. der Hintergrund nicht angezeigt.\n- In `ModeButton` passt der interaktive Bereich (`getInteractiveArea`) nicht zur gezeichneten Button-Grösse: Du zeichnest ein Rechteck `65x25`, aber der `Rectangle` ist nur `15x15`. Damit ist der Button nur in einer Ecke klick-/hoverbar, was die Anforderung “als Knopf auf der Karte angezeigt” praktisch verletzt.\n- In `City`, `Lake`, `Mountain` sind die Interactive-Areas sehr klein und wirken nicht passend zur Darstellung (z. B. `5x5` bei City). Dadurch ist “mit der Maus auf ein Objekt zeigen” nur schwer/kaum möglich.\n\n### Suggestion\n- Prüfe, welche Bildpfade im Template bereits funktionieren (insbesondere in `SwissMap.draw`) und orientiere dich bei See/Berg an genau diesem Muster/Ordnernamen; vergleiche auch die Struktur im `resources`-Ordner.\n- Leite die Breite/Höhe deines `ModeButton`-Interactive-Areas direkt aus den Werten ab, die du auch in `drawRect(...)` verwendest, damit Hover/Klick exakt auf dem Button funktioniert.\n- Überlege dir pro Objekt (City/Lake/Mountain), welche Bildschirmgrösse dein Marker/Bild wirklich hat, und wähle den `Rectangle` (oder eine passendere `Shape`) so, dass er die sichtbare Fläche gut abdeckt (nicht nur ein winziger Punkt am Koordinatenursprung).\n\n### Code Style\n- Entferne Debug-Ausgaben wie `System.out.println(satelliteMode)` in `SwissMap.draw` und `System.out.println(getInhabitants())` in `City.onMouseEnter`, sonst spammst du die Konsole bei jedem Frame/Hover.\n- In `Mountain` und `SwissMap` sind Imports/Variablen für `ImageIO`, `BufferedImage`, `IOException`, `Objects` unbenutzt – die solltest du löschen.\n- `ModeButton` speichert `hovered` und `clicked`, nutzt sie aber nicht (z. B. um Darstellung zu ändern). Entweder verwenden oder entfernen, damit die Klasse klarer bleibt.\n\n\n# Exercise: visualizer\n\n### Correctness\n- Das `DataPoint`-Interface stellt nicht die Informationen bereit, die der `Visualizer` effektiv braucht: Es fehlen Werte für x- und y-Koordinate (als `double`) sowie Strings für Gruppierung/Legende und die Texte im Hover/Highlight.\n- Die Methoden in `DataPoint` sind als Setter-artige `void`-Methoden definiert (`title(...)`, `information(...)`, ...). Der `Visualizer` benötigt aber Daten *vom* Datenpunkt (also Rückgabewerte), nicht dass der Visualizer Daten *in* den Datenpunkt hineinschreibt.\n- In `Visualizer` wurden die Dummy-Werte (`DUMMY_DOUBLE`, `DUMMY_STRING`) nirgends durch Aufrufe auf das `DataPoint`-Objekt ersetzt; damit funktioniert die Visualisierung weiterhin nicht wie gefordert.\n- `Movie`, `Country` und `Processor` implementieren das `DataPoint`-Interface nicht, dadurch kannst du die Arrays aus `loadMovies/loadCountries/loadProcessors` nicht als `DataPoint[]` an den `Visualizer` übergeben.\n- In `VisualizerApp` wird weiterhin `new DataPoint[0]` verwendet statt einen der Datensätze zu laden und zu visualisieren.\n- Die in der Aufgabe geforderten Zuordnungen (Movies: Budget→x, Rating→y; Countries: Literacy→x, GDP/capita→y; Processors: Jahr+Monat→x, clockRate*cores (log y)→y) sind in deinem Attempt noch nirgends umgesetzt.\n- Die geforderten Javadoc-Kommentare zur Dokumentation des `DataPoint`-Interfaces fehlen.\n\n### Suggestion\n- Schau dir in `Visualizer` jede Stelle mit `DUMMY_DOUBLE`/`DUMMY_STRING` an und leite daraus ab, *welche Art von Information* dort gebraucht wird (z.B. Koordinate, Gruppennamen, Titel, Detailtext). Daraus ergeben sich die Methoden, die dein `DataPoint` anbieten muss.\n- Überlege beim Interface konsequent in “Getter”-Richtung: Der `Visualizer` fragt den Punkt nach x/y/Label/Details ab. Entsprechend sollten die Methoden Werte zurückgeben, statt `void` zu sein.\n- Für die Legende/`colorOfGroup(...)` brauchst du pro Datenpunkt eine Gruppierungs-Information (String oder `null`). Für das Highlight brauchst du einen Titel (eine Zeile) und zusätzlich einen mehrzeiligen Beschreibungstext (wird im Code per `split(\"\\n\")` verarbeitet).\n- Sobald das Interface passt, implementiere es in `Movie` zuerst (damit du schnell testen kannst), und ersetze dann in `VisualizerApp` das leere Array durch den geladenen Film-Datensatz (Typen müssen dabei kompatibel sein).\n- Für Prozessoren: plane im Interface eine Möglichkeit ein, dass der `Visualizer` die y-Werte logarithmisch darstellen kann (oder dass der Datenpunkt bereits den passenden transformierten Wert liefert) – orientiere dich daran, wie du es ohne Änderungen an der GUI-Bibliothek in die bestehende `Visualizer`-Logik einhängen kannst.\n\n### Code Style\n- Die Interface-Methodennamen `title`, `information`, `secondInfo` sind uneinheitlich und unklar; ausserdem sind `secondInfo` und Map-Parameter schwer verständlich ohne Dokumentation. Besser ist eine klar benannte, kleine Anzahl an Methoden mit eindeutigen Rückgabewerten.\n- `import java.util.Map;` in `DataPoint` wirkt aktuell wie ein Design in Richtung “beliebige Daten reinreichen”; für diese Aufgabe ist eine spezifische, klar definierte Schnittstelle typischer und leichter testbar.\n- Es fehlen die verlangten Javadoc-Kommentare am `DataPoint`-Interface und seinen Methoden.\n",
"status" : "SUCCESS"
}
}