167 lines
8.1 KiB
Markdown
167 lines
8.1 KiB
Markdown
# 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
|
||
|
||
- Ü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.*
|