Neuer Kurs Godot 4 für Gestaltung & 2D-Prototypen mit Screenshots aus Editor und Spiel (LRN-23)

HANDBUCH.md

@@ -71,7 +71,7 @@ Eine vollständige, minimale Vorlage mit jeder Übungsart liegt in [`tooling/fix
 
 1. **Lehrplan entwerfen.** Schreibe zuerst die Liste der Module auf: 10–16 Module in 2–4 Tracks, vom Einstieg bis zum Profi-Niveau. Frage dich bei jedem Modul: *Was kann ich danach, was ich vorher nicht konnte?* Und: *Würde ein Arbeitgeber das erwarten?*
 2. **Ordner anlegen:** `content/<bereich>/` mit `area.yaml` (Abschnitt 4). Die Ordner-ID ist kurz, klein und kebab-case, zum Beispiel `go`, `typescript`, `devops`.
-3. **Farbe wählen.** Eine kräftige Farbe, auf der schwarzer Text gut lesbar ist (Kontrast ≥ 4,5 : 1 zu `#0B0B0B`). Vorhandene Farben nicht wiederholen: `#A98BFF` Kotlin, `#FF6A3D` Rust, `#FFD400` Linux, `#4D8BFF` Python, `#2BD97C` Automation, `#FF5CA8` Git, `#22D3EE` Data Analysis, `#C6F432` Testing, `#FF9F1C` PostgreSQL, `#F4A3FF` Erzählhandwerk, `#FF4D6D` Combat Design. Gute freie Kandidaten: `#FFC6A8` (Apricot), `#B5E3FF` (Eisblau).
+3. **Farbe wählen.** Eine kräftige Farbe, auf der schwarzer Text gut lesbar ist (Kontrast ≥ 4,5 : 1 zu `#0B0B0B`). Vorhandene Farben nicht wiederholen: `#A98BFF` Kotlin, `#FF6A3D` Rust, `#FFD400` Linux, `#4D8BFF` Python, `#2BD97C` Automation, `#FF5CA8` Git, `#22D3EE` Data Analysis, `#C6F432` Testing, `#FF9F1C` PostgreSQL, `#F4A3FF` Erzählhandwerk, `#FF4D6D` Combat Design, `#B5E3FF` Godot. Guter freier Kandidat: `#FFC6A8` (Apricot).
 4. **Module schreiben** (Abschnitte 5–7). Ein Modul pro Datei, Dateiname = Modul-ID.
 5. **Karten, Projekte, Glossar, Spickzettel, Berufsseite** ergänzen (Abschnitt 8).
 6. **Prüfen:** `pnpm content:check <bereich>`, dann `pnpm verify <bereich>`, dann `pnpm test` und `pnpm build`.
@@ -240,6 +240,20 @@ lesson: |
 
 Tabellen (GFM) sind erlaubt und im Spickzettel ausdrücklich erwünscht.
 
+### Bilder
+
+Screenshots und Abbildungen gehören dorthin, wo Text nicht reicht: ein Editor-Dock, das man wiedererkennen soll, ein Spielbild mit einem Darstellungsfehler, den man diagnostiziert. Sie gehen in Lektionen und in allen Markdown-Feldern der Übungen.
+
+```markdown
+![Inspektor eines Sprite2D mit Filter Linear: die Figur ist verwaschen](/media/godot/pixelraster/filter-linear@2x.png "Godot 4.7.2, Filter Linear, vierfach skaliert")
+```
+
+- **Ablage:** nur PNG unter `public/media/<bereich>/<modul>/`. Der Service Worker legt alle PNG-Dateien aus `public/` beim Installieren ab, Bilder gehen also offline. Halte sie klein (Pixelart und Editor-Ausschnitte als PNG mit wenigen Farben, meist unter 100 KB).
+- **Alt-Text ist Pflicht** und beschreibt, was zu sehen ist, auch das, worauf es ankommt. Der Titel in Anführungszeichen wird zur Bildunterschrift; nenne dort Quelle und Version.
+- **Größe:** Der Build liest Breite und Höhe aus der Datei, damit die Seite beim Laden nicht springt. Eine Datei `…@2x.png` hat doppelt so viele Pixel, wie sie anzeigt, und bleibt auf hochauflösenden Displays scharf. Ein Bild ist nie breiter als die Textspalte; ein Tipp öffnet es in voller Größe zum Zoomen. Gestalte Bilder für Unterwegs-Module deshalb so, dass sie bei 330 px Breite lesbar bleiben: lieber einen Ausschnitt als den ganzen Bildschirm.
+- **Prüfung:** `content:check` meldet fehlende Dateien und fehlende Alt-Texte als Fehler. Bilder von außerhalb (`https://…`) sind nicht erlaubt: Sie gingen offline nicht und könnten verschwinden.
+- Ein Bild allein in einem Absatz wird eine Abbildung mit Unterschrift; mitten im Text erscheint es als Block ohne Unterschrift.
+
 ## 7. Übungen
 
 Gemeinsame Felder aller Übungen:

README.md

@@ -1,6 +1,6 @@
 # learn.kiumu.app
 
-Private Lernplattform für Kotlin & Android, Rust, Linux, Python, Automation mit Python, Git, Data Analysis mit Excel, SQL und Python, Testing & Softwarequalität, SQL & PostgreSQL für Anwendungsentwickler sowie Combat Design & Game Feel mit Godot 4. Live: [learn.kiumu.app](https://learn.kiumu.app) · Öffentliches Repository: [hernstev97/learning-platform](https://github.com/hernstev97/learning-platform)
+Private Lernplattform für Kotlin & Android, Rust, Linux, Python, Automation mit Python, Git, Data Analysis mit Excel, SQL und Python, Testing & Softwarequalität, SQL & PostgreSQL für Anwendungsentwickler, Combat Design & Game Feel mit Godot 4 sowie Godot 4 für Gestaltung & 2D-Prototypen. Live: [learn.kiumu.app](https://learn.kiumu.app) · Öffentliches Repository: [hernstev97/learning-platform](https://github.com/hernstev97/learning-platform)
 
 Die Plattform ist kein Nachschlagewerk. Jedes Modul besteht aus einer Lektion, die ein Denkmodell aufbaut und auf die offizielle Dokumentation verweist, und aus 10–14 Übungen in fester Reihenfolge: verstehen → vorhersagen → schreiben → Fehler finden → erklären → anwenden. Jeder Bereich hat Interview-Karteikarten mit Wiederholung, Projekte und ein Abschlussprojekt, das wie eine Take-Home-Aufgabe im Bewerbungsprozess geschnitten ist.
 

content/combat/modules/frust-diagnose.yaml

@@ -117,7 +117,7 @@ lesson: |
 
   - **HitLog** mit Frame-Nummer für jeden Druck, jeden Zustandswechsel und jeden Treffer.
   - **Pause und Einzelbild**: F9 hält das Spiel im Game-Fenster an, F10 rückt einen Frame vor ([Game embedding](https://docs.godotengine.org/en/stable/tutorials/editor/game_embedding.html#frame-advance-f10)).
-  - **Kollisionsformen sichtbar** im Menü *Debug* ([Overview of debugging tools](https://docs.godotengine.org/en/stable/tutorials/scripting/debug/overview_of_debugging_tools.html#visible-collision-shapes)).
+  - **Sichtbare Collision-Shapes** im Menü *Debuggen* ([Overview of debugging tools](https://docs.godotengine.org/en/stable/tutorials/scripting/debug/overview_of_debugging_tools.html#visible-collision-shapes)).
   - **Movie Maker**: `--write-movie` nimmt mit fester Bildrate auf, als PNG wird jedes Bild eine Datei ([Creating movies](https://docs.godotengine.org/en/stable/tutorials/animation/creating_movies.html)). So siehst du einen Lauf später Bild für Bild an.
 
   Dein eigener Blick reicht nicht. Du kennst jeden Telegraph, also kannst du nicht prüfen, ob jemand ihn beim ersten Mal liest. Mike Ambinder rät für Valve, darauf zu achten, „what people do – not what they say“ ([Valve's Approach to Playtesting, PDF](https://cdn.fastly.steamstatic.com/apps/valve/2009/GDC2009_ValvesApproachToPlaytesting.pdf)). Eduardo Gorinstein, Combat Designer von Hades, sagt: „When I watch people play the game, they approach the fight in different ways“ ([DigiPen](https://digipen.edu/showcase/news/eduardo-gorinstein-delivers-challenge-and-fun-hades)).

content/combat/modules/godot-start.yaml

@@ -104,7 +104,7 @@ lesson: |
 
   ## Eine Figur, die in alle Richtungen läuft
 
-  Zuerst die Aktionen. Unter *Projekteinstellungen → Eingabezuordnung* (Input Map) legst du `move_left`, `move_right`, `move_up`, `move_down`, `attack` und `dodge` an und gibst jeder Taste und Gamepad-Eingabe: `move_right` bekommt etwa `D`, die Pfeiltaste rechts und *Linker Stick, X-Achse +*. Der Code fragt nur Aktionen ab, nie Tasten. Jede Aktion hat eine **Deadzone**, Standard 0,2: Stick-Ausschläge darunter zählen als 0 ([InputMap](https://docs.godotengine.org/en/stable/classes/class_inputmap.html#class-inputmap-method-add-action), [Input examples](https://docs.godotengine.org/en/stable/tutorials/inputs/input_examples.html)).
+  Zuerst die Aktionen. Unter *Projekteinstellungen → Eingabe-Zuordnung* (Input Map) legst du `move_left`, `move_right`, `move_up`, `move_down`, `attack` und `dodge` an und gibst jeder Taste und Gamepad-Eingabe: `move_right` bekommt etwa `D`, die Pfeiltaste rechts und *Linker Stick, X-Achse +*. Der Code fragt nur Aktionen ab, nie Tasten. Jede Aktion hat eine **Deadzone**, Standard 0,2: Stick-Ausschläge darunter zählen als 0 ([InputMap](https://docs.godotengine.org/en/stable/classes/class_inputmap.html#class-inputmap-method-add-action), [Input examples](https://docs.godotengine.org/en/stable/tutorials/inputs/input_examples.html)).
 
   Dann das Skript der Figur:
 
@@ -177,7 +177,7 @@ lesson: |
 
   ## Messen statt raten: Kollisionsformen, Einzelbild und Frame-Nummern
 
-  Drei Werkzeuge reichen für den Anfang. Im Menü *Debug* schaltest du **Kollisionsformen sichtbar** an; beim nächsten Start zeichnet Godot jede aktive Form farbig ([Overview of debugging tools](https://docs.godotengine.org/en/stable/tutorials/scripting/debug/overview_of_debugging_tools.html#visible-collision-shapes)). Im laufenden Spiel hält **Pause** (F9) alles an, und **Nächster Frame** (F10) rückt genau einen Frame vor ([Game embedding](https://docs.godotengine.org/en/stable/tutorials/editor/game_embedding.html#frame-advance-f10)). So siehst du Bild für Bild, wann die Hitbox erscheint. Und du schreibst in die Ausgabe, in welchem Physik-Frame etwas passiert:
+  Drei Werkzeuge reichen für den Anfang. Im Menü *Debuggen* schaltest du **Sichtbare Collision-Shapes** an; beim nächsten Start zeichnet Godot jede aktive Form farbig ([Overview of debugging tools](https://docs.godotengine.org/en/stable/tutorials/scripting/debug/overview_of_debugging_tools.html#visible-collision-shapes)). Im laufenden Spiel hält **Pause** (F9) alles an, und **Nächster Frame** (F10) rückt genau einen Frame vor ([Game embedding](https://docs.godotengine.org/en/stable/tutorials/editor/game_embedding.html#frame-advance-f10)). So siehst du Bild für Bild, wann die Hitbox erscheint. Und du schreibst in die Ausgabe, in welchem Physik-Frame etwas passiert:
 
   ```gdscript
   func _on_hitbox_area_entered(area: Area2D) -> void:

content/combat/modules/hitboxen.yaml

@@ -148,9 +148,9 @@ lesson: |
 
   ## Kollisionsebenen und Debug-Anzeige
 
-  Damit eine Hitbox nur die richtigen Flächen findet, liegt jede Fläche auf einer Ebene und scannt bestimmte andere. Die Godot-Doku fasst die Regel so: „Object A can detect a contact with object B only if object B is in any of the layers that object A scans.“ ([Collision layers and masks](https://docs.godotengine.org/en/stable/tutorials/physics/physics_introduction.html#collision-layers-and-masks)). In der Testszene liegt die Hurtbox der Figur auf Ebene 2, die des Gegners auf Ebene 3. Die Hitbox der Figur scannt Ebene 3, die des Gegners Ebene 2. So trifft kein Angriff die eigene Figur. Die Einrichtung Schritt für Schritt steht in [Testszene: Angriff mit Frame-Daten](/combat/testszene-angriff). Dreamscapers getrennte Prüfung für Gegner, Umgebung und Zerstörbares ließe sich in Godot mit einer Fläche je Ebene nachbauen.
+  Damit eine Hitbox nur die richtigen Flächen findet, liegt jede Fläche auf einer Ebene und scannt bestimmte andere. Die Godot-Doku fasst die Regel so: „Object A can detect a contact with object B only if object B is in any of the layers that object A scans.“ ([CollisionObject2D.collision_layer](https://docs.godotengine.org/en/stable/classes/class_collisionobject2d.html#class-collisionobject2d-property-collision-layer)). In der Testszene liegt die Hurtbox der Figur auf Ebene 2, die des Gegners auf Ebene 3. Die Hitbox der Figur scannt Ebene 3, die des Gegners Ebene 2. So trifft kein Angriff die eigene Figur. Die Einrichtung Schritt für Schritt steht in [Testszene: Angriff mit Frame-Daten](/combat/testszene-angriff). Dreamscapers getrennte Prüfung für Gegner, Umgebung und Zerstörbares ließe sich in Godot mit einer Fläche je Ebene nachbauen.
 
-  Sehen kannst du die Flächen im fertigen Spiel nicht. Manche Trainingsmodi von Kampfspielen zeigen sie, Hitboxen fast immer rot und Hurtboxen grün (Infil, [Hitbox](https://glossary.infil.net/?t=Hitbox)). In Godot schaltest du im Menü *Debug* **Kollisionsformen sichtbar** an ([Visible collision shapes](https://docs.godotengine.org/en/stable/tutorials/scripting/debug/overview_of_debugging_tools.html#visible-collision-shapes)). Mit Pause (F9) und Nächster Frame (F10) gehst du dann Bild für Bild durch einen strittigen Treffer und siehst gedrehte Hitboxen im aktiven Frame. Prüf am Frame-Zähler der Debug-Anzeige, wie weit ein Schritt geht.
+  Sehen kannst du die Flächen im fertigen Spiel nicht. Manche Trainingsmodi von Kampfspielen zeigen sie, Hitboxen fast immer rot und Hurtboxen grün (Infil, [Hitbox](https://glossary.infil.net/?t=Hitbox)). In Godot schaltest du im Menü *Debuggen* **Sichtbare Collision-Shapes** an ([Visible collision shapes](https://docs.godotengine.org/en/stable/tutorials/scripting/debug/overview_of_debugging_tools.html#visible-collision-shapes)). Mit Pause (F9) und Nächster Frame (F10) gehst du dann Bild für Bild durch einen strittigen Treffer und siehst gedrehte Hitboxen im aktiven Frame. Prüf am Frame-Zähler der Debug-Anzeige, wie weit ein Schritt geht.
 
   > [!PRAXIS]
   > Ist ein Treffer strittig, schau dir zuerst den aktiven Frame mit sichtbaren Formen an und ändere erst danach etwas. Ein Treffer ohne Kontakt im Bild kann gewollt sein: Dreamscaper nimmt ihn bei Spielerangriffen bewusst in Kauf und hält die Gegner-Hitboxen präzise. Schreib in jede Vorgabe für einen Coding-Agenten Form, Größe und Lage jeder Fläche relativ zur Figurenmitte und die Ebenen, die sie scannt.

content/combat/modules/testszene-angriff.yaml

@@ -188,7 +188,7 @@ lesson: |
   	return get_parent().take_hit(attack, source, self)
   ```
 
-  Damit nur gewollte Paare sich finden, benennst du unter *Projekteinstellungen → Ebenennamen → 2D-Physik* drei Ebenen und setzt Ebene (`collision_layer`) und Maske (`collision_mask`) so ([Collision layers and masks](https://docs.godotengine.org/en/stable/tutorials/physics/physics_introduction.html#collision-layers-and-masks)):
+  Damit nur gewollte Paare sich finden, benennst du unter *Projekteinstellungen → Ebenen-Namen → 2D-Physik* drei Ebenen und setzt Ebene (`collision_layer`) und Maske (`collision_mask`) so ([Collision layers and masks](https://docs.godotengine.org/en/stable/tutorials/physics/physics_introduction.html#collision-layers-and-masks)):
 
   | Node | Ebene | Maske | Einstellung |
   | --- | --- | --- | --- |
@@ -383,7 +383,7 @@ lesson: |
   	text = "%s  Frame %d  Puffer: %s\n%s" % [player.state_name(), player.frame, buffer, "\n".join(HitLog.lines.slice(-3))]
   ```
 
-  Zusammen mit *Debug → Kollisionsformen sichtbar* und dem Einzelbild-Schritt (F10) siehst du jetzt bei jedem Treffer, welcher Zustand, welcher Frame und welcher Puffer im Spiel war.
+  Zusammen mit *Debuggen → Sichtbare Collision-Shapes* und dem Einzelbild-Schritt (F10) siehst du jetzt bei jedem Treffer, welcher Zustand, welcher Frame und welcher Puffer im Spiel war.
 
   ### Eingaben nach Drehbuch
 

content/combat/projects.yaml

@@ -58,7 +58,7 @@ projects:
         detail: Spielfigur mit `player.gd`, Dummy mit `enemy.gd`, drei benannte Ebenen, Hitbox und Hurtbox nach der Tabelle aus der Lektion.
       - id: log-und-anzeige
         title: HitLog und Debug-Anzeige
-        detail: Autoload `HitLog`, Debug-Label im `CanvasLayer`, Kollisionsformen sichtbar. Jeder Tastendruck und jeder Zustandswechsel steht mit Frame-Nummer in der Ausgabe.
+        detail: Autoload `HitLog`, Debug-Label im `CanvasLayer`, „Sichtbare Collision-Shapes“ an. Jeder Tastendruck und jeder Zustandswechsel steht mit Frame-Nummer in der Ausgabe.
       - id: referenz-angriff
         title: Referenzlauf Angriff
         detail: Mit den Platzhalterwerten einmal treffen. Die Abstände im Log müssen der Lektion entsprechen (8 Frames bis `ACTIVE`, Treffer einen Frame danach, `RECOVERY` 7 Frames nach `ACTIVE`, `MOVE` 14 danach).

content/godot/area.yaml

@@ -0,0 +1,34 @@
+id: godot
+title: Godot 4 für Gestaltung & 2D-Prototypen
+short: Godot
+tagline: Ein Projekt, das eine KI gebaut hat, im Editor lesen, mit eigenen Assets füllen und abstimmen.
+description: >
+  Editor, Szenen, Nodes, Ressourcen und Instanzen, eigene Sprites, Animationen, Tiles und Sounds,
+  Kollisionen, Eingabeaktionen und Parameter, Bildrate und Simulation, Debugger, Profiler und Export –
+  mit Godot 4.7. Code und technisches Gerüst darf eine KI liefern; du liest es, stellst es ein und
+  triffst jede gestalterische Entscheidung selbst. Wo es passt, knüpft der Kurs an deine
+  Erfahrung aus der Webentwicklung an. Module mit der Marke „Unterwegs“ gehen ganz am Handy, auch offline, mit Screenshots aus Editor
+  und Spiel. „Am PC“ braucht Godot am Rechner; lesen kannst du diese Lektionen auch unterwegs.
+color: "#B5E3FF"
+order: 12
+outcomes:
+  - "Du **liest ein fremdes Godot-Projekt**: Hauptszene, Szenenbaum, Instanzen, Ressourcen, Signale und Autoloads, im Editor und zur Laufzeit im Remote-Baum."
+  - Du **importierst eigene Pixelart** scharf und im richtigen Raster, zerlegst Spritesheets, setzt Ursprünge und ordnest Animationen und Töne zu.
+  - Du erklärst, was zwischen **Spielauflösung und Bildschirm** passiert, und diagnostizierst unscharfe, ungleichmäßige oder zitternde Pixel an Screenshots.
+  - Du stellst **Kollisionen, Layer und Masken, Eingabeaktionen und exportierte Parameter** ein und sagst vorher, was eine Änderung bewirkt.
+  - Du baust **2D-Level mit TileMapLayer** und Y-Sortierung aus eigenen Tiles.
+  - Du **grenzt Probleme ein** – Bildrate oder Simulation, Import, Kollision, Skalierung – mit Debugger, Monitoren und Profiler.
+  - Du **exportierst Testversionen** und sicherst Projekt und Originaldateien nachvollziehbar in Git.
+tracks:
+  - title: Den Editor lesen
+    description: Docks und Projektordner, Szenenbäume, Instanzen und Ressourcen. Am PC erkundest du ein Projekt und baust das Testgelände auf, an dem der Kurs arbeitet.
+    modules: [editor-anatomie, szenenbaum, instanzen-ressourcen, projekt-erkunden]
+  - title: Eigene Assets
+    description: Pixelraster und Skalierung verstehen, dann eigene Sprites importieren, Animationen und Töne zuordnen.
+    modules: [pixelraster, sprites-importieren, animationen, audio]
+  - title: Welt und Systeme abstimmen
+    description: Kollisionen und Masken, Eingabeaktionen und Parameter, Level aus Tiles.
+    modules: [kollision-ebenen, aktionen-parameter, level-tilemap]
+  - title: Messen und ausliefern
+    description: Bildrate und Simulation, Fehler eingrenzen mit Debugger und Profiler, Testversionen exportieren und sichern, zum Schluss vorhersagen, ändern und messen im eigenen Testgelände.
+    modules: [bildrate-simulation, fehler-eingrenzen, export-sichern, werkstatt-messen]