{
"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- In `TryStraightFirst` fehlt der geforderte Fall „wenn weder vorne noch links noch rechts geht: rechtsum kehrt machen“; aktuell drehst du in diesem Fall gar nicht, wodurch die Figur stecken bleiben kann (Endlosschleife).\n- `BacktrackingAlgorithm` entspricht nicht der erwarteten Nutzung des Interfaces: `navigate(Figure figure)` bekommt nur die `Figure`, du koppelst den Algorithmus aber an ein konkretes `Labyrinth`-Objekt (Konstruktorparameter + Verwendung von `labyrinth.goalAt(...)`, `labyrinth.rows()`, `labyrinth.cols()`). Damit passt der Algorithmus nicht allgemein zu dem `Figure`, das vom `LabyrinthGame` übergeben wird.\n- In `LabyrinthApp` erzeugst du ein eigenes `Labyrinth l = new Labyrinth(MAPS[1]);` für den Algorithmus, aber gespielt wird jedes Level mit einem *anderen* `LabyrinthGame` (und somit anderer `Figure`). Dadurch arbeitet `BacktrackingAlgorithm` intern mit einem anderen Labyrinth als der Figur, die er steuert.\n- `BacktrackingAlgorithm.checkPath`: Beim „Sackgassen“-Fall drehst du um und rufst rekursiv `checkPath` auf, aber du gehst dabei keinen Schritt zurück (kein `moveForward()` nach dem Umdrehen). Das verhindert echtes Backtracking (Positionsänderung zurück zum Vorgängerfeld).\n- In `checkPath` markierst du Felder als besucht und brichst bei `besucht[row][col]` sofort ab. Dadurch kann es passieren, dass du an einem Knoten mit mehreren Abzweigungen nach dem Zurückkommen nicht mehr alle Alternativen erkundest (weil der Knoten schon „besucht“ ist), obwohl du eigentlich noch Richtungen probieren müsstest.\n- `BacktrackingAlgorithm` beendet die Suche über `labyrinth.goalAt(row,col)` statt über `figure.isGoalReached()`. Damit ignorierst du die vorgesehene Ziel-Abfrage der Figur/Engine und bindest dich wieder an das falsche Labyrinth-Objekt.\n\n### Suggestion\n- Für `TryStraightFirst`: Überlege, was in deiner `while`-Schleife passieren muss, wenn **alle drei** `path...()`-Checks false sind, damit die Figur nicht im gleichen Zustand hängen bleibt.\n- Für `BacktrackingAlgorithm`: Versuche den Algorithmus so zu bauen, dass er **nur** über das `Figure`-Interface funktioniert (Bewegung + `path...()` + `isGoalReached()`), ohne Zugriff auf `Labyrinth`-Methoden wie `rows/cols/goalAt`.\n- Für das „richtige“ Backtracking: Achte darauf, dass du nach einem rekursiven Erkunden einer Richtung **physisch wieder zurück** auf das vorherige Feld kommst, bevor du die nächste Alternative ausprobierst (nicht nur drehen).\n- Beim „besucht“-Konzept: Überlege, ob „ein Feld wurde irgendwann besucht“ wirklich das richtige Kriterium ist, oder ob du eher vermeiden willst, **die gleiche Kante/Richtung** mehrfach zu laufen bzw. ob du erst „fertig“ bist, wenn du von einem Feld aus alle möglichen Ausgänge geprüft hast.\n- Damit dein Algorithmus pro Level korrekt läuft: Stelle sicher, dass der `NaviAlgorithm` keine Level-spezifischen Objekte cached, sondern mit der jeweils übergebenen `Figure` arbeitet (oder ggf. pro `play(...)` neu erzeugt wird).\n\n### Code Style\n- In `BacktrackingAlgorithm.navigate` sind auskommentierte Codeblöcke und Debug-Prints (`System.out.println`) drin; das macht die Abgabe schwer lesbar – besser entfernen, wenn du dich für den rekursiven Ansatz entschieden hast.\n- `BacktrackingAlgorithm` speichert `labyrinth` als Feld, obwohl `navigate` bereits alles Nötige bekommen sollte; das erhöht Kopplung und erschwert Tests/Wiederverwendung.\n- Benennung: `besucht` ist ok, aber `checkPath` beschreibt nicht klar, dass es eine rekursive Suche ist; ein Name, der die Strategie ausdrückt (z.B. „search/dfs/backtrack“), wäre lesbarer.\n- Wiederholter Code für „zurücklaufen“ (mehrfach `turnLeft(); turnLeft(); moveForward(); ...`) kommt dreimal vor; das schreit nach einer kleinen Hilfsmethode, um Duplikation zu reduzieren.\n\n\n# Exercise: swissmap\n\n### Correctness\n- Deine Ressourcen-Pfade für die Hintergrundkarte weichen von der Aufgaben-/Vorlage-Struktur ab (`swissmap_img/...` statt `swissmap/...`); wenn diese Dateien im Projekt nicht genau so vorhanden sind, wird die Karte (bzw. die Icons) nicht angezeigt.\n- `ModeButton`: Der interaktive Bereich (`getInteractiveArea`) passt nicht zur gezeichneten Button-Fläche: Du zeichnest ein Rechteck mit `65x25`, aber der Hover-/Click-Bereich ist nur `15x15`, dadurch reagieren Hover/Klick nur auf einen kleinen Teil des Buttons.\n- `City`: Der interaktive Bereich ist ein `Rectangle` mit `5x5` an der Koordinate; das ist sehr klein und entspricht nicht wirklich der sichtbaren Markierung (du zeichnest u.a. einen Kreis). Dadurch kann “drauf zeigen” in der Praxis kaum funktionieren, obwohl es gefordert ist, dass man die Beschreibung per Hover anzeigen kann.\n\n### Suggestion\n- Prüfe, welche Resource-Ordner/Dateinamen im mitgelieferten Projekt tatsächlich existieren (insbesondere im `resources`-Ordner) und richte deine `drawImage(...)`-Pfade exakt danach aus.\n- Leite die Größe/Position des `getInteractiveArea(...)` jeweils aus dem ab, was du in `draw(...)` tatsächlich zeichnest (beim Button z.B. gleiche Breite/Höhe wie das `drawRect`, bei City z.B. eine Fläche, die zur Kreisgröße passt).\n- Wenn du bei Hover einen größeren Kreis zeichnest oder Text einblendest: Überlege, ob der interaktive Bereich eher die “Basis-Markierung” treffen soll (klein) oder ob du ihn bewusst etwas größer machst, damit die Bedienung zuverlässig klappt.\n\n### Code Style\n- Entferne Debug-Ausgaben wie `System.out.println(satelliteMode)` in `SwissMap.draw` und `System.out.println(getInhabitants())` in `City.onMouseEnter`, das stört beim normalen Programmablauf.\n- In `Mountain` und `SwissMap` sind mehrere Imports/Variablen unbenutzt (z.B. `ImageIO`, `BufferedImage`, `IOException`, `Objects`, sowie `clicked`/`hovered` im `ModeButton` werden nicht verwendet) – das macht den Code unnötig unübersichtlich.\n- In `getInteractiveArea` erstellst du erst eine Variable (`Rectangle r/s = ...`) und gibst sie direkt zurück; das kann man kürzer halten (wenn du es lesbar findest), oder konsequent benennen (z.B. immer `area` statt `r/s`).\n\n\n# Exercise: visualizer\n\n### Correctness\n- Das `DataPoint`-Interface stellt nicht die Informationen bereit, die der `Visualizer` effektiv braucht (numerische x-/y-Werte für Plot/MinMax, Gruppierung für Farben/Legende sowie Titel/Detailtext für Hover).\n- Die Methoden im `DataPoint`-Interface sind als `void`-Setter formuliert (`title(...)`, `information(...)`, `secondInfo(...)`), aber der `Visualizer` braucht Getter-Rückgabewerte, um Dummy-Werte zu ersetzen.\n- In `Visualizer` wurden die `DUMMY_DOUBLE`- und `DUMMY_STRING`-Stellen nicht durch Aufrufe auf das jeweilige `DataPoint`-Objekt ersetzt; dadurch kann keine echte Visualisierung stattfinden.\n- `Movie`, `Country` und `Processor` implementieren `DataPoint` nicht, dadurch können die geladenen Datensätze nicht als `DataPoint[]` an den `Visualizer` übergeben werden.\n- In `VisualizerApp` wird weiterhin `new DataPoint[0]` verwendet statt einen der Loader (`loadMovies()`, `loadCountries()`, `loadProcessors()`) als Datensatz zu übergeben.\n- Die geforderte Zuordnung der Achsen ist nicht umgesetzt (Movies: x=Budget, y=User-Rating; Countries: x=Literacy, y=GDP per capita; Processors: x=Jahr+Monat kombiniert, y=clockRate * cores und logarithmische y-Achse).\n\n### Suggestion\n- Schau dir jede Stelle im `Visualizer` an, wo `DUMMY_DOUBLE`/`DUMMY_STRING` steht, und leite daraus ab, *welche konkrete Information* ein Punkt liefern muss (z.B. für `findMinMax()` eindeutig x und y als `double`).\n- Überlege dir für die Legende/Farbgebung: Welche *Kategorie* (String oder auch `null`) muss ein Punkt liefern, damit `collectGroups()` und `colorOfGroup(...)` sinnvoll funktionieren?\n- Für das Hover-Overlay: Der Code zeichnet einen fetten Titel und darunter mehrere Zeilen (`split(\"\\n\")`). Entwirf dafür Methoden im Interface, die genau diese Strings zurückgeben (statt sie “reinzugeben” per Parameter).\n- Implementiere das Interface schrittweise zuerst bei `Movie` und passe dann `VisualizerApp` so an, dass wirklich Movie-Daten an `Visualizer` übergeben werden können (Typkompatibilität: `Movie[]` vs `DataPoint[]` beachten).\n- Für `Processor`: Leite aus den Anforderungen ab, wie du aus Jahr+Monat einen einzelnen x-Wert machst, und welche y-Berechnung der Visualizer dann braucht (und wo du die Log-Skalierung einbauen würdest).\n\n### Code Style\n- Methodennamen im Interface wie `title(...)` wirken wie Setter; benenne sie so, dass klar ist, dass ein Wert *zurückgegeben* wird (und nutze passende Rückgabetypen statt `void`).\n- `information(Map<String, Integer> ...)`/`secondInfo(...)` wirkt unnötig kompliziert und passt schlecht zur tatsächlichen Darstellung im `Visualizer` (der erwartet am Ende Strings/Zeilen, nicht Maps).\n",
"status" : "SUCCESS"
}
}