Jander_Semester2/Semesterprojekt/docs/enhancement-ideas.md

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.