{
"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` erfüllst du die Anforderung „wenn links/rechts möglich, dann versuchen“ nicht vollständig: Du drehst zwar, aber du gehst in diesem Schleifendurchlauf keinen Schritt nach vorne, und du machst auch keinen „rechtsum kehrt“, wenn weder vorne/links/rechts geht.\n- In `TryStraightFirst` kann die Figur in einer Situation ohne Pfad vorne/links/rechts in einer Endlosschleife hängen bleiben (weil dann in der Schleife nichts passiert, aber `isGoalReached()` weiterhin false ist).\n- In `BacktrackingAlgorithm` ist dein `else` an `if(figure.pathToTheRight())` gekoppelt: Das bedeutet, dein „ansonsten“-Fall tritt nur ein, wenn **rechts** nicht geht – selbst wenn vorne oder links auch nicht gehen (oder wenn vorne/links gegangen wurden). Das entspricht nicht sauber dem „wenn nichts geht, dann umdrehen/backtracken“-Gedanken.\n- In `BacktrackingAlgorithm` kann `figure.moveForward()` im `else`-Teil ausgeführt werden, ohne vorher zu prüfen, ob vorne ein Pfad ist; damit riskierst du direkt ein `GameOver` („Pfad verlassen!“).\n- In `BacktrackingAlgorithm` verwendest du ein fixes `besucht = new boolean[100][100][100]`; die Maps sind zwar klein, aber die dritte Dimension ist bei `dir` nur 0..3 nötig. Außerdem kann es je nach Umgebung/anderen Maps die Übungsanforderung „allgemein“ verletzen, weil es nicht an die tatsächliche Labyrinthgröße gekoppelt ist.\n\n### Suggestion\n- Bei `TryStraightFirst`: Überlege dir, was in **einem** Schleifendurchlauf passieren soll, wenn du links oder rechts auswählst. Reicht „nur drehen“, oder musst du danach direkt auch laufen, damit wirklich „versucht“ wird?\n- Für den Fall „nichts geht“ in `TryStraightFirst`: Lege explizit fest, was du dann tust (die Aufgabe verlangt rechtsum kehrt). Prüfe, dass danach auch wirklich eine Bewegung passiert und die Schleife nicht stehen bleibt.\n- In `BacktrackingAlgorithm`: Prüfe die Struktur deiner Verzweigungen: Der „kein Weg“-Fall sollte logisch erst dann greifen, wenn vorne/links/rechts **alle** nicht möglich sind (und nicht nur abhängig davon, ob rechts möglich ist).\n- Bevor du beim Backtracking einen Schritt „zurück“ läufst, stelle sicher, dass die Richtung wirklich zur vorherigen Position zeigt und dass dort auch ein Pfad ist (oder dass dein Rückschritt aus einer Aktion besteht, die garantiert legal ist).\n- Für `besucht`: Nutze für die ersten zwei Dimensionen die tatsächlichen Labyrinthkoordinatenbereiche (Zeilen/Spalten) und für die Richtung nur die 4 Zustände. Dann vermeidest du unnötige Größe und machst es wirklich „allgemein“.\n\n### Code Style\n- In `BacktrackingAlgorithm` ist `System.out.println(figure.isGoalReached());` Debug-Ausgabe und gehört typischerweise nicht in die finale Abgabe (und triggert außerdem ständig Listener-Checks).\n- Dein `besucht`-Array ist sehr groß und „magisch“ dimensioniert (`100`); solche Magic Numbers besser vermeiden bzw. aus sinnvollen Größen ableiten.\n- Einrückung/Whitespace ist in `BacktrackingAlgorithm` uneinheitlich (z.B. fehlende Einrückung bei Feldern/Blöcken), das macht die Kontrollfluss-Logik schwer lesbar.\n- Mehrfaches „Umdrehen“ (`turnLeft()`/`turnRight()` zweimal) kommt oft vor; das könntest du lesbarer machen (z.B. als kleine Hilfsmethode), damit klarer wird, wann du backtrackst vs. wann du explorierst.\n\n\n# Exercise: swissmap\n\n### Correctness\n- In `City.toString()`, `Lake.toString()` und `Mountain.toString()` verwendest du Zeilenumbrüche (`\"\\n\"`), obwohl in der Aufgabenstellung die Beschreibung als einzeiliger Text (wie im Ausgangscode vorgegeben) gedacht ist.\n- Deine `ModeButton`-Klickfläche (`getInteractiveArea`) ist deutlich kleiner als der Button, den du zeichnest (`drawRect` 65x25 vs. Rectangle 15x15). Damit reagiert ein Klick/Hoover nur auf einen kleinen Teil des sichtbaren Buttons, was die geforderte Button-Interaktion praktisch verletzt.\n- Bei `Lake` und `Mountain` ist die Skalierung der Icons über `WIDTH * scale(gui) / BG_PIXEL_WIDTH` an die Kartenbreite gekoppelt; dadurch werden die Icons beim Resizing extrem gross/klein statt eine sinnvolle, objektbezogene Grösse zu behalten (die Aufgabe verlangt „Objekte wie oben dargestellt“ – also Marker-Icons, nicht nahezu kartengrosse Bilder).\n\n### Suggestion\n- Schau dir die vorgegebene `toString()`-Formatierung im Ausgangscode an und überlege, wie du die Beschreibung ohne Zeilenumbruch so ausgeben kannst, dass sie trotzdem gut lesbar bleibt.\n- Leite die `getInteractiveArea` beim `ModeButton` aus den tatsächlich gezeichneten Button-Massen ab (gleiche Position und gleiche Breite/Höhe wie im `draw`), damit Hover/Klick wirklich dort passieren, wo der Button sichtbar ist.\n- Überlege dir für Lake/Mountain eine konstante (oder nur leicht skalierende) Icon-Grösse in Pixeln, statt die Icon-Grösse aus der Karten-`WIDTH` abzuleiten. Orientiere dich daran, dass ein Marker ungefähr gleich gross bleibt, während nur die Karte skaliert.\n\n### Code Style\n- Mehrere unbenutzte Imports (z.B. `ImageIO`, `BufferedImage`, `IOException`, `Objects`, `Arrays`) entfernen, das macht die Klassen leichter lesbar.\n- `clicked` und `hovered` im `ModeButton` werden gesetzt, aber im `draw` nicht genutzt; entweder visuell verwenden (z.B. Farbe ändern) oder weglassen.\n- Debug-Ausgaben wie `System.out.println(satelliteMode)` in `SwissMap.draw()` und `System.out.println(getInhabitants())` in `City.onMouseEnter()` rausnehmen, weil `draw()` sehr häufig aufgerufen wird und die Konsole sonst „zugespammt“ wird.\n\n\n# Exercise: visualizer\n\n### Correctness\n- Dein `DataPoint`-Interface liefert keine Werte für x- und y-Koordinate; der `Visualizer` braucht aber pro Punkt zwei numerische Werte, um Min/Max zu bestimmen, Punkte zu platzieren und Mouse-Hover-Abstände zu berechnen.\n- Dein `DataPoint`-Interface hat `void`-Methoden (`title`, `information`, `secondInfo`), aber der `Visualizer` benötigt Strings (z.B. Titel/Label, Detailtext, Gruppierung), die er zeichnen und für die Legende sammeln kann.\n- In `Visualizer` hast du die `DUMMY_DOUBLE`/`DUMMY_STRING` Stellen nicht ersetzt; damit kann die Visualisierung nicht wie gefordert funktionieren (Min/Max bleibt falsch, alle Punkte liegen auf derselben Position, Hover/Legendendaten sind Dummy).\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 `loadMovies()`/`loadCountries()`/`loadProcessors()`, dadurch wird gar nichts visualisiert.\n\n### Suggestion\n- Schau im `Visualizer` nach, welche Informationen an den DUMMY-Stellen gebraucht werden: überall dort sollte eine `DataPoint`-Methode existieren, die genau diesen Wert **zurückgibt** (nicht “setzt”).\n- Überlege dir eine minimale Schnittstelle: typischerweise brauchst du Methoden für `x` und `y` (double), für die Gruppierung/Farbe (String oder `null`), für den angezeigten Namen beim Hover (String) und für den mehrzeiligen Detailtext (String mit `\\n`).\n- Beim Umbau von `Visualizer`: ersetze jede Verwendung von `DUMMY_DOUBLE`/`DUMMY_STRING` durch den passenden Aufruf auf `point` bzw. `closest` (je nachdem in welcher Schleife du gerade bist).\n- Damit `VisualizerApp` funktioniert, müssen die Arrays aus `loadMovies/loadCountries/loadProcessors` als `DataPoint[]` verwendbar sein: prüfe, was du an den Datensatzklassen ändern musst, damit ein `Movie[]` automatisch als `DataPoint[]` akzeptiert werden kann.\n- Für die Datensatz-spezifische Logik: ordne für Movies Budget→x und Rating→y zu; bei Countries Literacy→x und GDP per Capita→y; bei Processors Veröffentlichungsdatum→x (Jahr+Monat kombiniert) und “effektive Geschwindigkeit”→y (ClockRate * Cores) und beachte, dass der Detailtext ggf. Formatierung/Einheiten braucht.\n\n### Code Style\n- Methodennamen wie `title(String name)` wirken wie Setter; für ein Interface, das vom Visualizer “abgefragt” wird, sind sprechende Getter-Namen (z.B. `get...`) konsistenter und leichter verständlich.\n- `information(Map<String, Integer>)`/`secondInfo(Map<String,Integer>)` sind sehr unklar benannt und erzwingen unnötig `Map`/`Integer`-Strukturen; der Visualizer zeichnet am Ende Text, daher ist eine textnahe Schnittstelle meist einfacher.\n- Es fehlen die geforderten Javadoc-Kommentare im `DataPoint`-Interface (Verhalten/Format z.B. für Mehrzeiler, erlaubte `null`-Werte für Gruppen etc.).\n",
"status" : "SUCCESS"
}
}