clean-up: remove dungeon from homework (#1047)

Der Dungeon bzw. der DevDungeon sollte eigentlich das Narrativ für diese
Veranstaltung bilden. Es stellt sich leider immer stärker heraus, dass
dies nicht wirklich realistisch ist:

- Abhängigkeit zu libGDX und Hardware/Betriebssystem: Im _Prinzip_
sollte alles über Gradle aufgelöst werden - aber in der Praxis hakelt es
immer wieder, vor allem unter Windows. Da es bei den Übungen um eine
Prüfungsleistung geht, muss nur _ein_ Student mit Problemen kommen und
das Ding hat sich erledigt. Dazu kommt, dass ich keinen Support für
Linux und/oder Windows leisten kann.
- Komplexität der API: Von ferne betrachtet ist es entspannt: Gameloop,
Systems, Components. Je näher man aber kommt, um so verschachtelter und
komplexer und leider auch wirrer wird es. Wenn man selbst was umsetzen
möchte, kopiert man entweder existierende Dinge oder steht (als
Zweitsemestler) auf dem Schlauch. Eine schöne Illustration zu John
Ousterhout's Anti-Pattern "breite Interfaces, flache Klassen" (und das
noch hübsch verschachtelt).
- Dokumentation: Dort wo vorhanden, wird häufig nur das über den Code
bereits offensichtliche wiedergegeben. Es fehlen Erklärungen zum
Kontext, zu den Designentscheidungen, zum Einsatz, ...
- Die Aufgaben im DevDungeon sind schön und interessant. Die Studis
werden gezwungen, den Code zu lesen und zum Lösen der Aufgabe müssen sie
gar nicht mal so viel Code schreiben. Dennoch ist das Feedback nicht
sooo gut: Die Studis müssen einen relativ großen Aufwand treiben, um am
Ende einen Heiltrank oder so zu haben. Passt zum späteren Leben, aber
zum Üben bestimmter Konzepte ist das Overhead. Eigentlich wäre der
nächste Schritt, dass die Studis selbst ein Level bzw. Rätsel
definieren, aber angesichts der API und der Dokumentation ist das im
zweiten Semester eher aussichtslos. Die Erfahrung im Projekt zeigt, dass
man mehrere Wochen bis Monate angeleitet arbeiten muss, bis man selbst
Dinge hinbekommt. Da ist das Semester aber schon rum. Zudem waren die
Erfahrungen im ersten Lauf ernüchternd, da die wenigsten genug Phantasie
für konkrete Spielideen entwickeln und so immer nur das gleiche Monster
eben anders angepinselt wurde.
- Code-Qualität: Die Architektur und die API sind über weite Strecken
implementierungsgetrieben und ohne erkennbare Recherche zum Stand der
Technik entstanden. Es gibt immer wieder richtig gute Bausteine, aber
insgesamt ist das Projekt taktisch entwickelt worden. Nach dem Ende der
Projekte wird niemand freiwillig die Maintenance oder sogar
Weiterentwicklung übernehmen.

Dennoch eignet sich das Dungeon-Projekt an vielen Stellen als
Studienobjekt (Commit-Messages, Dokumentation, API-Gestaltung, Tests,
...). Das sollte ausgebaut werden.


closes #1046

Author: cagix

homework/b04.md

@@ -1,8 +1,7 @@
 ---
 author: Carsten Gips (HSBI)
 no_beamer: true
-title: "Blatt 04: Stream-API & Damaged Bridge (Git Remote, Streams,
-  Lambda-Ausdrücke)"
+title: "Blatt 04: Stream-API (Git Remote, Streams, Lambda-Ausdrücke)"
 ---
 
 # Zusammenfassung
@@ -136,52 +135,6 @@ einen Starter für diese vierte Teilaufgabe.
 
 Machen Sie aus der Klasse `streamapi.Student` eine Record-Klasse.
 
