{
"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 `LabyrinthApp` erstellst du das `NaviAlgorithm`-Objekt einmal mit `new Labyrinth(MAPS[1])` und verwendest es dann für alle Levels; dein `BacktrackingAlgorithm` arbeitet aber mit diesem gespeicherten `labyrinth` und nicht mit dem Labyrinth des jeweiligen `LabyrinthGame`-Levels, das die `Figure` tatsächlich bewegt.\n- `TryStraightFirst` erfüllt die Aufgabenbeschreibung nicht vollständig: Wenn vorne/links/rechts kein Pfad ist, soll die Figur „rechtsum kehrt“ machen; dieser Fall fehlt, dadurch kann der Algorithmus in einer Sackgasse in einer Endlosschleife hängen.\n- In `BacktrackingAlgorithm.checkPath` prüfst du das Ziel mit `labyrinth.goalAt(row, col)` statt über das `Figure`/die aktuelle Spielinstanz; dadurch kann „Ziel erreicht“ falsch beurteilt werden, sobald `labyrinth` nicht zum aktuellen Level passt.\n- Dein Backtracking markiert Felder als `besucht` und bricht dann sofort ab, wenn du wieder auf ein besuchtes Feld kommst; damit kann es passieren, dass du alternative Abzweigungen, die du von diesem Feld aus noch nicht ausprobiert hast, nie mehr untersuchst (und so das Ziel verfehlst).\n- In `checkPath` drehst du bei „keine Wege“ nur um (`turnRight()` zweimal) und rufst rekursiv `checkPath` auf, ohne dich tatsächlich zurück zu bewegen; wenn das Feld schon als besucht markiert ist, passiert danach nichts mehr und du bleibst effektiv in der Sackgasse stehen.\n\n### Suggestion\n- Überlege dir, wie dein Algorithmus an die passende „Welt“ (das konkrete Level) kommt: Die `navigate(Figure figure)`-Methode bekommt absichtlich nur die `Figure`, damit der Algorithmus level-unabhängig bleibt.\n- Ergänze bei `TryStraightFirst` einen letzten `else`-Fall für „keine Richtung möglich“ und setze dort die geforderte Kehrtwende um, bevor die Schleife weiterläuft.\n- Für `Backtracking`: Wenn du „besucht“ verwendest, trenne gedanklich „Knoten schon mal betreten“ von „alle Ausgänge dieses Knotens vollständig ausprobiert“. Eine Möglichkeit ist, nicht nur Zellen zu merken, sondern auch, aus welcher Richtung/mit welchem Zustand du dort warst bzw. welche Abzweigungen noch offen sind.\n- Beim Backtracking muss das Zurückgehen real stattfinden: Nach einem rekursiven Versuch musst du die Figur wieder in den Zustand bringen (Position + Blickrichtung), den sie vor dem Versuch hatte, bevor du die nächste Richtung probierst.\n- Für Sackgassen: Eine Kehrtwende allein reicht nicht, wenn du danach nicht mindestens einen Schritt zurück machst (oder sonstwie zum letzten Entscheidungspunkt zurückkommst).\n\n3. Code Style:\n- `BacktrackingAlgorithm` hat auskommentierte große Code-Blöcke; die besser entfernen, sobald du dich für eine Variante entschieden hast.\n- Feldnamen wie `besucht` sind ok, aber gemischte Sprache im Code (Deutsch/Englisch) wirkt schnell inkonsistent; entscheide dich möglichst für eine Richtung.\n- In `BacktrackingAlgorithm.navigate` sind `int col = labyrinth.cols(); int row = labyrinth.rows();` leicht verwirrend benannt (col/row als Größen vs. später col/row als Position); unterschiedliche Namen würden das klarer machen.\n- `BacktrackingAlgorithm` speichert ein `Labyrinth`-Objekt als Feld, obwohl `navigate` schon alles Nötige über die `Figure` steuern soll; das koppelt die Klasse unnötig an eine konkrete Map-Instanz.\n\n\n# Exercise: swissmap\n\n### Correctness\n- In `Lake`, `Mountain` und `SwissMap` verwendest du andere Resource-Pfade (`swissmap_img/...`) als in der Aufgabenstellung/Grundgerüst vorgesehen (`swissmap/...`). Wenn diese Dateien nicht genau so im `resources`-Ordner liegen, werden die Bilder nicht geladen und damit die Objekte/Map nicht korrekt angezeigt.\n- `ModeButton.getInteractiveArea(...)` passt nicht zur gezeichneten Button-Fläche: Du zeichnest ein Rechteck mit `65x25`, aber der interaktive Bereich ist nur `15x15`. Dadurch ist ein grosser Teil des Buttons nicht klick-/hoverbar.\n- `City.getInteractiveArea(...)` ist sehr klein (`5x5`) und zudem so positioniert, dass das Rechteck ab dem Punkt `(x,y)` nach rechts/unten geht. Wenn du den Kreis um `(x,y)` zeichnest, ist der „Trefferbereich“ damit nicht um den Kreis zentriert, was Hover häufig „verfehlt“.\n- `Lake`/`Mountain` skalieren ihre Icons mit `WIDTH * scale(gui) / BG_PIXEL_WIDTH` (also mit einer Skalierung, die zur Hintergrundkarte passt). Das führt sehr wahrscheinlich zu viel zu grossen Icons, weil du die Kartengrösse als Basis für ein Icon benutzt (die Icons sollten typischerweise eine feste Pixelgrösse oder eine eigene, kleine Skalierung haben).\n\n### Suggestion\n- Prüfe, wie die Bilder im Projekt tatsächlich abgelegt sind (Ordnername im `resources`-Verzeichnis) und gleiche dann die Strings in `drawImage(...)` darauf ab; orientiere dich an der Art, wie `SwissMap` im Grundgerüst die Pfade benutzt.\n- Leite die Breite/Höhe des interaktiven Bereichs beim `ModeButton` direkt von den Werten ab, die du auch beim Zeichnen verwendest, damit Zeichnung und Interaktion deckungsgleich sind.\n- Überlege bei `City` (und ggf. auch bei den Icons), ob dein `Rectangle` um den Mittelpunkt liegen sollte (also x/y entsprechend verschoben), damit der Hover-Bereich den Kreis wirklich abdeckt.\n- Für `Lake`/`Mountain`: Nimm für die Icon-Grösse eine eigene konstante Grösse (oder eine sehr kleine, direkt gedachte Skalierung), statt die Kartenbreite (`WIDTH`) als Ausgangspunkt zu verwenden.\n\n### Code Style\n- In mehreren Klassen sind Imports/Variablen unnötig bzw. ungenutzt (z.B. `Component` in `SwissMap`, `ImageIO/BufferedImage/IOException/Objects` in `Mountain` und `SwissMap`, `Arrays` in `SwissMapApp`, `clicked`/`hovered` in `ModeButton` ohne Effekt im `draw`). Entferne das, damit der Code fokussiert bleibt.\n- `System.out.println(...)` in `SwissMap.draw` und `City.onMouseEnter` erzeugt sehr viel Konsolen-Output (draw wird ständig aufgerufen). Wenn du debuggen willst, mach das gezielt oder nur temporär.\n- In `toString()` fügst du `\\n` ein (City/Lake/Mountain). Das ist ok, aber achte darauf, dass `drawString` das überhaupt als Zeilenumbruch unterstützt; sonst wirkt die Ausgabe „komisch“.\n\n\n# Exercise: visualizer\n\n### Correctness\n- Das `DataPoint`-Interface stellt nicht die Informationen bereit, die der `Visualizer` für die Darstellung benötigt: Es fehlen Methoden, um die x- und y-Werte eines Punktes zu liefern, sowie Text für Anzeige/Details und (optional) eine Gruppierung für die Farben/Legende.\n- Die Methoden im `DataPoint`-Interface sind als `void` definiert und wirken wie “Setter” (`title(...)`, `information(...)`), aber der `Visualizer` muss Werte **abfragen** können (er hat ja nur `DataPoint point` und zeichnet daraus).\n- In `Visualizer` wurden die `DUMMY_DOUBLE`/`DUMMY_STRING`-Stellen nicht durch Aufrufe auf das jeweilige `DataPoint`-Objekt ersetzt, dadurch wird weiterhin nichts Sinnvolles visualisiert.\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 eines geladenen Datensatzes (Movies/Countries/Processors), dadurch gibt es keine Datenpunkte zu visualisieren.\n- Es fehlen die geforderten Javadoc-Kommentare, die das erwartete Verhalten der Interface-Methoden dokumentieren.\n- Die aufgaben-spezifischen Achsen-Zuordnungen sind noch nicht umgesetzt (Movies: Budget vs. Rating; Countries: Literacy vs. GDP/capita; Processors: Veröffentlichungsmonat kombiniert + effektive Geschwindigkeit).\n\n### Suggestion\n- Schau dir in `Visualizer` alle Stellen an, wo ein `point` existiert, aber `DUMMY_DOUBLE`/`DUMMY_STRING` genutzt wird: Welche **konkreten Informationen** braucht der Visualizer dort jeweils? Daraus ergibt sich fast direkt, welche “Getter”-Methoden ins Interface gehören.\n- Überlege beim Interface: der Visualizer darf ein `DataPoint` nicht “füttern”, sondern muss aus ihm **lesen** können. Frage dich daher bei jeder Interface-Methode: “Soll der Visualizer hier etwas setzen – oder etwas bekommen?”\n- Für die Legende/Farbgebung brauchst du pro Punkt einen Gruppennamen (oder `null`). Für den Hover brauchst du einen Titel und einen mehrzeiligen Detailtext. Für die Position brauchst du zwei Zahlenwerte (x/y). Versuche das minimal und allgemein für alle 3 Datensätze zu definieren.\n- Wenn das Interface steht, implementiere es in **einer** Klasse zuerst (z.B. `Movie`) und ersetze in `VisualizerApp` den Datensatz, damit du schnell testen kannst, ob Punkte erscheinen und Hover/Legende funktionieren.\n- Für Prozessoren: Überlege, wie du “Jahr+Monat” zu einem einzigen x-Wert machst, den man gut auf einer Achse plotten kann, und welche y-Berechnung (ClockRate * Cores) du zurückgibst. Die Log-Skalierung betrifft dann nicht das Interface, sondern wie/wo der Visualizer y-Werte umrechnet.\n\n3. Code Style:\n- Die Methodennamen im Interface (`title`, `information`, `secondInfo`) sind semantisch unklar und wirken wie Setter; auch `secondInfo` ist wenig aussagekräftig. Bessere, eindeutig lesende Namen würden das Interface verständlicher machen.\n- `Map<String, Integer>` als Parameter-Typ im Interface macht die Schnittstelle unnötig kompliziert und unflexibel (und passt schlecht zu den Strings, die im Hover-Screenshot angezeigt werden). Außerdem fehlt dir damit z.B. die Möglichkeit, nicht-integer Werte sauber darzustellen.\n- In `DataPoint.java` ist ein `import java.util.Map;` drin, der mit der späteren Visualizer-Integration sehr wahrscheinlich nicht nötig sein wird; achte darauf, Imports schlank zu halten.\n",
"status" : "SUCCESS"
}
}