{
"llm" : {
"feedback" : "# Exercise: todo\n\n### Correctness\n- Die Ausgabeformatierung in `Task.toString()` entspricht nicht dem gezeigten Beispiel: erwartet ist u. a. ein Häkchen (`✓`) bei erledigten Tasks und ein anderes Spacing/Format (z. B. `\" ✓ [0] Waschen\"` bzw. `\" [1] Lernen\"`), nicht `\"[X][0] Waschen\"` / `\"[ ][id] ...\"`.\n- Die Fehlermeldung bei ungültiger ID soll genau `\"Task with ID XX not found\"` sein (gemäss Kommentar/Vorgabe). Du gibst stattdessen `\"Task with ID \" + id + \" not found\"` aus.\n\n### Suggestion\n- Schau dir die Beispiel-Session genau an und passe `toString()` so an, dass die Darstellung (Häkchen vs. Leerzeichen, Klammern um die ID, führende Leerzeichen) exakt dazu passt; insbesondere unterscheide „done“ und „not done“ so, wie es im Output gezeigt wird.\n- Orientiere dich bei der Fehlermeldung an der exakt verlangten Zeichenkette im Methodenkommentar (inkl. `XX`), auch wenn es „komisch“ wirkt, dass nicht die echte ID eingesetzt wird.\n\n### Code Style\n- `import ch.fhnw.prog1.exercise.todo.Task;` ist in `ToDoApp` redundant, weil `Task` im selben Package liegt.\n- In `Task` ist bei `this. isDone = false;` ein unnötiges Leerzeichen nach dem Punkt.\n- In `listTasks`/`addTask` iterierst du jeweils über `tasks.length` (100). Das ist ok, aber ohne Zähler für „benutzte“ Einträge machst du immer einen kompletten Scan; ein `used`-Counter würde Logik und Laufzeit vereinfachen.\n\n\n# Exercise: energymeter\n\n### Correctness\n- Der Konstruktor und die Methoden sind bei dir `public`, in der Aufgabenbeschreibung (und auch in der Beispiel-Lösung) sind sie package-private (ohne `public`). Falls die Unit-Tests im selben Package liegen und genau diese Sichtbarkeit erwarten, kann das zu einem Test-Fehlschlag führen.\n\n### Suggestion\n- Schau dir an, wie die Tests die Klasse instanziieren und Methoden aufrufen: Achten sie auf Modifier/Sichtbarkeit (z. B. kein `public`)? Falls ja, passe die Deklarationen entsprechend an (Konstruktor und Methoden ohne `public`).\n\n### Code Style\n- Du mischst Exception-Messages (einmal mit Text, sonst ohne). Einheitlicher wäre entweder überall mit oder überall ohne Message.\n- Die `if/else`-Blöcke in `fill` und `consume` könnten lesbarer werden, wenn du erst den neuen Level berechnest und dann auf Min/Max begrenzt (das ist weniger verzweigt).\n\n\n# Exercise: pong\n\n### Correctness\n- Die geforderten Klassen `Player` und `Ball` fehlen vollständig.\n- In `PongGame` werden keine zwei `Player`-Objekte und kein `Ball`-Objekt erstellt/initialisiert und gespeichert.\n- Der Ball startet nicht in der Mitte und hat keine zufällige Anfangsgeschwindigkeit.\n- In der Spielschleife werden weder Player noch Ball tatsächlich bewegt (die Key-Inputs werden nur gelesen, aber nicht verwendet).\n- Kollisionen (oben/unten für Ball und Begrenzung der Player, sowie Ball-Player und Ball-Seitenwände inkl. Punktevergabe/Reset) sind nicht implementiert.\n- Es werden nicht die Objekte (Player/Ball) gezeichnet, sondern weiterhin nur die Platzhalter-Primitive (fixes Rechteck/Kreis).\n- Erweiterung auf mehrere Bälle (Array, periodisches Hinzufügen, Entfernen beim Verlassen) ist nicht umgesetzt.\n\n### Suggestion\n- Fang mit (a) an: Lege zwei kleine Klassen an, die genau die im Text genannten Felder enthalten (Position, Größe/Score bzw. Geschwindigkeit) und überlege, welche Werte du beim Start setzen musst (Spielmitte, sinnvolle Paddle-Positionen links/rechts).\n- Für die zufällige Ballgeschwindigkeit: Wähle einen Wertebereich für `vx` und `vy` und sorge dafür, dass die Richtung zufällig positiv/negativ ist (und dass `vx` nicht 0 wird).\n- In (b): Ersetze die fixen `fillRect`/`fillCircle`-Koordinaten durch Zeichnen basierend auf den Objekt-Feldern (z.B. `player.px/py`, `ball.px/py`).\n- In (c): Nutze die Booleans von `isKeyPressed`, um `py` der Spieler zu ändern (hoch/runter). Für den Ball: pro Frame `px += vx`, `py += vy`.\n- In (d): Beim Ball an oberer/unterer Wand nur `vy` umdrehen und die Position zurück in den gültigen Bereich schieben. Bei den Players nach dem Bewegen `py` so begrenzen, dass der Balken im Feld bleibt.\n- In (e): Überlege dir eine einfache Kollisionsprüfung (z.B. Rechteck-Rechteck mit Ball als kleines Rechteck oder Kreis vs. Rechteck). Beim Treffer soll die x-Richtung umkehren. Bei Seitenwand: Punktestand erhöhen und Ball neu in die Mitte setzen (mit neuer zufälliger Geschwindigkeit).\n- In (f): Verwende ein `Ball[]` plus eine Variable, die zählt, wie viele Einträge aktuell “aktiv” sind. Halte eine Invariante wie „aktive Bälle liegen kompakt von Index 0 bis active-1“, dann kannst du Entfernen effizient machen, indem du den letzten aktiven Ball in die Lücke kopierst.\n\n### Code Style\n- Aktuell ist fast nur Template-/TODO-Code vorhanden; sobald du implementierst, achte darauf, Zuständigkeiten zu trennen: Logik (move/collide) eher in `Ball`/`Player`, Rendering in `draw`-Methoden.\n- Die Variablen `p1Up` und `p2Up` werden momentan nicht verwendet; entweder verwerten (für Bewegung) oder weglassen, sobald du direkt auf `isKeyPressed` reagierst.\n- Vermeide “Magic Numbers” wie `20, 50, 10, 100` im Zeichencode; ersetze sie durch Konstanten oder berechne sie aus `WIDTH/HEIGHT` und Paddle-Länge.\n\n\n# Exercise: stepstats\n\n### Correctness\n- Die Verwendungsweise in der Aufgabenstellung erwartet die Attribute `averageSteps`, `minSteps`, `maxSteps` (und `successDays`). In deiner Klasse heisst das Feld für den Durchschnitt aber `avgSteps`, was nicht zur geforderten API passt.\n\n### Suggestion\n- Benenne das Attribut für den Durchschnitt so, dass es genau dem Namen entspricht, der im Aufgabenstatement gezeigt wird, und passe die Ausgaben im Client entsprechend an.\n\n### Code Style\n- Achte auf konsistente Einrückung im `for`-Loop (einige Zeilen sind anders eingerückt), das erschwert das Lesen.\n- In `StepTracker` fehlen im Vergleich zur Vorlage/Beispiel die Klassen- und Paket-Deklaration sowie nötige Imports (z. B. `Scanner`). Falls eure Code-Vorlage das nicht automatisch liefert, sollte das konsistent zur restlichen Übungsstruktur sein.\n",
"status" : "SUCCESS"
}
}