{
"llm" : {
"feedback" : "# Exercise: todo\n\n### Correctness\n- Die `Task`-Klasse ist nicht implementiert (inkl. Felder wie ID/Beschreibung/Done und `toString()`), obwohl die Ausgabe über `IO.println(task)` darauf angewiesen ist.\n- Es fehlt das geforderte `Task[]`-Array in `ToDoApp`, in dem die Tasks gespeichert werden sollen.\n- Die drei geforderten Methoden `listTasks`, `addTask` und `markTaskDone` sind noch nicht implementiert, damit ist die App funktional nicht lauffähig gemäß Aufgabenbeschreibung.\n\n### Suggestion\n- Leite aus der Beispiel-Interaktion ab, welche Informationen ein `Task`-Objekt mindestens speichern muss (z. B. ID, Beschreibung, erledigt ja/nein) und welche Darstellung `toString()` liefern soll, damit `IO.println(task)` die gewünschte Zeile ausgibt.\n- Lege in `ToDoApp` eine feste Datenstruktur (Array) für Tasks an und überlege dir zusätzlich, wie du festhältst, wie viele Plätze bereits belegt sind bzw. wo der „erste freie Platz“ ist.\n- In `listTasks(all)`: Iteriere über die gespeicherten Tasks und gib abhängig von `all` entweder alle oder nur die nicht erledigten aus; denke daran, den Spezialfall „es wurde nichts ausgegeben“ zu erkennen und dann `(No tasks)` zu drucken.\n- In `addTask(description)`: Ermittle den Index des ersten freien Array-Platzes (das ist gleichzeitig die ID) und speichere dort ein neu erzeugtes `Task`-Objekt.\n- In `markTaskDone(id)`: Nutze, dass die ID dem Array-Index entspricht; prüfe vorher, ob an dieser Stelle überhaupt ein Task existiert, und gib sonst die geforderte Meldung aus.\n\n### Code Style\n- In deiner Abgabe sind aktuell nur die TODO-Gerüste vorhanden; sobald du implementierst, achte darauf, die Logik in den drei Methoden zu kapseln (nicht zusätzliche Parsing-Logik in `main` duplizieren) und aussagekräftige Variablennamen für Zähler/Belegung zu verwenden.\n\n\n# Exercise: energymeter\n\n### Correctness\n- Deine Methoden und der Konstruktor sind als `public` deklariert, in der Aufgabenbeschreibung/Beispiellösung sind sie package-private (ohne `public`); falls die Unit-Tests exakt diese Sichtbarkeit erwarten, kann das zu einem Fehlschlag führen.\n\n### Suggestion\n- Schau dir an, wie die Tests/Beispiellösung die Sichtbarkeit der Klasselemente vorgeben: Entferne testweise `public` bei Konstruktor und Methoden (und ggf. auch bei den Attributen), sodass alles im gleichen Package zugreifbar bleibt, aber nicht öffentlich ist.\n\n### Code Style\n- Einheitlichkeit bei Exceptions: einmal mit Message (`IllegalArgumentException(\"...\")`), sonst ohne; entscheide dich für eine Variante.\n- Du könntest die wiederholten `if/else`-Blöcke bei `fill`/`consume` etwas vereinfachen (z. B. erst rechnen, dann begrenzen), um Dopplungen zu vermeiden.\n\n\n# Exercise: pong\n\n### Correctness\n- Es fehlen die geforderten Klassen `Player` und `Ball` (mit den im Text verlangten Attributen wie Position, Balkenlänge/Punkte bzw. Geschwindigkeit).\n- In `PongGame` werden keine zwei `Player`-Objekte und kein `Ball`-Objekt erstellt/initialisiert (Ball in der Mitte, zufällige Anfangsgeschwindigkeit).\n- In der Spielschleife werden weder die Balken per Tastatur bewegt noch der Ball per Geschwindigkeit weiterbewegt (die Variablen `p1Up`/`p2Up` werden nur gelesen, aber nicht verwendet).\n- Kollisionen mit oberen/unteren Wänden (Ball abprallen; Player im Spielfeld halten) sind nicht implementiert.\n- Kollisionen Ball–Balken, Punktevergabe bei Verlassen links/rechts und Neustart des Balls in der Mitte sind nicht implementiert.\n- Die Erweiterung mit mehreren Bällen (Ball-Array, periodisches Hinzufügen, Entfernen beim Verlassen) ist nicht umgesetzt.\n- Gezeichnet werden aktuell nur Demo-Formen an festen Koordinaten statt der tatsächlichen Spielobjekte und des Punktestands.\n\n### Suggestion\n- Erstelle zuerst minimale `Player`- und `Ball`-Klassen mit genau den Daten, die im Auftrag stehen, und gib ihnen je eine Methode, um sich zeichnen zu lassen (damit du in b) schnell etwas siehst).\n- Initialisiere in `PongGame` zwei Player links/rechts und setze den Ball auf `(WIDTH/2, HEIGHT/2)`; für die zufällige Geschwindigkeit reicht es, zufällig Vorzeichen und einen sinnvollen Betrag für `vx`/`vy` zu wählen.\n- Nutze die Key-States (`w/s` und `up/down`), um pro Frame die `py` der Balken zu ändern; prüfe danach direkt, ob sie über den Rand hinaus ragen, und korrigiere.\n- Für Wandkollisionen oben/unten beim Ball: überprüfe pro Frame, ob Ball-Position ± Radius außerhalb ist; dann `vy` umdrehen und die Position zurück in den gültigen Bereich setzen.\n- Für Ball–Balken-Kollision: arbeite mit Rechtecken (Bounding-Boxen) oder mit Koordinatenchecks; wenn Überschneidung, kehre `vx` um und schiebe den Ball minimal aus dem Balken heraus, damit er nicht „kleben“ bleibt.\n- Für Punkte: erkenne, wenn der Ball links/rechts komplett raus ist; dann Punkt beim Gegenspieler erhöhen und den Ball (bzw. später: den jeweiligen Ball) neu in der Mitte starten lassen.\n- Für mehrere Bälle: verwalte ein Array plus eine Zahl „aktive Bälle“; halte die Invariante, dass die aktiven Bälle immer vorne im Array liegen, dann kannst du Entfernen durch „mit letztem aktiven ersetzen“ effizient machen.\n- Zeichnen: ersetze die festen `fillRect`/`fillCircle`-Aufrufe durch Zeichnen basierend auf den Objektpositionen; den Punktestand mit `drawString` ausgeben.\n\n### Code Style\n- Dein Code ist im Wesentlichen noch die unveränderte Vorlage; entferne die Demo-Zeichenaufrufe (festes Rechteck/Kreis), sobald du echte Objekte zeichnest, damit keine Verwirrung entsteht.\n- Die Variablen `p1Up`/`p2Up` sind aktuell ungenutzt; entweder direkt in `if (gui.isKeyPressed(...))` verwenden oder die Variablen konsequent für die Bewegungslogik einsetzen.\n\n\n# Exercise: stepstats\n\n### Correctness\n- `minSteps` und `maxSteps` bleiben bei `steps.length == 0` auf `Integer.MAX_VALUE` bzw. `Integer.MIN_VALUE`, was keine sinnvollen Statistikwerte sind (auch wenn du `avgSteps` dann nicht berechnest).\n- `StepTracker` ist nicht im Package `ch.fhnw.prog1.exercise.stepstats` (im Beispiel ist es dort), und es fehlen die nötigen Imports/Qualifizierungen für `Scanner` sowie für `IO` (so wie dein Code gerade dasteht, kompiliert er in einer normalen Java-Umgebung nicht).\n\n### Suggestion\n- Überlege dir, welchen Wert `minSteps`/`maxSteps` haben sollen, wenn es keine Tage gibt, und setze diese Felder in diesem Fall bewusst auf etwas Passendes statt auf die Initialisierungs-Sentinels.\n- Prüfe die vorgegebene Projekt-/Package-Struktur: `StepTracker` sollte in derselben Package-Struktur liegen wie in der Vorlage, und alle verwendeten Klassen (`Scanner`, `IO`) müssen entweder importiert oder voll qualifiziert werden.\n\n### Code Style\n- Die Felder sind alle `public`; überlege, ob ihr in der Aufgabe wirklich direkten Feldzugriff wollt oder ob `private` + Getter üblich wäre (je nach Vorgabe im Kurs). Hier ist es zwar kompatibel zur geforderten Nutzung, aber allgemein eher unüblich.\n- Einrückungen im `for`-Block sind etwas uneinheitlich (ein paar Zeilen sind weniger eingerückt), das erschwert das Lesen.\n",
"status" : "SUCCESS"
}
}