# Enhancement-Ideen (Backlog)

> Roh-Sammlung von Ausbau-Ideen über die Abgabe hinaus. Lebendes Dokument –
> noch kein Design, noch keine Festlegung. Wird in Teilprojekte zerlegt und
> nacheinander über den Brainstorming → Spec → Plan → Implementierung-Zyklus
> verfeinert.

Stand: 2026-05-31. Ausgangslage: Pflichtumfang ("bare minimum") erfüllt,
alle Phasen 1–7 grün. Ziel: deutlich mehr Tiefe und Politur.

## Leitziele

- **Reichere Ausgabe** statt nacktem Konsolentext – sowohl Konsole als auch GUI.
- **GUI soll noch mehr bieten** als die Konsole (mehr Raum für visuelle Mittel).
- **~60 Minuten Spielzeit** anpeilen. Viel mehr Inhalt, viel mehr zu tun.
- Bestehendes **NPC-System zu einem tieferen Quest-System** ausbauen.

## Themenblöcke

### 1. Reichere Präsentation / Ausgabe-Schicht

- Weg vom reinen `write(String)`: formatierte Ausgabe (Überschriften, Trenner,
  Hervorhebungen für Items/NPCs/Richtungen).
- **Konsole**: ANSI-Farben, Box-Drawing-Zeichen für Rahmen, evtl. ASCII-Art /
  Banner für Räume oder Spielstart.
- **GUI (Swing)**: mehr als ein `JTextArea` – Farben, Stile, evtl. Panels,
  Statusanzeige, Bilder/Icons.

### 2. Nerd Fonts / Glyphen – das Installationsproblem

- Nerd-Font-Glyphen (Icons) sehen gut aus, müssen aber auf dem System des
  Spielers installiert sein, sonst Tofu-Kästchen.
- Offene Frage: gute Lösung finden, damit es überall funktioniert.
- Erste Gedanken:
  - **GUI**: Font ließe sich *mitliefern* (`.ttf` in Resources, via
    `Font.createFont` laden) → Installationsproblem entfällt für die GUI.
  - **Konsole**: Font nicht kontrollierbar → gestufte Fallbacks
    (reines ASCII → Unicode-Box-Drawing → Nerd-Glyphen) statt harter Annahme.

### 3. Karte / Map

- Übersichtskarte der Räume – in **beiden** Modi.
- Konsole: ASCII-Map. GUI: gezeichnete Map (Grid/Graph).
- Offene Fragen: nur bereits besuchte Räume zeigen? aktuelle Position markieren?
  fester Grundriss oder dynamisch aus den Exits berechnet?

### 4. Gameplay-Ausbau (Inhalt)

- Deutlich mehr Räume, Items, NPCs.
- Mehr zu *tun*: Rätsel, Mechaniken, Abhängigkeiten zwischen Objekten.
- Zielgröße: ~60 Min. Spielzeit (laut Annahme machbar, da überwiegend Text).

### 5. Quest-System (NPC-Ausbau)

- Aktuelles NPC-System: Begrüßung + Geschenk-Reaktion (Item → Item).
- Ausbau Richtung: mehrstufige Quests, Bedingungen, NPC-"Memory" (Zustand),
  Quest-Log, evtl. Win-Condition daran gekoppelt.

### 5b. Spielkern: zentraler Bogen + Mechanik-Spine

**Leitidee (bestätigt):** Bewusst *kondensiert* – wenige Mechaniken, die sich
vielfach kombinieren, statt vieler Einzel-Gimmicks. Ein 60-Min-Spiel soll
*designt* wirken, nicht gestreckt.

**Hauptziel:** *Den Strom wieder anschalten* (`power_on`). Der Weg dahin ist eine
**Quest-Kette, die den Spieler Raum für Raum führt** (Raum X freischalten → führt
zu Raum Y → … → Generator/Sicherungskasten). Das Hauptziel selbst ist das Ende
des Bogens; einzelne Teilziele schalten je den nächsten Bereich frei.

**Mechanik-Spine (5 Bausteine, die sich kombinieren):**

1. **World-Flags / Zustand** – Rückgrat (`power_on`, `cellar_drained`,
   `ghost_banished`). Beschreibungen, Exits und NPC-Reaktionen lesen/schreiben sie.
2. **Verschlossene Exits & Schalter** – Türen brauchen Schlüssel *oder* Flag;
   Hebel/Ventile setzen Flags und öffnen Bereiche.
3. **Licht & Dunkelheit** – dunkle Räume brauchen eine brennende Lichtquelle,
   sonst keine Sicht auf Exits/Items (Atmosphäre, einfach umzusetzen).
