# 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  ✅ umgesetzt (Branch `feature/presentation-layer`)

> Umgesetzt: semantisches Modell (`io.text`), `ConsoleIO` (ANSI + Box-Drawing,
> Color/Glyph-Modi), `SwingIO` (4 Regionen, `JTextPane`, gebündelter Font,
> HiDPI-Skalierung + Zoom `Strg +/-/0`), HUD pro Zug, Welcome-Banner. 79 Tests grün.
> Spec/Plan unter `docs/superpowers/`. Karte/Menü/Save/Musik weiterhin offen.


- 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.

**Festgelegt (Zielbild Konsole):** Stufe **B als Baseline** (Boxed Heading,
gelabelte Sektionen, persistente HUD-Zeile: Ort · Gold · Zug · Licht), **ASCII-Art
nur für große Momente** (Spielstart, Finale, Schlüsselräume). Semantische
Farb-Rollen: Items / NPCs / Exits / Heading / Gefahr.

**Designprinzipien:**
- **Nicht überladen / Progressive Disclosure** – Raumeintritt zeigt nur das
  Wesentliche (Ort, kurze Beschreibung, Auffälliges); Details auf Abruf
  (`examine`, `look`).
- **Info auf Regionen verteilen statt Text stapeln** – die **Karte ersetzt die
  „Exits:"-Zeile**. GUI: persistentes Map-Panel macht die Exit-Zeile überflüssig.
  Konsole: kompakte Mini-Map (bei `map` bzw. knapp beim Raumeintritt).

### 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  ✅ umgesetzt (Branch `feature/map`)

> Umgesetzt: `MapLayout` (BFS-Gitter-Layout + Fog of War), `MapView`-Modell,
> GUI-`MapPanel` (Graphics2D, ersetzt die Exit-Liste), Konsolen-ASCII via
> `AsciiMap` + `map`-Befehl, Besuchte-Räume-Tracking auf `Player`, Map-Push pro Zug.
> Item/NPC-Marker und Türen-Styling offen (Quest-Teilprojekt). Spec/Plan unter
> `docs/superpowers/`.


- Ü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)

> ✅ Fundament umgesetzt (Branch `feature/quest-foundation`): World-Flags +
> Condition/Effect-Engine, verschlossene Exits, zustandsabhängige Beschreibungen,
> bedingte Dialoge, Reaktionen mit requires/effects, Schalter-Effekte. Demo:
> Generator schaltet Strom → Keller-Tür öffnet + Raum wird beleuchtet.
>
> ✅ #3.2 umgesetzt (Branch `feature/quests`): condition-driven Quests
> (Quest/QuestStage), QuestEngine mit Auto-Advance + Ansagen, START_QUEST-Effekt,
> Konsolen-Befehl `quests` und GUI-Quest-Box unter der Karte. Demo-Quest
> `restore_power`. Offen: #3.3 Win-Condition/Enden sowie Licht/Dunkelheit &
> Item-Kombination.


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

**GUI-Layout (festgelegt):** Quest-Log als **dauerhaft sichtbare Box unterhalb der
Karte** im rechten Seitenbereich (Map oben, Quests darunter). Gehört zu Quest-
Teilprojekt #2 (Quest-Log); das Fundament #1 reserviert/plant den Slot.

### 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.*