{
"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- Es fehlt die geforderte Klasse `StupidAlgorithm` (Implementierung des `NaviAlgorithm`), die einfach per `while` geradeaus läuft, bis das Ziel erreicht ist.\n- Es fehlt die geforderte Klasse `TryStraightFirst` mit der beschriebenen Priorität (geradeaus, sonst links/rechts, sonst rechtsum kehrt).\n- In deiner `LabyrinthApp` hast du die vorgegebenen `MAPS` verändert und damit nicht mehr die Levels aus der Aufgabe verwendet; dadurch ist nicht überprüfbar, ob dein Algorithmus die geforderten Levels schafft.\n- `BacktrackingAlgorithmWithMemory` merkt sich besuchte Positionen nur über `row/col`, ignoriert aber die Blickrichtung; dadurch kann er in Situationen abbrechen, obwohl aus derselben Zelle mit anderer Richtung noch ein anderer (neuer) Abzweig geprüft werden müsste.\n- `BacktrackingAlgorithm` macht beim Zurückgehen teils `moveForward()`, ohne davor zu drehen (bzw. ohne sicherzustellen, dass „vorwärts“ wirklich zurück zur vorherigen Zelle führt); das ist kein korrektes Backtracking und kann in Sackgassen oder an Kreuzungen falsch laufen bzw. crashen.\n\n### Suggestion\n- Implementiere die Aufgabe wirklich schrittweise: zuerst den „nur geradeaus“-Algorithmus (ohne Abbiegen), dann den „try straight first“-Algorithmus (mit den vier Fällen), und erst danach Backtracking.\n- Lass die originalen `MAPS` aus der Vorlage unverändert und teste deinen Algorithmus genau damit, sonst umgehst du unabsichtlich die eigentliche Schwierigkeit der Levels.\n- Wenn du „Seen“/Memory verwendest: überlege dir, ob „State“ nur aus `(row,col)` besteht oder ob `(row,col,dir)` (oder sogar „Kante“/Move) nötig ist, damit du beim erneuten Betreten derselben Zelle trotzdem andere Ausgänge noch testen kannst.\n- Für korrektes Backtracking: prüfe, ob du nach einem rekursiven Versuch wirklich zuverlässig in den exakt vorherigen Zustand zurückkehrst (Position und Richtung). Achte dabei besonders darauf, wann du drehen musst, bevor du zurückläufst.\n\n### Code Style\n- Du hast mehrere auskommentierte „Versionen“ im Code: behalte nur eine finale Variante und entferne alte Versionen (oder nutze Git für Historie).\n- `BacktrackingAlgorithmWithMemory` baut Positions-Keys als String (`col + \"/\" + row`); das ist unnötig fehleranfällig/ineffizient—besser wäre ein kleiner Value-Typ (z.B. eigenes `record`) oder ein eindeutiges Encoding.\n- In `LabyrinthApp` sind die `MAPS` stark von der Vorlage abweichend; auch wenn es zum Testen praktisch ist, macht das die Abgabe schwer nachvollziehbar—für Abgaben besser beim Template bleiben und höchstens zusätzliche Testmaps separat anlegen.\n\n\n# Exercise: swissmap\n\n### Correctness\n- In `City`, `Lake` und `Mountain` wird beim Hover keine **Beschreibung** angezeigt (Aufgabe c verlangt, dass beim Daraufzeigen die Beschreibung erscheint; aktuell ändert sich nur die Darstellung).\n- `getInteractiveArea(...)` ist bei `City`/`Lake`/`Mountain` fachlich unpassend dimensioniert: Du verwendest `area` bzw. `height` als Breite/Höhe des `Rectangle` (das sind km² bzw. Meter), wodurch der Hover-Bereich nicht zur gezeichneten Darstellung passt und je nach Objekt extrem riesig/komisch sein kann.\n- In `City.draw(...)` wird die Kreisgrösse an `gui.getWidth()` gekoppelt statt an die Map-Skalierung bzw. eine konstante/skalierte Markergrösse; dadurch hängt die Markergrösse nicht sinnvoll mit der Karten-Zoomstufe zusammen (bei Resizing wird der Kreis u. U. unproportional gross/klein).\n- `SwissMapApp`: Die `main`-Methode hat die falsche Signatur (`void main()` statt einer Java-Entry-Point-Signatur). Je nach Test/Startumgebung wird das Programm so nicht als Startklasse erkannt.\n\n### Suggestion\n- Für die Beschreibung beim Hover: Nutze dein `hovering`-Flag nicht nur für “hover image/grösserer Kreis”, sondern zeichne in `draw(...)` zusätzlich einen Text (z. B. `toString()` oder `name` + Werte), aber nur wenn `hovering == true`.\n- Für den interaktiven Bereich: Überlege dir, welche Pixel-Fläche dein Objekt tatsächlich belegt (Icon-Breite/-Höhe oder Kreisradius) und baue das `Rectangle` (oder eine passendere `Shape`) mit diesen Pixelmassen um die GUI-Koordinaten; nicht mit km²/m als Rohwert.\n- Für die City-Grösse: Statt `gui.getWidth()/...` nimm eine feste Markergrösse (ggf. leicht mit `SwissMap.scale(gui)` skalieren), damit Marker und Hover-Bereich konsistent bleiben, wenn das Fenster resized wird.\n- Für `main`: Prüfe, wie die Aufgabe/Tests das Programm starten. In der Regel muss `main` `public static void main(String[] args)` sein, sonst wird es nicht automatisch ausgeführt.\n\n### Code Style\n- In `ModeButton`: `private SwissMap swissMap;` kann `final` sein, da die Referenz nach dem Konstruktor nicht mehr geändert wird.\n- In `ModeButton`: `WIDTH` und `HEIGHT` sollten als `static final` Konstanten (und üblicherweise in GROSSBUCHSTABEN) deklariert werden, statt als Instanzfelder.\n- In mehreren Klassen wiederholt sich sehr viel Hover-Boilerplate (hovering-Flag, enter/exit, Rectangle). Das ist nicht falsch, aber langfristig könntest du das vereinheitlichen (z. B. durch Hilfsmethoden/Konstanten), damit du Interaktionsfläche und Zeichnen konsistent hältst.\n\n\n# Exercise: visualizer\n\nLlm Evaluation ist für diese Aufgabe deaktiviert. Entferne die .llmignore Datei vom Package der Aufgabe.\n",
"status" : "SUCCESS"
}
}