{
"llm" : {
"feedback" : "# Exercise: todo\n\n### Correctness\n- Die Ausgabe eines einzelnen Tasks entspricht nicht dem geforderten Format aus dem Beispiel (dort z. B. `\" ✓ [0] Waschen\"` bzw. `\" [1] Lernen\"`); bei dir ist es aktuell `\"[x] 0: Waschen\"`/`\"[ ] 1: Lernen\"` (anderes Symbol, andere Reihenfolge/Zeichen, Doppelpunkt).\n- In `markTaskDone` ist die Fehlermeldung nicht exakt wie verlangt: gefordert ist `\"Task with ID XX not found\"` (mit der ID eingesetzt), du gibst `\"Task with ID \" + id + \" not found\"` aus (anderer Wortlaut/Format).\n\n### Suggestion\n- Schau dir das gewünschte Konsolen-Beispiel sehr genau an (inkl. Leerzeichen/Einrückung) und leite daraus ab, wie `toString()` genau aufgebaut sein muss (wo stehen Häkchen/Spaces, wo die ID in eckigen Klammern, ob ein Doppelpunkt vorkommt, etc.).\n- Orientiere dich beim “not found”-Text strikt am Methodenkommentar: gleiche Wörter, gleiche Reihenfolge; ersetze nur das `XX` durch die konkrete ID.\n\n### Code Style\n- `listTasks` iteriert immer über das ganze 100er-Array; lesbarer/effizienter wäre es, nur über den tatsächlich benutzten Bereich zu laufen (z. B. indem du eine Zählvariable für belegte Einträge pflegst).\n- `addTask` macht stillschweigend nichts, wenn das Array voll ist; zumindest ein Hinweis/Output wäre hilfreich, damit man als Nutzer versteht, warum kein Task mehr hinzugefügt wird.\n- Achte auf konsistente Sichtbarkeiten/Struktur: Deine `Task`-Klasse hängt am Ende der Datei ohne klaren Klassenabschluss im Snippet; in Java ist es üblich, entweder eine separate Datei `Task.java` zu haben oder eine sauber geschlossene (z. B. `static`) innere Klasse.\n\n\n# Exercise: energymeter\n\n### Correctness\n- Die Methode `consume` verwendet als Parametername `capacity`, wodurch die Klassenvariable `capacity` verdeckt wird; laut Aufgabenbeschreibung soll der erste Parameter aber die *Intensität/Kapazität pro Zeit* darstellen (nicht die Meter-Kapazität). Das ist inhaltlich irreführend und kann zu falscher Verwendung/Interpretation in den Tests führen.\n- `percentFull()` liefert bei `level == 0` und `capacity > 0` den Wert `level` zurück (also `0`), was zwar zufällig passt, aber die Logik ist nicht konsistent mit „Prozent voll“ (du gibst dort nicht „0 Prozent“ zurück, sondern „0 Energie“ – bei anderen Werten würde das nicht funktionieren).\n- `percentFull()` berechnet am Ende `100 / (capacity / level)`. Wenn `capacity == 0` und `level > 0`, führt das zu einer Division durch 0 (ergibt `Infinity`), statt einen sinnvollen Prozentwert zu liefern.\n\n### Suggestion\n- Benenne den ersten Parameter von `consume` so, dass klar wird, dass es um „Intensität“ (Verbrauch pro Zeit) geht, und nicht um die Meter-`capacity`. Achte dabei darauf, dass deine Klassenvariable `capacity` nicht aus Versehen verdeckt wird.\n- Überlege bei `percentFull()`, was „Prozent voll“ mathematisch bedeutet: Es sollte in allen Fällen ein Prozentwert sein (0–100 oder ggf. auch >100, je nach Spezifikation), nicht manchmal Energie und manchmal Prozent.\n- Behandle den Spezialfall `capacity == 0` in `percentFull()` unabhängig davon, ob `level` 0 ist oder nicht, damit keine Division durch 0 passieren kann.\n\n### Code Style\n- Die Attribute sind `public`; üblich (und meist auch in solchen Übungen erwartet) sind nicht-öffentliche Felder mit Zugriff über Methoden, damit der Zustand nicht von außen beliebig verändert werden kann.\n- Vermeide gemischte/unklare Benennungen (`energie`, `durance`, Parameter `capacity` in `consume`): einheitliche Sprache und fachlich passende Namen machen den Code deutlich verständlicher.\n- Deine Exception-Meldungen sind ok, aber für Unit-Tests oft egal; wichtig ist eher konsistentes Verhalten (und ggf. dass überhaupt die erwartete Exception kommt).\n\n\n# Exercise: pong\n\n### Correctness\n- In Teil f) soll „immer nach **einer bis zwei Sekunden**“ ein neuer Ball hinzukommen; bei dir ist das Intervall konstant (`SPAWN_INTERVAL = 75`), also nicht zufällig variierend.\n- Wenn der Ball oben/unten abprallt, korrigierst du die Position nicht zurück ins Spielfeld (du invertierst nur `vy`). Dadurch kann der Ball je nach Schrittweite kurz „in der Wand stecken“ und im nächsten Frame erneut flippen (sichtbares Flackern bzw. doppeltes Abprallen).\n- Bei der Kollision Ball↔Paddle prüfst du nur, ob `ball.y` innerhalb des Paddle-Bereichs liegt, aber ignorierst den Ballradius (die Ballkante kann das Paddle treffen, obwohl der Mittelpunkt noch außerhalb liegt).\n\n### Suggestion\n- Für Teil f): Überlege dir, wie du beim Spawnen jedes Mal eine zufällige Wartezeit in Frames bestimmen kannst (z.B. Bereich entsprechend 1–2 Sekunden bei 50 FPS) und diese dann herunterzählst statt einen festen Zähler zu verwenden.\n- Für Wandkollisionen: Nach dem Umdrehen von `vy` setze `ball.y` so, dass der Ball gerade noch innerhalb des Spielfelds liegt (unter Berücksichtigung von `radius`), damit er nicht im nächsten Schritt sofort wieder als „außerhalb“ erkannt wird.\n- Für Paddle-Kollision: Denke daran, dass die Kollision geometrisch mit dem Kreis passiert – d.h. die y-Prüfung sollte auch die Ausdehnung des Balls berücksichtigen (nicht nur den Mittelpunkt).\n\n### Code Style\n- In `Ball` und `Player` sind sehr viele Felder `public`; besser kapseln (z.B. `private` + Methoden), damit du Invarianten (Spielfeldgrenzen, Kollisionslogik) nicht überall im Code „von außen“ brechen kannst.\n- In `PongGame` fehlt ein `package`-Statement, obwohl deine anderen Klassen in `ch.fhnw.prog1.exercise.pong` liegen; das führt je nach Projektsetup schnell zu inkonsistenten Imports/Struktur.\n- `drawString(p1.score + \" : \" + p2.score, WIDTH / 2 - 20, 20)` ist „magisch“ verschoben; nutze lieber GUI-Textausrichtung (oder eine klar benannte Konstante), damit die Anzeige bei anderen Scores/Fonts stabil bleibt.\n- Du importierst `Ball`/`Player` explizit, obwohl du sie (wahrscheinlich) im selben Package haben möchtest; mit konsistenter Package-Struktur könnten unnötige Imports entfallen.\n\n\n# Exercise: stepstats\n\n### Correctness\n- In der Aufgabenstellung wird die Verwendung mit `stats.averageSteps` gezeigt, aber im Text steht `double avgSteps = stats.averageSteps;` und in der Beispiel-Lösung heisst das Feld `avgSteps`; falls die Tests/Checker exakt `avgSteps` erwarten, passt dein Attributname `averageSteps` nicht zur erwarteten API.\n\n### Suggestion\n- Schau in die Vorlage/Tests bzw. in die genaue Aufgabenformulierung, welche Attributnamen wirklich gefordert sind (z. B. `avgSteps` vs. `averageSteps`) und richte deine Feldnamen exakt danach aus.\n\n### Code Style\n- In `StepTracker.java` fehlen in deinem Snippet `package`-Deklaration sowie Imports (z. B. `java.util.Scanner`); falls du das im Projekt hast, ok—sonst darauf achten, dass die Datei so kompiliert.\n- Du mischst `IO.println` mit `Scanner` (statt konsistent `System.out` wie in der Beispiel-Lösung); ist nicht falsch, aber inkonsistent und kann je nach Vorlage zu Verwirrung führen.\n",
"status" : "SUCCESS"
}
}