-## DevDungeon: Zerbrechende Tiles und Speed Potions (Lambda-Ausdrücke)
-
-Klonen Sie das Projekt
-[DevDungeon](https://github.com/Dungeon-CampusMinden/dev-dungeon) und laden Sie es
-in Ihrer IDE als Gradle-Projekt. Betrachten Sie das Sub-Projekt[^1] "devDungeon".
-Dies ist ein von einem Studierenden ([\@Flamtky](https://github.com/Flamtky))
-erstelltes Spiel mit mehreren Leveln, in denen Sie spielerisch verschiedene Aufgaben
-*in-game* und *ex-game* lösen müssen.
-
-Starten Sie den DevDungeon mit `./gradlew devDungeon:runDevDungeon`. Spielen Sie
-sich für diese Aufgabe durch das **erste Level** ("Damaged Bridge")[^2].
-
-Ziel ist es, die mysteriöse Brücke in der Mitte des ersten Levels lebendig zu
-überqueren. Beobachten Sie die Startsequenz: Was fällt ihnen an dem Monster auf,
-dass Sie ganz am Anfang angreifen will? Sie finden weitere Hinweise in den
-Briefkästen und über die Popups ... Beachten Sie auch die Hinweise am versteckten
-Item. Um dieses nutzbar zu machen, müssen Sie in den Java-Code des Spiels gehen (im
-`src/`-Unterordner im Sub-Projekt "devDungeon") und den Effekt für das Item
-reparieren (implementieren). Analysieren Sie den Code für das Item und seinen
-Effekt, und schauen Sie sich die anderen Effekte im selben Package an. Schreiben Sie
-nun Code für die mit "TODO" markierte Methode des Effekts. Starten Sie dann das
-Spiel neu und schauen Sie, ob das Item nun funktioniert.
-
-**WICHTIG**: **Bevor** Sie mit der Implementierung beginnen, schauen Sie sich bitte
-die Einführung in die Programmierung des Dungeons und die verwendete
-*Entity-Component-System*-Architektur in der Lektion [Intro
-Dungeon](../lecture/misc/dungeon.md) an. Dort werden Ihnen Hintergründe zum Dungeon
-und der für diese Aufgabe relevanten Component erklärt.
-
-**Hinweis**: Sie können das Demo-Level deaktivieren, indem Sie in der Klasse
-`starter.DevDungeon` das Flag `SKIP_TUTORIAL` auf den Wert `true` setzen. Damit
-gelangen Sie direkt in das in dieser Aufgabe relevante Level.
-
-**Hinweis**: Aktuell ist das Projekt DevDungeon an einigen Stellen noch
-*Work-in-Progress*, beispielsweise fehlt häufig noch die Javadoc. Alle Gradle-Tasks,
-die von Checkstyle-Tasks abhängen (`checkstyleMain`, `check`, `build`, ...) werden
-deshalb fehlschlagen. Sie können den DevDungeon aber wie oben beschrieben mit
-`./gradlew devDungeon:runDevDungeon` (bzw. über den Task `devDungeon:runDevDungeon`
-aus der IDE heraus) starten.
-
-**WICHTIG**: Achten Sie bitte darauf, dass im Projektpfad **keine Leerzeichen** und
-keine Sonderzeichen (Umlaute o.ä.) vorkommen! Dies kann zu seltsamen Fehler führen.
-Bitte auch darauf achten, dass Sie als JDK ein **Java SE 21 (LTS)** verwenden. Unter
-Windows ist der Einsatz von
-[WSL](https://learn.microsoft.com/en-us/windows/wsl/install) empfehlenswert.
-
 # Bearbeitung und Abgabe
 
 -   Bearbeitung: Einzelbearbeitung oder bis zu 3er Teams
@@ -211,21 +164,3 @@ Windows ist der Einsatz von
 
     -   Deadline: 23. Mai, 08:00 Uhr
 -   Vorstellung im Praktikum: 23. Mai
-
-[^1]: Gradle-Subprojekte sind im Prinzip mehrere Java-Projekte in einem gemeinsamen
-    Repository mit einer gemeinsamen Gradle-Basiskonfiguration. Jedes Sub-Projekt
-    hat dann noch einmal eine eigene, die Basiskonfiguration verfeinernde
-    Gradle-Konfiguration. Da jedes Sub-Projekt eigene Tasks mitbringen kann, muss
-    denn der Name des Sub-Projekts dem Tasknamen vorangestellt werden:
-    Beispielsweise muss statt `./gradlew runDevDungeon` nun
-    `./gradlew devDungeon:runDevDungeon` aufgerufen werden. Siehe auch
-    [Multi-Project Build
-    Basics](https://docs.gradle.org/current/userguide/intro_multi_project_builds.html)
-    oder [Structuring Projects with
-    Gradle](https://docs.gradle.org/current/userguide/multi_project_builds.html).
-
-[^2]: Das erste richtige Level, also das erste Level *nach* dem Demo-Level. Das
-    Demo-Level zeigt Ihnen, wie Sie das Spiel bedienen können. Zusätzlich gibt es
-    die kurze [Anleitung "How to
-    play"](https://github.com/Dungeon-CampusMinden/Dungeon/blob/master/dungeon/doc/how_to_play.md)
-    ...

homework/b05.md

@@ -1,8 +1,7 @@
 ---
 author: Carsten Gips (HSBI)
 no_beamer: true
-title: "Blatt 05: Torch Riddle & Katzen-Café (Streams, JUnit, Optional\\<\\>,
-  Visitor)"
+title: "Blatt 05: Katzen-Café (Streams, JUnit, Optional\\<\\>, Visitor)"
 ---
 
 # Zusammenfassung
@@ -25,45 +24,6 @@ Die Links zu Ihren Pull-Requests mit den Lösungen geben Sie bitte immer in Ihre
 
 # Aufgaben
 
-## DevDungeon: Fackeln im Sturm (Umgang mit `Optional<>` und Streams)
-
-Klonen Sie das Projekt
-[DevDungeon](https://github.com/Dungeon-CampusMinden/dev-dungeon) und laden Sie es
-in Ihrer IDE als Gradle-Projekt. Betrachten Sie das Sub-Projekt "devDungeon". Dies
-ist ein von einem Studierenden ([\@Flamtky](https://github.com/Flamtky)) erstelltes
-Spiel mit mehreren Leveln, in denen Sie spielerisch verschiedene Aufgaben *in-game*
-und *ex-game* lösen müssen.
-
-Starten Sie den DevDungeon mit `./gradlew devDungeon:runDevDungeon`. Spielen Sie
-sich für diese Aufgabe durch das **zweite Level** ("Torch Riddle")[^1].
-
-Sie befinden sich in einem Raum mit Fackeln, welche Sie per Interaktion an- und
-ausschalten können. Neben jeder Fackel ist ein Briefkasten, der der Fackel einen
-Zahlenwert zuordnet. Irgendwo führt eine Tür zu einem zunächst versteckten Raum mit
-einer Belohnung - aber diese Tür geht erst auf, wenn Sie (a) die richtigen Fackeln
-an- bzw. ausgeschaltet haben, und wenn Sie (b) die defekte Methode
-`TorchRiddleRiddleHandler#getSumOfLitTorches` (im Package
-`level.devlevel.riddleHandler`) korrekt implementiert haben. Beachten Sie die
-entsprechenden Hinweise im Javadoc der Methode.
-
-Das Tor zum nächsten Level geht unabhängig davon erst auf, wenn Sie den
-Boss-Gegner[^2] in diesem Level besiegt haben ... Hierzu ist *keine* Programmierung
-notwendig, lediglich geschicktes Spielen und gegebenenfalls rechtzeitiges Trinken
-von (dann hoffentlich vorhandenen) Heil-Tränken.
-
-**Hinweis**: Aktuell ist das Projekt DevDungeon an einigen Stellen noch
-*Work-in-Progress*, beispielsweise fehlt häufig noch die Javadoc. Alle Gradle-Tasks,
-die von Checkstyle-Tasks abhängen (`checkstyleMain`, `check`, `build`, ...) werden
-deshalb fehlschlagen. Sie können den DevDungeon aber wie oben beschrieben mit
-`./gradlew devDungeon:runDevDungeon` (bzw. über den Task `devDungeon:runDevDungeon`
-aus der IDE heraus) starten.
-
-**WICHTIG**: Achten Sie bitte darauf, dass im Projektpfad **keine Leerzeichen** und
-keine Sonderzeichen (Umlaute o.ä.) vorkommen! Dies kann zu seltsamen Fehler führen.
-Bitte auch darauf achten, dass Sie als JDK ein **Java SE 21 (LTS)** verwenden. Unter
-Windows ist der Einsatz von
-[WSL](https://learn.microsoft.com/en-us/windows/wsl/install) empfehlenswert.
-
 ## Katzen-Café
 
 Forken Sie das
@@ -153,8 +113,3 @@ Fügen Sie passende Aufrufe der beiden Visitoren in `Main#main` hinzu.
 
     -   Deadline: 30. Mai, 08:00 Uhr
 -   Vorstellung im Praktikum: 30. Mai
-
-[^1]: Das zweite richtige Level, also das zweite Level *nach* dem Demo-Level. Oder
-    eben das dritte Level, wenn man das Demo-Level mitzählt :-)
-
-[^2]: ... sieht aus wie eine wandelnde Kerze ...

homework/b07.md

@@ -1,7 +1,7 @@
 ---
 author: Carsten Gips (HSBI)
 no_beamer: true
-title: "Blatt 07: Bike-Shop & Illusion Riddle (Refactoring, Javadoc)"
+title: "Blatt 07: Bike-Shop (Refactoring, Javadoc)"
 ---
 
 # Zusammenfassung
@@ -34,108 +34,6 @@ an.
 Diskutieren Sie jeweils, was Ihnen an der Dokumentation dieser Klasse auffällt: Was
 gefällt Ihnen, was stört Sie? Schlagen Sie Verbesserungen vor.
 
-## DevDungeon: Illusion Riddle
-
-Klonen Sie das Projekt
-[DevDungeon](https://github.com/Dungeon-CampusMinden/dev-dungeon) und laden Sie es
-in Ihrer IDE als Gradle-Projekt. Betrachten Sie das Sub-Projekt "devDungeon". Dies
-ist ein von einem Studierenden ([\@Flamtky](https://github.com/Flamtky)) erstelltes
-Spiel mit mehreren Leveln, in denen Sie spielerisch verschiedene Aufgaben *in-game*
-und *ex-game* lösen müssen.
-
-### DevDungeon: Lösen des Illusion Riddle
-
-Starten Sie den DevDungeon mit `./gradlew devDungeon:runDevDungeon`. Spielen Sie
-sich für diese Aufgabe durch das **dritte Level** ("Illusion Riddle")[^1].
-
-In diesem Level gibt es mehrere Räume, die durch Teleporter (statt Türen)
-miteinander verbunden sind. Beim Betreten dieser nur schwer erkennbaren dunkleren
-Bodenkacheln werden Sie in den nächsten Raum transportiert. Während dieser
-Mechanismus deterministisch ist, gibt es zusätzlich eine neue Monster-Art, die Sie
-mit fischähnlich aussehenden Geschossen angreift und bei einem Treffer in einen
-zufälligen Raum transportiert.
-
-Im Level sind insgesamt drei Schalter verborgen, von denen Sie mindestens zwei
-finden und betätigen müssen, damit die weiteren Übergänge freigeschaltet werden. Die
-Reihenfolge spielt dabei keine Rolle.
-
-Leider ist durch den starken *Fog of War* kaum etwas zu sehen. Auch die vielen
-Fackeln verbessern die Sicht nicht wirklich. Können Sie mit diesen Fackeln irgendwie
-interagieren?
-
-Ziel ist es, den Weg zum letzten Raum des Levels zu finden und den dort wartenden
-Boss-Gegner zu besiegen.
-
-*Tipp*: Es könnte hilfreich sein, sich eine Skizze der Räume anzufertigen. Diese
-sind in diesem Level bei jedem Start identisch.
-
-*Tipp*: Es könnte in einem bestimmten Raum hilfreich sein, mehrfach im Kreis zu
-laufen ...
-
-*Tipp*: Eine Code-Analyse könnte helfen. Vielleicht können Sie durch Anpassungen im
-Code die Sicht verbessern oder die Gesundheit Ihres Helden verbessern oder die
-Teleportationsgeschosse unschädlich machen? Streng genommen ist das natürlich
-*cheaten*, aber da Sie ja Code lesen und anpassen üben, können wir im Rahmen dieser
-Lehrveranstaltung darüber hinwegsehen. Erklären Sie im Praktikum, welche Änderungen
-Sie wo und warum vorgenommen haben und was das bewirkt.
-
-**Hinweis**: Aktuell ist das Projekt DevDungeon an einigen Stellen noch
-*Work-in-Progress*, beispielsweise fehlt häufig noch die Javadoc. Alle Gradle-Tasks,
-die von Checkstyle-Tasks abhängen (`checkstyleMain`, `check`, `build`, ...) werden
-deshalb fehlschlagen. Sie können den DevDungeon aber wie oben beschrieben mit
-`./gradlew devDungeon:runDevDungeon` (bzw. über den Task `devDungeon:runDevDungeon`
-aus der IDE heraus) starten.
-
-**WICHTIG**: Achten Sie bitte darauf, dass im Projektpfad **keine Leerzeichen** und
-keine Sonderzeichen (Umlaute o.ä.) vorkommen! Dies kann zu seltsamen Fehler führen.
-Bitte auch darauf achten, dass Sie als JDK ein **Java SE 21 (LTS)** verwenden. Unter
-Windows ist der Einsatz von
-[WSL](https://learn.microsoft.com/en-us/windows/wsl/install) empfehlenswert.
-
-### DevDungeon: Refactoring der Klasse IllusionRiddleLevel
-
-Analysieren Sie die Klasse `IllusionRiddleLevel` im Package `level.devlevel`,
-insbesondere die beiden Methoden `IllusionRiddleLevel#onTick` und
-`IllusionRiddleLevel#lightTorch`:
-
-1.  Welche *Bad Smells* können Sie hier identifizieren?
-
-2.  Beheben Sie die Smells durch die **schrittweise Anwendung** von den aus der
-    Vorlesung bekannten Refactoring-Methoden. Ergänzend zu der Übersicht aus der
-    Vorlesung finden sie unter [Refactoring
-    Guru](https://refactoring.guru/refactoring/techniques) eine erweiterte
-    Darstellung gängiger Refactoring-Techniken.
-
-    Machen Sie pro Refactoring-Schritt einen Commit, und halten Sie alle Commits in
-    einem Pull-Request fest. An diesem können Sie im Praktikum Ihr Vorgehen
-    vorstellen.
-
-*Tipp*: Schauen Sie schlechter Namensgebung, nach redundantem Code, nach übermäßig
-komplexer Logik, nach Code/Logik in der falschen Klasse (am falschen Ort), nach
-übermäßig vielen Parametern, nach fehlendem Javadoc, ....
-
-**Hinweis**: Normalerweise erstellen Sie eine Testsuite, bevor Sie mit dem
-Refactoring beginnen. Leider ist durch die Abhängigkeit zu libGDX und der Game-Loop
-das Testen im (Dev-) Dungeon nicht trivial, so dass Sie hier ausnahmsweise direkt
-mit dem Refactoring loslegen dürfen und auf das Erstellen einer Testsuite verzichten
-können.
-
-### Protector-Skill für Ihren Hero
-
-Erstellen Sie einen neuen Protector-Skill für den Hero und weisen Sie diesen einer
-Taste zu. Bei Nutzung des Skills soll ein neues Protector-Monster an einer
-zufälligen Position in einem bestimmten Radius um den Helden erzeugt werden. Das
-Protector-Monster sucht das räumlich nächste Monster, nähert sich diesem automatisch
-bis auf Angriffsdistanz und greift dieses dann so lange mit Feuerbällen an, bis
-eines der beiden Monster keine Lebenspunkte mehr hat. Der Skill soll einen Cool-Down
-haben, d.h. er soll erst nach einer gewissen Zeit erneut benutzbar sein.
-
-Nutzen Sie diesen neuen Skill im **dritten Level** ("Illusion Riddle") und schauen
-Sie, ob Sie dadurch leichter zum Ausgang des Levels kommen.
-
-**Hinweis**: Erinnern Sie sich an die [ECS-Architektur](../lecture/misc/dungeon.md).
-Schauen Sie sich u.a. die Factory `HeroFactory` und den `FireballSkill` an.
-
 ## Refactoring im Bike-Shop
 
 Forken Sie das
@@ -167,7 +65,7 @@ strukturierten und schlecht benannten und schlecht dokumentierten Code.
     Vorgehen vorstellen.
 
 Nach dem Refactoring sollte ein `./gradlew check` keine Probleme bzgl. Formatierung
-und Dokumentation[^2] mehr finden.
+und Dokumentation[^1] mehr finden.
 
 *Tipp*: Schauen Sie schlechter Namensgebung, nach redundantem Code, nach übermäßig
 komplexer Logik, nach Code/Logik in der falschen Klasse (am falschen Ort), nach
@@ -203,7 +101,4 @@ komplexer Logik, nach Code/Logik in der falschen Klasse (am falschen Ort), nach
     -   Deadline: 20. Juni, 08:00 Uhr
 -   Vorstellung im Praktikum: 20. Juni
 
-[^1]: Das dritte richtige Level, also das dritte Level *nach* dem Demo-Level. Oder
-    eben das vierte Level, wenn man das Demo-Level mitzählt :-)
-
-[^2]: d.h. Sie müssen gegebenenfalls auch Javadoc ergänzen ...
+[^1]: d.h. Sie müssen gegebenenfalls auch Javadoc ergänzen ...

homework/b08.md

@@ -1,16 +1,14 @@
 ---
 author: Carsten Gips (HSBI)
 no_beamer: true
-title: "Blatt 08: Bridge Guard Riddle & Syntax Highlighting (Reguläre Ausdrücke,
-  Template-Method, Command)"
+title: "Blatt 08: Syntax Highlighting (Reguläre Ausdrücke, Template-Method, Command)"
 ---
 
 # Zusammenfassung
 
 Auf diesem Blatt üben Sie den Umgang mit regulären Ausdrücken in Java. Wir nutzen
 diese zusammen mit dem Template-Method-Pattern für die Implementierung eines
-einfachen Syntax-Highlightings, und im DevDungeon müssen Sie mit einem Brücken-Troll
-kämpfen und das Command-Pattern implementieren.
+einfachen Syntax-Highlightings.
 
 ::: important
 **Hinweis**: Bitte denken Sie daran, dass Sie spätestens seit Blatt 04 die
@@ -26,76 +24,6 @@ Die Links zu Ihren Pull-Requests mit den Lösungen geben Sie bitte immer in Ihre
 
 # Aufgaben
 
-## DevDungeon: Brücken-Troll
-
-Klonen Sie das Projekt
-[DevDungeon](https://github.com/Dungeon-CampusMinden/dev-dungeon) und laden Sie es
-in Ihrer IDE als Gradle-Projekt. Betrachten Sie das Sub-Projekt "devDungeon". Dies
-ist ein von einem Studierenden ([\@Flamtky](https://github.com/Flamtky)) erstelltes
-Spiel mit mehreren Leveln, in denen Sie spielerisch verschiedene Aufgaben *in-game*
-und *ex-game* lösen müssen.
-
-Starten Sie den DevDungeon mit `./gradlew devDungeon:runDevDungeon`. Spielen Sie
-sich für diese Aufgabe durch das **vierte Level** ("Bridge Guard Riddle")[^1].
-
-In diesem Level gibt es im oberen Teil eine Art Brücke, die von einem Brücken-Troll
-bewacht wird.
-
-![](images/bridgetroll-annot.png){width="80%"}
-
-Diesen müssen Sie besiegen, um die Brücke passieren und die Belohnung (einen
-magischen Schild) zu bekommen. Den Schild können Sie im nächsten Level gut
-gebrauchen: Der Schild schützt Ihren Hero vor Schäden, auch wenn er nur einen
-Treffer verträgt und sich dann über eine gewisse Zeit regenerieren muss, bevor er
-wieder funktionstüchtig ist.
-
-*Hinweis*: Sie können natürlich wie immer auch "außen herum" gehen und die Brücke
-vermeiden, um ins nächste Level zu kommen. Das ist aber ziemlich gefährlich, und Sie
-bekommen den magischen Schild nicht, den Sie für das letzte Level ziemlich dringend
-brauchen.
-
-**Hinweis**: Aktuell ist das Projekt DevDungeon an einigen Stellen noch
-*Work-in-Progress*, beispielsweise fehlt häufig noch die Javadoc. Alle Gradle-Tasks,
-die von Checkstyle-Tasks abhängen (`checkstyleMain`, `check`, `build`, ...) werden
-deshalb fehlschlagen. Sie können den DevDungeon aber wie oben beschrieben mit
-`./gradlew devDungeon:runDevDungeon` (bzw. über den Task `devDungeon:runDevDungeon`
-aus der IDE heraus) starten.
-
-**WICHTIG**: Achten Sie bitte darauf, dass im Projektpfad **keine Leerzeichen** und
-keine Sonderzeichen (Umlaute o.ä.) vorkommen! Dies kann zu seltsamen Fehler führen.
-Bitte auch darauf achten, dass Sie als JDK ein **Java SE 21 (LTS)** verwenden. Unter
-Windows ist der Einsatz von
-[WSL](https://learn.microsoft.com/en-us/windows/wsl/install) empfehlenswert.
-
-### RegExp mit dem Brücken-Troll
-
-Suchen Sie den Brücken-Troll auf und sprechen Sie ihn an. Er wird Ihnen eine Reihe
-von Fragen zum Thema reguläre Ausdrücke stellen, die Sie korrekt beantworten müssen.
-
-Machen Sie Screenshots von den Fragen und Ihren Antworten, die Sie im Praktikum
-vorstellen und diskutieren.
-
-### Command-Pattern mit der Klasse *BridgeControlCommand*
-
-Leider lässt sich der Brücken-Troll offenbar weder durch Diskussion noch durch Kampf
-besiegen. Aber vielleicht können Sie die Brücke "aufmachen", so dass er in die Tiefe
-stürzt? Die *Tiles* der Brücke bestehen aus sogenannten `PitTile`s: Wenn diese offen
-sind, fällt man hindurch; wenn sie geschlossen sind, kann man gefahrlos darauf
-treten (außer, es ist eine Verzögerung aktiviert :-) ... Allerdings müssten Sie
-danach die Brücke auch wieder schließen, um selbst darüber hinweg laufen zu können
-...
-
-Schauen Sie sich die Info-Box am Eingang zur Brücke an. Der Hebel bedient mit Hilfe
-des Command-Patterns die Brücke. Für die *Commands* gibt es die Klasse
-`BridgeControlCommand` im Package `entities.levercommands`, wobei die Methode
-`BridgeControlCommand#execute` das *Command* ausführt und die Methode
-`BridgeControlCommand#undo` das *Command* wieder rückgängig macht.
-
-Implementieren Sie die beiden Methoden und starten Sie das Spiel erneut.
-
-**Hinweis**: Mit der Methode `Game.currentLevel().tileAt()` können Sie auf ein
-`Tile` an einer bestimmte Koordinate zugreifen.
-
 ## Syntaxhighlighting mit RegExp
 
 Klonen Sie die [Vorgaben "Syntax
@@ -189,6 +117,3 @@ Kommentar brauchen Sie keine Keywords, Annotationen, Strings usw. erkennen.
 
     -   Deadline: 27. Juni, 08:00 Uhr
 -   Vorstellung im Praktikum: 27. Juni
-
-[^1]: Das vierte richtige Level, also das vierte Level *nach* dem Demo-Level. Oder
-    eben das fünfte Level, wenn man das Demo-Level mitzählt :-)