4. **Item-Kombination** – z.B. `match + candle → lit candle`. Achtung: v1.0 hat
   bewusst argloses `use X` ohne Targets gewählt → Command-Grammatik muss erweitert
   werden (jetzt erlaubt, da über MVP hinaus).
5. **Quest-Ketten + mehrere Enden** – Teilziele referenzieren Flags; Kette
   abschließen = Win; *welche* Flags gesetzt sind, entscheidet das Ende.

**Beispiel-Puzzle (zeigt das Stapeln):** *Strom wiederherstellen* – Sicherung im
gefluteten Keller; erst Ventil → `cellar_drained`; Sicherung einsetzen → Schalter
→ `power_on` → oberes Stockwerk/Tür öffnet sich. Ein Puzzle, drei Mechaniken,
schaltet einen ganzen Flügel frei.

*Weitere Puzzle-Ideen im Backlog (optional, nach Bedarf):* Zahlenschloss mit
Code aus Lore, Caesar-Chiffre-Brief (`decode`), Geist bannen (Reliquien-Fetch),
Melodie-/Sequenz-Rätsel, dunkler Gang. Resource-Meter (Sanity/Öl) **offen** –
vorerst puzzle-fokussiert ohne Survival-Druck.

### 6. Hauptmenü & Settings

- **Hauptmenü** vor der Spielschleife: *Neues Spiel*, *Spiel laden*, *Einstellungen*, *Beenden*.
- **Spielstände-Liste**: gespeicherte Spiele mit Metadaten (Name, Raum, Zugzahl,
  Zeitstempel) anzeigen und hineinladen.
- **Settings-Untermenü**: z.B. Farben an/aus, Typewriter-Tempo, Musik-Lautstärke
  an/aus, ASCII vs. Unicode.
- Sollte in beiden Modi funktionieren: Konsole = nummeriertes Textmenü, GUI =
  Buttons/Liste. Architektur: Menü-Schicht *oberhalb* des Game-Loops.

### 7. Speichern / Laden

- Spielstand serialisieren (Player-Zustand, Inventar, World-Flags, besuchte Räume,
  Quest-Fortschritt) – Format z.B. YAML/JSON.
- Mehrere Speicherstände, benennbar; Anbindung an die Spielstände-Liste im Menü.

### 8. Musik (GUI)

- Hintergrundmusik **nur in der GUI**.
- **Pro Raum definierbar via YAML**: in `rooms.yaml` ein optionales Feld
  (z.B. `music: <dateiname>`), Dateien in *einem* Ordner.
- **Dateigröße** ist ein Thema → Lösungsrichtung:
  - Audiodateien **nicht** in JAR/Repo bündeln, sondern externer `music/`-Ordner;
    Audio ggf. via `.gitignore` ausschließen + dokumentieren, wo Dateien hinkommen.
  - **Komprimierte Formate** (OGG/MP3) statt WAV, **gestreamt** statt komplett geladen.
  - Bibliothek erlaubt → kleinen Audio-Decoder einbinden (Java `javax.sound` kann
    OGG/MP3 nicht nativ).
  - Loop pro Track, sanfter Wechsel beim Raumwechsel, graceful fallback bei
    fehlender Datei, Lautstärke aus den Settings.
  - Architektur: `MusicPlayer`-Komponente hinter Interface; Konsole = No-Op.

## Festgelegte Erweiterungs-Entscheidungen

| Entscheidung | Wert |
|---|---|
| Eigene `uebung`-Datenstrukturen verwenden? | **Nein** – Standard-Collections (vom Prof bestätigt) |
| Algorithmen-Showcase | weiterhin willkommen, aber mit Standard-Datenstrukturen (z.B. BFS `go to <raum>`, Trie-Autocomplete) |
| Bibliotheken erlaubt? | **Ja** (Pflichtteil war bewusst ohne; Erweiterung darf welche nutzen) |
| Hauptmenü | ja: Neues Spiel / Laden / Settings / Beenden |
| Speichern/Laden | ja, mehrere benannte Spielstände |
| Musik | ja, **nur GUI**, pro Raum via YAML, externer Ordner, komprimiert + gestreamt |

## Offene Designfragen (zu klären)

- Wie weit darf die `GameIO`-Abstraktion aufgebohrt werden, ohne dass Konsole
  und GUI auseinanderlaufen? (Gemeinsamer Loop ist ein Kernwert der Architektur.)
- Bleibt alles datengetrieben (YAML), auch Quests und Map-Layout?
- Reihenfolge / Abhängigkeiten der Teilprojekte.

---

*Notiz: Datengetriebenheit (YAML), getrennte DTO/Domain-Schicht und ein für
beide Frontends identischer Game-Loop sind etablierte Architekturwerte – neue
Features sollten sie respektieren, nicht umgehen.*