This commit is contained in:
Bastian Wagner
2026-08-20 09:47:24 +02:00
parent 67237f5ad8
commit b0e769d0da
12 changed files with 3904 additions and 7 deletions

File diff suppressed because it is too large Load Diff

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.3 MiB

View File

@@ -0,0 +1,921 @@
# Ashen Realms Local Location View Design Specification V1
## Zweck
Dieses Dokument definiert die dauerhaften Design- und Content-Regeln für die **lokale Ortsansicht** von Ashen Realms.
Die Ortsansicht bildet die fehlende Weltebene zwischen der globalen Karte und spezialisierten Aktivitäten wie Jagd, Kampf, Händler, Quests, Dungeons oder Bossen.
Sie beantwortet dem Spieler unmittelbar vier Fragen:
1. **Wo bin ich?**
2. **Wie sieht dieser Ort aus und wie fühlt er sich an?**
3. **Wer oder was befindet sich hier?**
4. **Was kann ich hier tun?**
Diese Spezifikation soll auch für zukünftige Gebiete und Orte gültig bleiben. Einzelne Orte dürfen sich visuell und spielerisch deutlich unterscheiden, verwenden aber dieselbe grundlegende Struktur und dasselbe Interaktionsmodell.
---
# 1. Rolle im Kernloop
Die lokale Ortsansicht wird zum normalen Ankunfts- und Ausgangsscreen, solange sich der Charakter physisch an einem Ort befindet.
Empfohlener Ablauf:
```text
Karte
→ Reise
→ Ortsansicht
→ Aktivität
→ Jagd
→ NPC
→ Untersuchung
→ Händler
→ Quest
→ Boss / Dungeon
→ zurück zur Ortsansicht
```
Die Karte beantwortet:
**Wohin kann ich reisen?**
Die Ortsansicht beantwortet:
**Was gibt es hier?**
Die Jagd beantwortet:
**Was kann ich hier bekämpfen?**
Der Kampf beantwortet:
**Wie besiege ich diesen Gegner?**
Diese Verantwortlichkeiten sollen getrennt bleiben.
---
# 2. Position in der Navigation
Die persistente linke Navigation erhält einen eigenen Eintrag:
```text
Ort
Karte
Jagd
Quests
Inventar
Charakter
Shop
```
`Ort` ist aktiv hervorgehoben, solange der Spieler die lokale Ortsansicht betrachtet.
Der Spieler soll grundsätzlich jederzeit zu dieser Ansicht zurückkehren können, sofern kein blockierender Gameplay-Zustand aktiv ist, beispielsweise ein noch nicht abgeschlossener Kampf.
---
# 3. Ziel des Spielerlebnisses
Ein Ort muss sich wie ein **Ort** anfühlen und nicht wie ein Datensatz oder Menüpunkt.
Der Screen soll beim Spieler das Gefühl erzeugen:
> Ich befinde mich gerade hier. Das ist meine Umgebung. Diese Personen und interessanten Punkte befinden sich hier. Von hier aus entscheide ich, was ich als Nächstes tue.
Die Ortsansicht ist deshalb kein Dashboard aus vielen kleinen Karten.
Das zentrale Artwork ist die wichtigste Präsentationsebene.
UI liegt darum herum oder gezielt darüber.
---
# 4. Grundaufbau des Screens
Jede Ortsansicht verwendet den bestehenden Ashen-Realms-App-Shell:
- persistente Topbar
- persistente linke Navigation
- große zentrale Artwork-Fläche
- kontextuelle rechte Sidebar
- persistenter Footer / Weltstatus
Der eigentliche Ortsinhalt besteht aus fünf funktionalen Ebenen.
## 4.1 Ortskopf
Zeigt:
- Ortsname
- Gebiet / Region als Breadcrumb
- kurze atmosphärische Beschreibung
Beispiel:
```text
Verbrannte Straße
Gebiet 1 > Aschenfelder
Ein alter Handelsweg, der durch Feuer und Krieg in Asche gelegt wurde.
```
Die Beschreibung sollte meist in 13 kurzen Zeilen auskommen.
Längere Lore gehört in Dialoge, Quests, Bücher oder eigene Lore-Inhalte.
---
## 4.2 Großes Orts-Artwork
Das Orts-Artwork ist das visuelle Zentrum des Screens.
Es soll vermitteln:
- Biom
- lokale Gefahr
- Wetter / Atmosphäre
- Architektur
- Spuren vergangener Ereignisse
- wichtige Landmarken
Beispiele:
### Aschenfelder
- verbrannte Straßen
- Asche
- Glut
- tote Bäume
- zerstörte Wagen
- Rauch
### Dämmerwald
- dichte Vegetation
- Nebel
- dunkles Blätterdach
- überwucherte Ruinen
- Spuren verdorbener Tiere
### Vergessene Ruinen
- alter Stein
- Gräber
- eingestürzte Mauern
- Banner
- Krypteneingänge
- kaltes magisches Licht
Interaktionsbeschriftungen dürfen **nicht fest in das Artwork eingebrannt** sein.
Marker und Labels werden durch die UI gerendert.
---
# 5. Points of Interest und Hotspots
Ein Ort kann direkt auf dem Artwork interaktive **Points of Interest (POIs)** besitzen.
Ein POI besteht aus:
- Icon
- Titel
- optionalem kurzen Aktionslabel
- normalisierter X-/Y-Position im Artwork
- Interaktionstyp
- optionalem Verfügbarkeitszustand
Beispiel:
```text
[Truhen-Icon]
Verlassener Wagen
Durchsuchen
```
POIs sollen sich optisch in die Szene integrieren.
Der Screen darf dadurch nicht zu einem Hidden-Object-Spiel werden.
Empfohlene sichtbare Anzahl:
- einfacher Übergangsort: 13
- normaler Ort: 25
- großer Hub: 37
Wenn deutlich mehr Aktionen notwendig sind, müssen sie gruppiert oder in eigene Panels/Screens ausgelagert werden.
---
# 6. Wiederverwendbare Interaktionstypen
Die erste gemeinsame Interaktionssprache lautet:
```text
HUNT
INVESTIGATE
SEARCH
NPC
MAP
TRAVEL
SHOP
QUEST
BOSS
DUNGEON
```
Nicht jeder Typ muss bereits im ersten Slice vollständig umgesetzt sein.
Wichtig ist, dass neue Orte aus wiederverwendbaren Interaktionstypen aufgebaut werden und nicht jeweils eigene Angular-Spezialkomponenten erhalten.
## 6.1 HUNT
Zweck:
Startet die normale Jagd-/Encounter-Schleife des aktuellen Ortes.
Ablauf:
```text
Ortsansicht
→ Jagd
```
Die Ortsansicht würfelt oder rendert selbst keine Encounter-Auswahl.
---
## 6.2 INVESTIGATE
Zweck:
Untersucht Spuren, Ruinen, Symbole, Leichen, Zeichen oder andere Hinweise in der Umgebung.
Mögliche Ergebnisse:
- atmosphärischer Text
- Lore-Hinweis
- Hinweis auf einen Ort
- später Questfortschritt
- später versteckte Verbindung
Für die erste Umsetzung reicht ein serverseitig geliefertes Ergebnis-Panel.
---
## 6.3 SEARCH
Zweck:
Durchsucht ein konkretes Objekt oder einen kleinen Bereich.
Beispiele:
- verlassener Wagen
- alte Vorratskiste
- Lagerreste
- Kryptennische
Später mögliche Ergebnisse:
- Item
- Währung
- Verbrauchsgegenstand
- Hinweis
- nichts
Sobald eine Interaktion echte Belohnungen vergibt, muss sie serverautoritativ sein.
Die erste Version darf reine Text-/Informationsresultate verwenden.
---
## 6.4 NPC
Zweck:
Interaktion mit einem sichtbar am Ort vorhandenen NPC.
Für V1 reicht ein einfaches Dialogpanel.
Spätere Erweiterungen können sein:
- Quests
- Händler
- Ruf-/Tauschsystem
- Dienstleistungen
- Fraktionsinteraktionen
NPCs sollen möglichst im Kontext der Szene sichtbar sein und nicht ausschließlich als Textliste in einem Panel erscheinen.
---
## 6.5 MAP
Zweck:
Öffnet die bestehende Karten-/Reiseansicht.
```text
Ortsansicht
→ Karte
```
---
## 6.6 TRAVEL
Reisen bleibt Bestandteil des bestehenden Karten-/Reisesystems.
Die Ortsansicht darf visuell Ausgänge oder Ziele zeigen, soll aber im Normalfall in den vorhandenen Reiseflow weiterleiten statt eine zweite Reiselogik zu bauen.
---
## 6.7 SHOP, QUEST, BOSS, DUNGEON
Diese Typen sind Erweiterungspunkte für späteren Content.
Sie verwenden dieselben POI- und Aktionsregeln, öffnen aber jeweils einen eigenen Screen, ein Panel oder einen spezialisierten Flow.
---
# 7. Primäre Aktionsleiste
Die wichtigsten lokalen Aktionen werden zusätzlich in einer großen Aktionsleiste unterhalb des Artworks dargestellt.
Diese Dopplung ist beabsichtigt.
POIs erzeugen Atmosphäre und räumlichen Kontext.
Die Aktionsleiste sorgt für klare Bedienbarkeit.
Empfohlenes Maximum:
**4 primäre Ortsaktionen**
Beispiel:
```text
[Jagd beginnen]
[Spuren untersuchen]
[Umgebung durchsuchen]
[Zur Karte]
```
Sekundäre Aktionen dürfen ausschließlich als POI oder in der rechten Sidebar erscheinen.
---
# 8. Rechte Kontext-Sidebar
Die rechte Sidebar fasst die spielerische Bedeutung des aktuellen Ortes zusammen.
Empfohlene Bereiche:
## Ortsidentität
- Gebiet / Region
- Ortsname
- Ortstyp
## Progressionskontext
- empfohlener Fortschrittsbereich oder Empfehlung
- relative Gefahr
Diese Information darf keine harte Zugangssperre sein.
Der bestehende Ashen-Realms-Grundsatz bleibt:
> Die Welt kommuniziert Gefahr, ohne Experimente künstlich zu verbieten.
## Mögliche Begegnungen
Zeigt repräsentative Gegner oder Encounter-Kategorien.
Das ist nur Vorschauinformation.
Der tatsächliche Encounter-Wurf erfolgt weiterhin im Jagdsystem.
## Verfügbare Interaktionen
Beispiele:
- Jagd
- Untersuchen
- Durchsuchen
- Sprechen
## Mögliche Belohnungen
Optionale Vorschau-Icons für:
- Ausrüstung
- Materialien
- Verbrauchsgegenstände
- Handelswaren
- regionsspezifische Belohnungen
Es dürfen keine exakten Belohnungen versprochen werden, wenn der zugrunde liegende Content diese nicht garantiert.
---
# 9. Ortstypen
Orte können über wiederverwendbare Typen ihre grundlegende Rolle ausdrücken.
Empfohlene Startwerte:
```text
SAFE_HUB
TRANSITION
HUNTING_GROUND
QUEST_LOCATION
OUTPOST
ELITE_ZONE
BOSS_LOCATION
DUNGEON_ENTRANCE
```
Der Typ beeinflusst Präsentation und verfügbare Aktionen, benötigt aber keine eigene Page-Implementierung.
Beispiele:
### Südtor von Graufurt
```text
TRANSITION
```
Fokus:
- Wachposten
- Reise
- Gebietsinformation
- wenig oder keine reguläre Jagd
### Verbrannte Straße
```text
HUNTING_GROUND
```
Fokus:
- Jagd
- Umgebungsinformationen
- Spuren
- erste NPC-Begegnung
### Verlassener Wachtposten
```text
OUTPOST / QUEST_LOCATION
```
Fokus:
- NPC
- stärkere Jagd
- Untersuchung
- Storyfortschritt
### Aschengrube
```text
ELITE_ZONE / BOSS_LOCATION
```
Fokus:
- Gefahr
- Elite-/Bosszugang
- kaum zivile Interaktionen
---
# 10. Wiederverwendbares Content-Modell
Die Ortsansicht soll datengetrieben sein.
Ein konzeptionelles View-Model sollte mindestens enthalten:
```ts
interface LocalLocationView {
locationId: string;
locationKey: string;
name: string;
regionName: string;
description: string;
locationType: LocationType;
artworkPath: string;
dangerRating: DangerRating;
recommendationLabel?: string;
huntingEnabled: boolean;
pointsOfInterest: LocationPointOfInterest[];
primaryActions: LocationAction[];
encounterPreview: EncounterPreview[];
rewardPreview: RewardPreview[];
}
```
Konzeptionelles POI-Modell:
```ts
interface LocationPointOfInterest {
key: string;
title: string;
actionLabel?: string;
type: LocationInteractionType;
iconKey: string;
xPercent: number;
yPercent: number;
enabled: boolean;
}
```
Koordinaten werden als Prozentwerte gespeichert, damit Hotspots beim Skalieren des Artworks an derselben Stelle bleiben.
Beispiel:
```text
xPercent: 42.5
yPercent: 66.0
```
---
# 11. Interaktionsergebnisse
Lokale Interaktionen sollen ein vorhersehbares Ergebnisformat zurückgeben.
Konzeptionell:
```ts
interface LocationInteractionResult {
interactionKey: string;
title: string;
text: string;
nextAction?: {
type: string;
target?: string;
};
}
```
Die erste Version bleibt bewusst klein.
Nicht nur für diesen Screen bauen:
- generische Visual-Novel-Engine
- verzweigte Dialogengine
- Event-Skriptsprache
- komplexen Questgraph
---
# 12. Navigationsregeln
## Nach abgeschlossener Reise
Der Spieler landet in der lokalen Ortsansicht des neuen aktuellen Ortes.
```text
Reise abgeschlossen
→ current location aktualisiert
→ Ortsansicht
```
## Nach normalem Kampf
Empfohlener Standard:
```text
Kampfergebnis / Loot
→ Ortsansicht
```
Von dort kann der Spieler erneut jagen.
## Beim Verlassen der Jagd
`Zurück` führt zur Ortsansicht.
## Karte
`Zur Karte` öffnet die Karte, verändert aber nicht den aktuellen Ort.
---
# 13. Screen-Zustände
Die Ortsansicht muss mindestens folgende Zustände definieren.
## Loading
- App-Shell bleibt sichtbar
- zurückhaltender Ladezustand im Hauptbereich
## Loaded
- Artwork
- POIs
- Aktionen
- Kontext-Sidebar
## Interaktion geöffnet
- Ort bleibt im Hintergrund sichtbar
- kurze Untersuchungen und einfache NPC-Dialoge öffnen kein komplett neues Seitenlayout
## Aktion nicht verfügbar
- sichtbar deaktiviert
- optional kurze Erklärung / Tooltip
## API-Fehler
- Navigation bleibt benutzbar
- kompakter Retry-Zustand
## Aktiver Kampf
Wenn der Server einen noch nicht abgeschlossenen Kampf meldet, darf die Ortsansicht nicht zum Umgehen dieses Kampfes genutzt werden.
Der bestehende Combat-Resume-Flow hat Vorrang.
---
# 14. Visuelle Regeln
Die Ortsansicht folgt vollständig der bestehenden Ashen-Realms-UI-Spezifikation.
Wichtig:
- Artwork zuerst
- dunkles Metall / Stein / Leder
- dezente Goldverzierungen
- keine weißen SaaS-Cards
- kein Glassmorphism
- keine Neon-Dashboard-Optik
- Fantasy-Serif für große Überschriften
- sehr gut lesbare UI-Schrift für normalen Text
- zurückhaltender Glow
- eindeutige Interaktionszustände
- konsistente Icon-Sprache
POI-Marker müssen erkennbar sein, dürfen aber das Artwork nicht dominieren.
Bevorzugt werden kleine runde oder schildartige Fantasy-Marker statt moderner Map-Pins.
---
# 15. Responsive Verhalten
Desktop bleibt das primäre Ziel.
## Desktop
- volle linke Navigation
- Artwork mit positionierten POIs
- rechte Sidebar sichtbar
- primäre Aktionsleiste sichtbar
## Tablet
- rechte Sidebar darf einklappbar werden
- Hauptaktionen bleiben sichtbar
- POIs bleiben durch Prozentkoordinaten korrekt verankert
## Mobile später
Nicht V1-Priorität.
Mögliche spätere Anpassung:
- Artwork oben
- POI-Liste unterhalb des Artworks
- rechte Sidebar wird einklappbare Ortsinfo
- Aktionen als zweispaltiges Grid
Das Desktop-Design soll jetzt nicht zugunsten von Mobile kompromittiert werden.
---
# 16. Content-Regeln für zukünftige Orte
Bei jedem neuen Ort werden in dieser Reihenfolge definiert:
1. **Zweck des Ortes**
2. **Visuelle Szene**
3. **Wichtigste Spielerentscheidung**
4. **25 sinnvolle POIs**
5. **Bis zu 4 primäre Aktionen**
6. **Encounter-Vorschau, falls relevant**
7. **Informationen für die rechte Sidebar**
8. **Rückkehr- und Weiterreise-Flow**
Für jeden relevanten Ort muss beantwortet werden:
> Warum soll sich der Spieler an diesen Ort erinnern und ihn nicht nur als weiteren Menüpunkt wahrnehmen?
Mindestens ein identitätsstiftendes Element sollte vorhanden sein:
- markanter NPC
- besondere Landmarke
- Untersuchung
- spezieller Service
- Elitezugang
- Bosszugang
- ungewöhnlicher Encounter-Pool
- Story-Hinweis
- visuelles Ereignis
---
# 17. Was ausdrücklich nicht gebaut werden soll
Die Ortsansicht ist kein:
- frei begehbarer Screen
- WASD-Bewegungssystem
- Point-and-Click-Adventure
- Hidden-Object-Spiel
- zweiter Kartenscreen
- Ersatz für die Jagd
- Ersatz für Quests
- universelles Modal für alle Spielsysteme
Vermeiden:
- dutzende Hotspots
- individuelle Komponenten pro Ort
- Kampflogik im Orts-Screen
- clientseitige Loot-Rolls
- clientseitiger Reiseabschluss
- duplizierte Jagdlogik
- lange Lore-Textwände direkt auf der Szene
---
# 18. V1-Referenzort Verbrannte Straße
Die erste Referenzimplementierung ist die **Verbrannte Straße** in den **Aschenfeldern**.
## Zweck
Beweisen, dass die Ortsansicht Weltgefühl, Jagd, einfache Exploration und NPC-Präsenz verbinden kann, ohne ein neues komplexes Subsystem zu werden.
## Visuelle Identität
- verbrannte Handelsstraße
- zerstörter Wagen
- aschebedeckter Boden
- glühende Risse / Glut
- tote Bäume
- Wachtstrukturen in der Ferne
- Rauch
- Spuren früherer Kämpfe
## POIs
### Jagdgebiet
Typ:
```text
HUNT
```
Aktion:
```text
Jagd beginnen
```
### Verdächtige Spuren
Typ:
```text
INVESTIGATE
```
Aktion:
```text
Untersuchen
```
Beispielresultat:
> Zwischen Asche und zerbrochenen Steinen erkennst du mehrere frische Stiefelabdrücke. Sie führen nach Osten, in Richtung des verlassenen Wachtpostens.
### Verlassener Wagen
Typ:
```text
SEARCH
```
Aktion:
```text
Durchsuchen
```
Beispielresultat für die erste Umsetzung:
> Der Wagen wurde gründlich geplündert. Zwischen verbrannten Brettern findest du nur leere Kisten und Spuren eines hastigen Aufbruchs.
In der ersten Implementierung muss diese Aktion noch keine Belohnung vergeben.
### Verwundeter Kundschafter
Typ:
```text
NPC
```
Aktion:
```text
Sprechen
```
Beispieldialog:
> „Die Straße ist nicht mehr sicher. Die Plünderer kommen aus Richtung des alten Wachtpostens. Wenn du weitergehst, halte die Augen offen.“
Für diese erste NPC-Interaktion ist noch kein Quest-System notwendig.
## Primäre Aktionen
```text
Jagd beginnen
Spuren untersuchen
Umgebung durchsuchen
Zur Karte
```
## Encounter-Vorschau
Repräsentative Gegner:
- Aschenratte
- Verwilderter Straßenhund
- Straßenräuber
- Verkohlter Plünderer
Die Vorschau ist rein informativ.
Sie ersetzt nicht den gewichteten Encounter-Pool der Jagd.
---
# 19. Visuelle Referenz
Für dieses Konzept wurde folgender Referenzscreen erzeugt:
```text
verbrannte_strasse_in_den_aschenfeldern.png
```
Der Screenshot definiert Komposition und Zielgefühl, aber keine pixelgenauen Maße.
Zukünftige Ortsansichten sollen insbesondere beibehalten:
- denselben App-Shell
- dominantes Orts-Artwork
- dieselbe POI-Markersprache
- primäre Aktionsleiste unten
- kontextuelle rechte Sidebar
- klare Trennung zwischen Ort, Karte, Jagd und Kampf
---
# 20. Definition of Done für zukünftige Orte
Eine Ortsansicht ist fertig, wenn:
- aktueller Ort und Region sofort erkennbar sind
- das Artwork den Ort eindeutig vermittelt
- verfügbare Aktionen klar sind
- wichtige NPCs / POIs im Kontext sichtbar sind
- POIs beim Skalieren korrekt positioniert bleiben
- Jagdaktionen den bestehenden Jagdflow verwenden
- Reisen den bestehenden Karten-/Reiseflow verwenden
- lokale Interaktionen keine fremden Systeme duplizieren
- serverautoritative Aktionen serverautoritativ bleiben
- derselbe Komponentenaufbau den nächsten Ort nur über andere Daten rendern kann
- der Screen wie ein Bestandteil desselben Ashen-Realms-UI-Systems wirkt
---
# 21. Leitprinzip
> **Die Karte zeigt dem Spieler, wohin er gehen kann. Die Ortsansicht lässt ihn spüren, wo er gerade ist.**
Jede zukünftige Ortsansicht soll genau diese Trennung stärken.