{
"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` erfüllt die Aufgabenbeschreibung nicht vollständig: Wenn vorne kein Pfad ist, soll links **oder** rechts versucht werden (mit anschließendem Schritt), und wenn gar nichts geht, soll die Figur **rechtsum kehrt** machen; bei dir wird bei links/rechts nur gedreht (ohne `moveForward()`), und der Fall „alles blockiert“ wird nicht behandelt.\n- `BacktrackingAlgorithm` weicht vom geforderten Interface-Design ab: `navigate` soll nur mit dem übergebenen `Figure` arbeiten, aber deine Implementierung hängt zusätzlich an einem `Labyrinth`-Objekt (Konstruktor-Parameter + Feld) und nutzt `labyrinth.cols()/rows()/goalAt(...)`.\n- In `LabyrinthApp` erstellst du ein `BacktrackingAlgorithm`-Objekt mit einem `Labyrinth`, das nur aus `MAPS[1]` gebaut wird, spielst damit aber alle Levels. Dadurch passt die verwendete Labyrinth-Referenz nicht zum Level, das gerade gespielt wird.\n- In `BacktrackingAlgorithm.checkPath` kann deine Rückwärtsbewegung (`turnLeft()`/`turnLeft()` + `moveForward()` + wieder zurückdrehen) einen `GameOver` auslösen, weil du dabei nicht prüfst, ob „hinter dir“ überhaupt ein Pfad ist (also ob das Rückwärtsfeld begehbar ist).\n- Dein Backtracking beendet die Navigation nicht zwingend, wenn das Ziel erreicht ist: du prüfst `labyrinth.goalAt(row, col)` (nicht `figure.isGoalReached()`), und selbst wenn du zurückkehrst, laufen aufrufende Stack-Frames danach teils mit weiteren Richtungsprüfungen weiter.\n\n### Suggestion\n- Für `TryStraightFirst`: Überlege dir eine feste Priorität pro Schleifendurchlauf (z.B. vorne, sonst links, sonst rechts, sonst umdrehen) und achte darauf, dass nach einer Entscheidung genau **eine** Aktion passiert, die die Figur wirklich in ein neues Feld bringt (Drehen allein reicht nicht).\n- Für `BacktrackingAlgorithm`: Versuche, den Algorithmus so zu formulieren, dass er ausschließlich über `Figure`-Methoden arbeitet (Pfad-Abfragen + Bewegungen + `isGoalReached()`), ohne Zugriff auf `Labyrinth`-Interna wie `goalAt`, `rows`, `cols`.\n- Für die Level-Schleife in `LabyrinthApp`: Der `NaviAlgorithm` sollte für jedes Level auf dem jeweils aktuellen Labyrinth/der aktuellen Figur funktionieren; vermeide daher, dass dein Algorithmus eine feste, „fremde“ Labyrinth-Instanz aus einem anderen Level verwendet.\n- Für das Zurückgehen im Backtracking: Bevor du „einen Schritt zurück“ machst, musst du sicher sein, dass der Schritt legal ist; nutze dafür eine Pfad-Abfrage in die entsprechende Richtung (oder stelle sicher, dass du nur zu Feldern zurückgehst, von denen du garantiert gekommen bist).\n- Für das korrekte Stoppen: Baue deine Rekursion/Schleifen so, dass nach dem Finden des Ziels keine weiteren Abzweigungen mehr ausgeführt werden (z.B. indem der Erfolg an den Aufrufer zurückgemeldet wird), statt nur lokal `return` zu machen.\n\n3. Code Style:\n- In `BacktrackingAlgorithm.navigate` sind lokale Variablen `col`/`row` für `labyrinth.cols()/rows()` irreführend benannt (das sind Dimensionen, nicht Positionen); außerdem sind sie danach nur für das Array relevant.\n- Auskommentierter Codeblock in `navigate` macht es schwer lesbar; besser entfernen, sobald du dich für den Ansatz entschieden hast.\n- `checkPath` enthält viel duplizierte Logik (vor/zurück + rekursiver Aufruf + „zurücksetzen“ der Ausrichtung); das schreit nach einer kleinen Hilfsmethode, damit du weniger Copy-Paste hast und Fehlerquellen reduzierst.\n- `BacktrackingAlgorithm` speichert `Labyrinth` als Feld, obwohl das Interface nur `Figure` vorgibt; das koppelt unnötig und macht Tests/Verwendung schwieriger.\n\n\n# Exercise: swissmap\n\n### Correctness\n- In `Lake` und `Mountain` (und auch `SwissMap`) verwendest du andere Resource-Pfade (`swissmap_img/...`) als in der Aufgabenstellung/SwissMap-Vorlage (`swissmap/...`). Wenn diese Dateien nicht exakt so im `resources`-Ordner liegen, werden die Bilder nicht geladen und die Objekte nicht wie gefordert angezeigt.\n- Die Skalierung für `Lake` und `Mountain` benutzt den Hintergrund-Skalierungsfaktor der ganzen Karte (`WIDTH * scale(gui) / BG_PIXEL_WIDTH`) als Bildscale. Dadurch werden die Icons voraussichtlich riesig bzw. in einer falschen Größe gezeichnet statt als kleine Marker auf der Karte.\n- `ModeButton` wird gezeichnet als `65x25`, aber `getInteractiveArea` gibt nur ein `15x15`-Rechteck zurück. Damit ist nur ein kleiner Teil des Buttons wirklich hover-/clickbar, was die Button-Anforderung „als Knopf“ praktisch verletzt.\n- Bei `City` ist die interaktive Fläche (`5x5` Rectangle) nicht passend zur gezeichneten Darstellung (Kreisradius 5 bzw. im Hover sogar 10). Dadurch wird Hover nur sehr schwer/ungenau ausgelöst und die Beschreibung erscheint nicht zuverlässig beim „darauf zeigen“.\n\n### Suggestion\n- Prüfe im Projekt, wie der `resources`-Ordner strukturiert ist und wie die Beispiel-`SwissMap.drawImage(...)` ihre Pfade angibt; übernimm dieses Schema konsistent für Lake/Mountain/SwissMap, damit die Assets sicher gefunden werden.\n- Überlege dir für Marker-Icons eine eigene konstante Pixelgröße (oder eine moderate, map-unabhängige Skalierung) statt den Kartenhintergrund-Scale zu verwenden; orientiere dich daran, wie groß die Marker im Screenshot wirken.\n- Lass die `getInteractiveArea` beim `ModeButton` die gleiche Position und Größe abdecken wie dein gezeichnetes Rechteck, damit Klick/Hover zum Button passt.\n- Passe bei `City` die interaktive Fläche an die tatsächlich gezeichnete Form/Größe an (z.B. mindestens so groß wie der sichtbare Kreis), damit „Hover zum Anzeigen“ zuverlässig funktioniert.\n\n### Code Style\n- Mehrere Debug-Ausgaben (`System.out.println(...)` in `SwissMap.draw` und `City.onMouseEnter`) gehören nicht zur GUI-Logik und machen die Konsole bei jedem Frame/Event unnötig voll.\n- In `Mountain` und `SwissMap` hast du Imports für `ImageIO`, `BufferedImage`, `IOException`, `Objects`, die nicht verwendet werden; die solltest du entfernen.\n- In `ModeButton` sind Felder wie `hovered` und `clicked` derzeit ohne Effekt im Rendering/Verhalten; entweder nutzen (z.B. Darstellung ändern) oder weglassen, damit der Code klar bleibt.\n\n\n# Exercise: visualizer\n\n### Correctness\n- Das `DataPoint`-Interface stellt keine Werte für x- und y-Achse bereit; der `Visualizer` kann damit weder `minX/maxX/minY/maxY` bestimmen noch Punkte korrekt platzieren.\n- Die Methoden im `DataPoint`-Interface sind als “Setter” formuliert (`void title(...)`, `void information(...)`), aber der Visualizer braucht “Getter”-Informationen pro Datenpunkt (Titel/Details/Gruppe) zum Zeichnen und für die Hover-Anzeige.\n- Es fehlen die geforderten Javadoc-Kommentare am `DataPoint`-Interface (Verhalten der Methoden dokumentieren).\n- `Visualizer` verwendet weiterhin überall `DUMMY_DOUBLE`/`DUMMY_STRING` statt Methodenaufrufe auf dem jeweiligen `DataPoint`-Objekt.\n- `Movie`, `Country` und `Processor` implementieren das `DataPoint`-Interface nicht, dadurch kannst du die geladenen Datensätze nicht als `DataPoint[]` an den `Visualizer` übergeben.\n- In `VisualizerApp` wird weiterhin `new DataPoint[0]` verwendet statt die Daten über `loadMovies()` / `loadCountries()` / `loadProcessors()` zu visualisieren.\n\n### Suggestion\n- Schau dir im `Visualizer` jede Stelle an, wo ein `DUMMY_DOUBLE` verwendet wird: Überlege jeweils, ob dort der x-Wert oder der y-Wert eines konkreten `point` gemeint ist, und leite daraus passende Methoden im Interface ab.\n- Für die Stellen mit `DUMMY_STRING`: Unterscheide zwischen (a) Gruppierung/Farbe (Legendeneintrag), (b) Titel in fett beim Hover, (c) mehrzeiliger Detailtext (`split(\"\\n\")`). Das sind typischerweise getrennte Informationen und brauchen nicht alle dieselbe Methode.\n- Interface-Methoden sollten Informationen *zurückgeben* (Richtung: Datenpunkt → Visualizer), nicht Daten “entgegennehmen”. Formuliere deine Interface-Methoden so, dass der Visualizer sie aufrufen kann, ohne vorher etwas setzen zu müssen.\n- Wenn du `Movie` kompatibel machst: Leite x aus Budget und y aus Rating ab (steht in der Aufgabe). Übertrage das gleiche Prinzip für `Country` (Literacy vs. GDP per capita) und `Processor` (Monat+Jahr vs. effektive Geschwindigkeit).\n- Passe danach `VisualizerApp` so an, dass tatsächlich eines der geladenen Arrays visualisiert wird; dafür müssen die Elemente im Array den Typ `DataPoint` erfüllen (also implementieren oder entsprechend umgewandelt werden).\n\n### Code Style\n- Die Methodennamen im Interface (`title`, `information`, `secondInfo`) sind semantisch uneindeutig und wirken wie Mutator-Methoden; üblich wäre eine klare Benennung nach dem, was geliefert wird (und konsistente Rückgabetypen statt `void`).\n- `Map<String, Integer>` als Interface-Parameter koppelt die Schnittstelle stark an eine konkrete Datenstruktur und schränkt spätere Darstellung (z.B. Werte mit Dezimalstellen oder Einheiten) ein; für Hover-Text ist ein bereits formatierter String oft einfacher.\n- Imports im `DataPoint` (`java.util.Map`) wären nach einer Umgestaltung evtl. nicht mehr nötig; behalte nur, was du wirklich verwendest.\n",
"status" : "SUCCESS"
}
}