{
"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 nach links/rechts: Du drehst nur (`turnLeft/turnRight`), aber wenn vorne frei wird, bewegst du dich erst im nächsten Schleifendurchlauf; gefordert ist in dem Fall „links oder rechts versuchen“ (typischerweise inkl. vorwärts gehen).\n- `TryStraightFirst` macht keine „rechtsum kehrt“, wenn vorne/links/rechts nicht geht; dieser Fall fehlt komplett (damit scheiterst du in Sackgassen).\n- `BacktrackingAlgorithm` ist so nicht kompatibel mit `LabyrinthApp`: Du konstruierst den Algorithmus mit einem separaten `Labyrinth` (`new Labyrinth(MAPS[1])`), aber `game.play(navi)` übergibt dem Algorithmus eine `Figure` aus einem *anderen* Labyrinth/Level. Damit nutzt du in `BacktrackingAlgorithm` (`labyrinth.cols()/rows()/goalAt`) nicht die Map, in der sich die Figur tatsächlich bewegt.\n- `BacktrackingAlgorithm` prüft das Ziel nicht über die Figur (`figure.isGoalReached()`), sondern über `labyrinth.goalAt(row,col)` auf dem „falschen“ Labyrinth-Objekt; selbst wenn die Figur im Spiel das Ziel erreicht, kann deine Rekursion weiterlaufen oder umgekehrt zu früh stoppen.\n- In `BacktrackingAlgorithm` kann das Rückwärtsgehen crashen: Du machst nach einem rekursiven Besuch immer eine feste Sequenz „180° drehen, moveForward, 180° drehen“ ohne zu prüfen, ob hinter dir wirklich ein Pfad ist; wenn deine Orientierung/Position nicht exakt so ist wie erwartet (z.B. durch andere Abzweigungen), kann `moveForward()` in eine Wand laufen und `GameOver` werfen.\n- Der Backtracking-Teil `if(!pathAhead && !left && !right){ turnRight(); turnRight(); checkPath(...) }` dreht nur um und ruft rekursiv auf, bewegt sich aber nicht weg aus dem Feld; da `besucht[row][col]` schon `true` ist, endet der Aufruf sofort und du kommst aus der Sackgasse nicht heraus.\n\n### Suggestion\n- Bei `TryStraightFirst`: Überlege dir pro Schleifendurchlauf eine klare Priorität „vorwärts, sonst links, sonst rechts, sonst umdrehen“ und sorge dafür, dass bei einem erfolgreichen Richtungswechsel in demselben Durchlauf auch wirklich ein Schritt gemacht wird (sonst „probierst“ du nicht wirklich).\n- Für die „rechtsum kehrt“: Es gibt keinen `turnAround()`, aber du kannst dir herleiten, wie viele Drehungen nötig sind, um die Richtung um 180° zu ändern.\n- Für `BacktrackingAlgorithm`: Versuche, den Algorithmus ausschließlich über das `Figure`-Interface zu steuern/prüfen (inkl. Zielprüfung), statt ein eigenes `Labyrinth` im Algorithmus zu halten. Dann funktioniert derselbe Algorithmus automatisch für jedes Level.\n- Beim Backtracking: Wenn du „zurückgehst“, stelle sicher, dass du tatsächlich eine Kante zurückläufst (also eine Bewegung machst) und dass deine Orientierung danach wieder so ist, dass du weitere Alternativen am vorherigen Knoten prüfen kannst.\n- Für das „besucht“-Konzept: Überlege, ob „ein Feld einmal besucht = nie wieder betreten“ bei Labyrinthen mit Verzweigungen wirklich reicht, oder ob du eher Kanten/Entscheidungen tracken musst (oder beim Zurückgehen bewusst wieder Felder betreten darfst).\n- Bevor du beim Rückweg `moveForward()` machst, denke daran, dass du auch beim Rückweg mit `pathAhead()` sicherstellen kannst, dass du nicht aus Versehen in eine Wand läufst.\n\n### Code Style\n- In `BacktrackingAlgorithm.navigate` sind auskommentierte Blöcke und Debug-Reste (z.B. `System.out.println`, große Kommentarbereiche); räum das auf, damit klar bleibt, welche Logik wirklich gilt.\n- `BacktrackingAlgorithm` speichert `Labyrinth labyrinth` als Feld, obwohl das Interface nur eine `Figure` liefert; das koppelt deinen Algorithmus unnötig ans konkrete Labyrinth-Objekt und macht Wiederverwendung schwierig.\n- Benennung: `besucht` ist ok, aber gemischt mit `checkPath` (Englisch/Deutsch gemischt); konsistentere Sprache/Bezeichner würde die Lesbarkeit verbessern.\n- In `checkPath` wiederholt sich der „zurücksetzen“-Block (zweimal links drehen, moveForward, zweimal links drehen) mehrfach; das schreit nach einer kleinen Hilfsmethode, damit du Fehler weniger leicht kopierst.\n\n\n# Exercise: swissmap\n\n### Correctness\n- In `ModeButton` passt der interaktive Bereich (`getInteractiveArea`) nicht zur tatsächlich gezeichneten Button-Grösse: Du zeichnest ein Rechteck mit `65x25`, aber die `Rectangle` ist nur `15x15` gross, dadurch ist der Button nur in einem kleinen Teil klick-/hoverbar.\n- In `Lake` und `Mountain` (und auch in `SwissMap`) verwendest du andere Resource-Pfade (`swissmap_img/...`) als in der Aufgabenstellung/Library-Beispiel (`swissmap/...`). Falls diese Dateien nicht exakt so im `resources`-Ordner vorhanden sind, werden die Bilder nicht angezeigt.\n- Die Skalierung der Icons für `Lake` und `Mountain` ist an die Hintergrundkarte gekoppelt (`WIDTH * scale(gui) / BG_PIXEL_WIDTH`), dadurch werden die Icons sehr wahrscheinlich viel zu gross/anders skaliert als beabsichtigt (die Aufgabe meint typischerweise „kleines Icon an Position“, nicht „Icon in Kartenbreite skalieren“).\n\n### Suggestion\n- Schau dir beim Button an, welche Fläche du wirklich anklicken/hovern willst: Die `Rectangle` aus `getInteractiveArea` sollte dieselben `x/y`-Koordinaten und dieselbe Breite/Höhe abdecken wie das, was du in `draw` als Button zeichnest.\n- Prüfe, wie die Bilder in den bereitgestellten Ressourcen tatsächlich heissen und in welchem Ordner sie liegen. Richte die Strings in `drawImage(...)` genau danach aus (Pfad relativ zum resources root).\n- Überlege dir für Seen/Berge eine eigene (kleine) Icon-Grösse in Pixeln (ggf. abhängig von `scale(gui)`), statt die Hintergrund-Skalierungsformel zu übernehmen. Orientiere dich daran, dass ein Icon „Marker-Grösse“ haben soll und nicht „Karten-Grösse“.\n\n### Code Style\n- Mehrere `System.out.println(...)` in `draw`/Events (`SwissMap.draw`, `City.onMouseEnter`) wirken wie Debug-Ausgaben und sollten in der finalen Version entfernt werden.\n- In `ModeButton` sind `hovered` und `clicked` aktuell ohne Effekt (werden gesetzt, aber nicht zur Darstellung/Logik genutzt) – entweder verwenden oder entfernen.\n- In `Mountain` und `SwissMap` sind Imports und Variablen für `ImageIO/BufferedImage/Objects` vorhanden, aber werden nicht benutzt; das macht den Code unnötig unübersichtlich.\n\n\n# Exercise: visualizer\n\n### Correctness\n- Das `DataPoint`-Interface stellt keine Werte bereit, die der `Visualizer` für die Darstellung zwingend braucht (mindestens x- und y-Koordinate als `double`, sowie Strings für Gruppierung/Legende und Hover-Anzeige). Stattdessen hast du `void`-Methoden definiert, die eher wie “Setter” wirken, womit der Visualizer nichts abfragen kann.\n- In `Visualizer` wurden die Dummy-Werte (`DUMMY_DOUBLE`, `DUMMY_STRING`) nirgends durch Aufrufe auf das jeweilige `DataPoint`-Objekt ersetzt; damit funktioniert die Visualisierung weiterhin nicht wie gefordert.\n- `Movie`, `Country` und `Processor` implementieren das `DataPoint`-Interface nicht, daher sind sie nicht mit dem `Visualizer` integrierbar.\n- In `VisualizerApp` wird weiterhin `new DataPoint[0]` verwendet, statt einen der Datensätze (`loadMovies()`, `loadCountries()`, `loadProcessors()`) zu übergeben; damit wird nichts visualisiert.\n- Die in der Aufgabe geforderten Achsen-Zuordnungen (Movies: Budget vs Rating; Countries: Literacy vs GDP per capita; Processors: Veröffentlichungsmonat vs effektive Geschwindigkeit inkl. log y) sind in deinem Stand noch nicht umgesetzt.\n\n### Suggestion\n- Überlege dir beim Interface: Der `Visualizer` muss Daten *lesen* können (Koordinaten, Gruppenname, Titel, Detailtext) – d. h. Methoden sollten Werte zurückgeben, nicht `void` sein.\n- Suche in `Visualizer` alle Stellen mit `DUMMY_DOUBLE`/`DUMMY_STRING` und frage dich jeweils: “Welche Information gehört hier zum aktuellen `point` bzw. zu `closest`?” und ersetze dann gezielt durch den passenden Interface-Methodenaufruf.\n- Implementiere das Interface schrittweise: zuerst nur für `Movie` (so wie im Aufgabentext beschrieben), dann in `VisualizerApp` nur Movies laden und prüfen, ob Plot + Hover grundsätzlich stimmen, erst danach Countries/Processors ergänzen.\n- Für Prozessoren: du brauchst für x einen kombinierten “Jahr+Monat”-Wert und für y eine berechnete Größe (clockRate * cores). Achte darauf, dass diese Werte als `double` an den Visualizer gehen.\n\n### Code Style\n- Die Methodennamen im Interface (`title`, `information`, `secondInfo`) sind unklar und wirken wie “Kommandos”; üblich wären sprechende “Getter”-Namen (und ohne Seiteneffekte), passend dazu, wie der Visualizer sie verwendet.\n- `information(Map<String, Integer> ...)`/`secondInfo(...)` wirkt sehr technisch und eng (nur `Integer`-Werte möglich); für die Hover-Ansicht brauchst du eher formatierten Text (mehrzeilig) oder klar benannte einzelne Textteile statt generische Maps.\n",
"status" : "SUCCESS"
}
}