This commit is contained in:
Bastian Wagner
2026-08-19 14:43:25 +02:00
parent deab7a31f1
commit f24a5fea9c
30 changed files with 1718 additions and 0 deletions

View File

@@ -0,0 +1,283 @@
# Ashen Realms Playable Slice 0.11: Grenzmarken & First Merchant
**Status:** Ready for implementation
**Prerequisite:** Playable Slice 0.10 First NPC & Quest
**Scope:** First regional currency and targeted merchant progression
**Currency:** Grenzmarken
**Next Slice:** Playable Slice 0.12 Aschenfelder Complete
## 1. Goal
Implement the first anti-frustration progression system.
The core philosophy is:
> Drops create excitement. Regional currency prevents frustration.
The player can earn Grenzmarken through normal progression and use them to buy targeted Tier-1 upgrades.
## 2. Grenzmarken
Implement persistent:
```text
Grenzmarken
```
Sources include existing configured rewards such as:
```text
Quests
rare enemies
stronger enemies
Elite
Boss
```
Use the current balancing/content definitions as the source of truth.
## 3. Currency model
At this stage a reusable currency model may become worthwhile.
Conceptually:
```text
CurrencyDefinition
CharacterCurrency
```
Example stable keys:
```text
silver
border-marks
```
If Silver is already safely represented directly on Character, do not force a risky large migration solely for architectural purity.
The important requirement is that Grenzmarken are persistent and server-authoritative.
## 4. Merchant
Introduce the first regional merchant at the appropriate existing NPC/location.
Use existing project content if a merchant NPC/location has already been defined.
Minimal merchant data:
```text
ShopDefinition
ShopOffer
```
A ShopOffer should determine:
```text
item
currency
price
availability
```
## 5. Grenzmarken offers
Use the established prices:
| Item | Price |
|---|---:|
| Räuberhaube | 5 Grenzmarken |
| Plündererhandschuhe | 6 Grenzmarken |
| Wachmannsbeinkleid | 8 Grenzmarken |
| Verstärkte Lederjacke | 10 Grenzmarken |
| Aschenklinge | 15 Grenzmarken |
Do not silently rebalance these prices in this implementation slice.
## 6. Shop API
Use the existing REST conventions.
Conceptually:
```http
GET /api/shops/:shopId
POST /api/shops/:shopId/purchases
```
Purchase request:
```json
{
"offerId": "uuid"
}
```
Do not accept authoritative client values such as:
```text
price
itemId
currency amount
discount
```
The server derives them from the persisted offer.
## 7. Purchase transaction
A purchase must be atomic:
```text
load character currency
load and validate offer
validate balance
subtract Grenzmarken
create CharacterItem
commit
```
If the transaction fails, neither the currency deduction nor the item grant should remain partially applied.
## 8. Ownership and duplicate items
Purchased equipment becomes normal persistent CharacterItem data.
Duplicates are allowed.
Do not implement:
```text
salvaging
buyback
duplicate conversion
pity conversion
```
## 9. Merchant UI
Show:
- merchant/NPC presentation
- current Grenzmarken balance
- available offers
- item icon
- item name
- item stats
- price
- affordability
- purchase action
Reuse the item display and comparison language from Inventory where possible.
## 10. Purchase feedback
After purchase:
```text
Grenzmarken balance decreases
item appears in inventory
player may open inventory
player may equip item
```
Do not automatically equip purchased equipment.
## 11. Progression proof
The important flow is:
```text
desired drop does not appear
player keeps playing
Grenzmarken accumulate
merchant provides targeted upgrade
```
The player should always feel that unlucky drops still produce progress.
## 12. Server authority
The server decides:
- currency balance
- reward grants
- offer availability
- offer price
- purchase validity
- resulting item ownership
Angular only requests purchase of a valid server-provided `offerId`.
## 13. Explicit non-goals
Do not implement:
```text
selling
buyback
dynamic prices
limited stock
shop refresh timers
player trading
auction house
discount systems
reputation
crafting vendor
```
## 14. Required tests
Verify:
- Grenzmarken rewards persist
- current balance is server-authoritative
- shop returns persisted offers
- insufficient balance rejects purchase
- valid purchase deducts exact configured cost
- valid purchase grants the correct CharacterItem
- purchase is transactional
- repeated request cannot accidentally duplicate a single transaction through race conditions
- item survives refresh
- purchased item can be equipped using existing equipment flow
## 15. Definition of Done
The player can:
```text
earn Grenzmarken
see balance
open merchant
inspect offers
buy targeted Tier-1 item
item enters inventory
equip item
```
Random loot and guaranteed long-term progression are now connected.
## 16. Handoff
Next:
```text
Playable Slice 0.12 Aschenfelder Complete
```

View File

@@ -0,0 +1,490 @@
# Ashen Realms Playable Slice 0.12: Aschenfelder Complete
**Status:** Final integration slice for the first region
**Prerequisite:** Playable Slices 0.10.11
**Scope:** Integration, balancing, content completion and polish for the Aschenfelder
**Primary Goal:** Complete the first genuinely playable regional progression loop.
## 1. Goal
Playable Slice 0.12 does not introduce a large new system.
It integrates, verifies, balances, and polishes everything built so far into one coherent first region.
The full intended flow is:
```text
Graufurt
Südtor
Verbrannte Straße
first hunts
first combat
first loot
first upgrades
Verlassener Wachtposten
NPC / Quest
stronger enemies
first Elite
Grenzmarken
targeted upgrades
Aschengrube
regional Boss
guaranteed boss loot
path toward Dämmerwald discovered
```
## 2. Complete locations
The Aschenfelder progression contains:
```text
Südtor von Graufurt
Verbrannte Straße
Verlassener Wachtposten
Aschengrube
```
Each location must have a clear purpose and correct travel connections.
## 3. Complete Tier-1 enemy set
The relevant first-region pool should now include the established enemies:
```text
Aschenratte
Verwilderter Straßenhund
Straßenräuber
Plünderer-Späher
Plünderer-Veteran
Verkohlter Plünderer
Aschenwühler
Verbrannter Jagdhund
Plündererhauptmann / Elite
Hauptmann der Aschenbande / Boss
```
If final naming differs in existing project content, preserve the existing finalized names rather than creating duplicates.
## 4. Complete Tier-1 item set
The relevant Tier-1 pool should now include:
```text
Abgenutztes Kurzschwert
Räuberklinge
Aschenklinge
Räuberhaube
Verstärkte Lederjacke
Plündererhandschuhe
Wachmannsbeinkleid
Aschenstiefel
Zeichen der Grenzwacht
Anhänger des verbrannten Hauptmanns
```
Not every item must be required for progression.
Prestige/special drops remain optional.
## 5. Combat duration targets
During the balancing pass, verify:
### Normal enemies
```text
48 rounds
```
### Elite
```text
610 rounds
```
### Boss
```text
814 rounds
```
These are balancing targets rather than hard rules.
## 6. Power progression targets
Use the established Combat Power progression as a reference:
### Start
```text
approximately 47 CP
```
### After first upgrades
```text
approximately 6070 CP
```
### Wachtposten progression
```text
approximately 8090 CP
```
### Aschengrube / boss-ready range
```text
approximately 100110 CP
```
Combat Power is an internal balancing tool, not a hard access gate.
## 7. Progression pacing
A typical player should need roughly:
```text
1218 normal combats
+
quests
+
boss
```
to progress meaningfully through the first region.
The intended experience must not require 50+ normal combats for basic progression.
## 8. First upgrade pacing
Verify that within approximately the first:
```text
35 combats
```
the player is very likely to see a meaningful equipment upgrade.
If this does not happen reliably enough, tune only the smallest necessary variables:
```text
drop rate
quest reward
starter equipment
```
Do not add unnecessary new reward systems.
## 9. Boss readiness
The regional boss should become reasonably beatable at approximately:
```text
7080% of maximum realistically obtainable regional power
```
Best-in-slot equipment should provide comfort and completionist value, not be mandatory.
## 10. Soft-gate validation
The player should not be blocked primarily by arbitrary level errors.
Where possible:
```text
actual world danger
```
should communicate that the player is too weak.
A player may attempt difficult content early, but the game should make the risk clear.
## 11. Full UI consistency pass
Review all implemented screens together:
```text
World
Hunt
Combat
Loot
Inventory
Quests
Merchant
```
Verify consistency of:
```text
Topbar
SideNavigation
Footer
Context Panel
Panel frames
Buttons
DangerBadges
Item icons
Combat actions
Typography
Spacing
Design tokens
```
No screen should feel like a separate web application.
## 12. Loading and error-state pass
All core player actions need intentional UI states:
```text
loading
success
domain error
network error
retry
```
Review at minimum:
```text
Travel
Hunt
Combat Action
Reward
Equip
Quest
Purchase
```
Do not use browser alerts.
## 13. Refresh and recovery pass
The following states must survive browser refresh through authoritative backend state:
```text
active travel
current hunt
active combat
finished combat/reward
inventory
equipment
active quest
Grenzmarken
boss completion
```
No critical gameplay state may exist only in Angular memory.
## 14. Full integration test
Where practical, automate the first complete progression flow:
```text
character starts at Südtor
travel to Verbrannte Straße
hunt
combat
win
receive loot
equip upgrade
travel to Wachtposten
accept quest
defeat relevant enemies
progress quest
earn Grenzmarken
buy targeted item
equip item
travel to Aschengrube
defeat boss
receive guaranteed boss reward
region completion persists
```
## 15. Manual playtest average RNG
Perform at least one normal playthrough and measure:
```text
combat duration
loot frequency
upgrade frequency
number of hunts
travel flow
quest pacing
Grenzmarken income
boss readiness
total region time
```
## 16. Manual playtest bad RNG
Test a deliberately unlucky run.
Verify:
```text
Grenzmarken still provide progress
progression does not hard-block
boss readiness remains achievable
player does not require extreme grind
```
## 17. Manual playtest good RNG
Test a deliberately lucky run.
Verify:
```text
region does not become instantly trivial
progression cannot be skipped too aggressively
boss remains meaningful
```
## 18. Data/content validation
Verify:
- all locations use persisted content
- all encounter pools use persisted relationships
- all loot is data-driven
- all shop offers are data-driven
- quest definitions are persisted/data-driven
- no core gameplay path depends on hardcoded Angular content
- no server domain service contains unnecessary location-specific special cases
## 19. Server-authority validation
Confirm that the backend remains authoritative for:
```text
travel
hunt availability
encounter generation
danger rating
combat
loot
XP
Silver
Grenzmarken
inventory ownership
equipment
effective stats
quest progress
shop purchases
boss completion
```
## 20. Performance / technical cleanup
Review the accumulated implementation for:
- duplicate API calls
- duplicated frontend state
- duplicated domain validation
- unused temporary placeholder logic
- obsolete Slice 0.10.5 shortcuts
- hardcoded demo combat stats that should now use CharacterStatsService
- temporary combat placeholder routes
- duplicated item definitions
- migration quality
- seed idempotency
Do not perform unrelated architectural rewrites.
## 21. Definition of Done
Playable Slice 0.12 / Aschenfelder Complete is complete when a fresh character can, without developer intervention:
```text
start
travel
hunt
fight
receive loot
improve equipment
meet NPC
complete quest
fight Elite
earn Grenzmarken
buy targeted item
reach Aschengrube
defeat regional Boss
receive guaranteed progression reward
discover path toward Dämmerwald
```
## 22. Final product test
The most important qualitative result is:
> After completing the Aschenfelder, the player should want to see what waits in the Dämmerwald.
If the loop is technically correct but does not create that motivation, the region still needs iteration.
## 23. After Slice 0.12
Do not immediately expand into the full Dämmerwald.
First:
```text
playtest
measure
balance
fix friction
validate reward pacing
validate combat decisions
validate boss readiness
```
Only after the first region loop works well should the same systems be expanded into the Dämmerwald and later the Vergessene Ruinen.

View File

@@ -0,0 +1,227 @@
# Ashen Realms Playable Slice 0.6: Full First Combat
**Status:** Ready for implementation
**Prerequisite:** Playable Slice 0.5 First Upgrade
**Scope:** First complete tactical combat action set
**Next Slice:** Playable Slice 0.7 Complete Verbrannte Straße
## 1. Goal
Playable Slice 0.6 turns the technical `ATTACK`-only fight into the first real Ashen Realms combat with meaningful player decisions.
The player loop becomes:
```text
Encounter
→ Combat
→ recognize enemy intent
→ choose appropriate action
→ attack / defend / interrupt / heal
→ win or lose
```
The slice must prove that combat is more than repeatedly pressing Attack.
## 2. Player actions
Implement:
```text
ATTACK
HEAVY_STRIKE
SHIELD_BASH
DEFEND
POTION
```
### ATTACK
- 100% normal damage.
### HEAVY_STRIKE
- 160% normal damage.
### SHIELD_BASH
- 70% normal damage.
- Interrupts a prepared interruptible enemy action.
### DEFEND
- Reduces incoming damage by 50% for the current round.
### POTION
- Heals 35% of maximum HP.
- Uses the player's action for the round.
- Cannot heal beyond max HP.
## 3. Combat bag
For V1, each combat starts with:
```text
2 healing potions
```
For this slice, the combat bag may remain part of the Combat snapshot if connecting it to persistent consumable inventory would unnecessarily expand scope.
Do not implement a complete consumable inventory economy yet.
## 4. Telegraphing
Enemies must be able to prepare dangerous actions.
Example:
```text
Straßenräuber bereitet Schweren Hieb vor.
```
The next player decision may be:
```text
ATTACK
DEFEND
SHIELD_BASH
HEAVY_STRIKE
POTION
```
A prepared action must be visible before the player chooses the next action.
## 5. Enemy intent
Extend combat state so the monster can expose a prepared intent.
Conceptually:
```ts
monsterState: {
pendingAction?: CombatIntent;
}
```
Initial intent types may include:
```text
NORMAL_ATTACK
HEAVY_ATTACK
```
Keep the model extensible without implementing future mechanics prematurely.
## 6. Straßenräuber behavior
The Straßenräuber becomes the first real learning enemy.
Basic behavior:
```text
normal attack
occasionally prepare Heavy Attack
resolve Heavy Attack on the following round
```
`SHIELD_BASH` can interrupt the prepared Heavy Attack.
`DEFEND` can mitigate it.
The player may also intentionally accept the risk and attack.
## 7. Combat UI
The action bar should now show:
```text
[ Angriff ]
[ Schwerer Hieb ]
[ Schildstoß ]
[ Verteidigen ]
[ Trank 2/2 ]
```
The combat screen must clearly display:
- player HP
- monster HP
- current round
- enemy intent / telegraph
- combat log
- available actions
- disabled/loading action states
Telegraphing must be more visually prominent than a normal combat log line.
## 8. Server authority
The server decides:
- action validity
- damage
- healing
- potion count
- defend mitigation
- interrupt success
- enemy intent
- monster action
- combat result
The client sends only the selected action enum.
## 9. Explicit non-goals
Do not implement yet:
```text
Bleeding
Poison
Mana
Crit
Dodge
Block Chance
Cooldown system
Sets
Boss phases
Flee
Elemental damage
Resistances
```
## 10. Required tests
At minimum verify:
- `ATTACK` uses 100% damage.
- `HEAVY_STRIKE` uses 160% damage.
- `SHIELD_BASH` uses 70% damage.
- `SHIELD_BASH` interrupts a prepared interruptible action.
- `DEFEND` halves incoming damage for the round.
- `POTION` heals 35% max HP.
- Potion healing cannot exceed max HP.
- Only two potions are available in a combat.
- A telegraphed attack resolves on the next round if not interrupted.
- A killed monster does not resolve a pending attack.
- Combat remains deterministic.
## 11. Definition of Done
The player can fight a Straßenräuber and encounter a situation such as:
```text
Schwerer Angriff angekündigt
Verteidigen
or
Schildstoß
or
Risiko eingehen
```
The combat is no longer just repeated use of `ATTACK`.
## 12. Handoff
Next:
```text
Playable Slice 0.7 Complete Verbrannte Straße
```

View File

@@ -0,0 +1,235 @@
# Ashen Realms Playable Slice 0.7: Complete Verbrannte Straße
**Status:** Ready for implementation
**Prerequisite:** Playable Slice 0.6 Full First Combat
**Scope:** First fully playable hunting location
**Primary Location:** Verbrannte Straße
**Next Slice:** Playable Slice 0.8 Wachtposten & First Elite
## 1. Goal
Turn the technical hunting location into the first complete gameplay location.
The Verbrannte Straße must support repeated hunting, multiple enemy archetypes, differentiated mechanics, meaningful loot, and the first visible progression through equipment.
## 2. Complete encounter pool
The hunting pool becomes:
```text
Aschenratte
Verwilderter Straßenhund
Straßenräuber
Verkohlter Plünderer rare
```
## 3. Aschenratte
Role:
- Level 1.
- Basic enemy.
- No special mechanic required.
Rewards:
```text
47 Silver
8 XP
60% Aschenfell / trade material
8% simple starter-slot equipment
```
## 4. Verwilderter Straßenhund
Role:
- Level 12.
- Introduces the first simple status effect.
Mechanic:
```text
BLEED
```
Keep Bleed deliberately simple:
- fixed duration
- fixed damage
- no complex stacking
- server-authoritative
- represented through structured combat state/events
Rewards:
```text
610 Silver
12 XP
70% Zähes Fell
8% Aschenstiefel
5% Kleiner Heiltrank
```
Do not implement the entire long-term consumable economy merely because a potion can drop.
## 5. Straßenräuber
Role:
- Level 2.
- Reinforces Telegraphing.
Mechanic:
```text
prepared Heavy Attack
```
Rewards:
```text
915 Silver
16 XP
18% Räuberklinge
12% Räuberhaube
8% Plündererhandschuhe
10% Kleiner Heiltrank
```
## 6. Verkohlter Plünderer
Role:
- Level 3.
- Rare encounter.
- Noticeably stronger.
- Early long-term target.
Guaranteed:
```text
2535 Silver
35 XP
1 Grenzmarke
```
Additional equipment drops use the existing balancing/content definitions.
The encounter should communicate:
> This enemy may be too strong right now, but the player can return later.
## 7. Encounter pool weights
All encounter probability belongs in persisted `LocationMonster` content.
Do not hardcode location-specific monster probabilities inside the HuntingService.
Conceptually:
```text
Aschenratte common
Straßenhund common
Straßenräuber normal
Verkohlter Plünderer rare
```
Exact weights may be tuned later.
## 8. Grenzmarken
Slice 0.7 may begin persisting Grenzmarken as reward data because the rare enemy already grants one.
They do not need to be spendable yet.
Spending Grenzmarken belongs to Slice 0.11.
## 9. Progression target
Within approximately the first 35 combats, the player should have a high chance of seeing the first meaningful equipment upgrade.
The purpose is to prove:
```text
hunt
→ fight
→ loot
→ equip
→ become stronger
```
through repeated play at one location.
## 10. Hunt UI
The Hunt context panel should now communicate the broader enemy pool.
Example:
```text
Mögliche Begegnungen
Aschenratte
Verwilderter Straßenhund
Straßenräuber
???
```
A rare enemy may remain hidden until first encountered.
Do not expose exact encounter percentages.
## 11. Explicit non-goals
Do not implement yet:
```text
Quest
NPC
Wachtposten progression
Boss
Merchant
Grenzmarken shop
Area completion
```
## 12. Required tests
Verify:
- all four monsters are persisted content
- all four are assigned to `burned-road`
- weighted selection remains deterministic in tests
- rare encounter selection is supported
- Bleed resolves correctly
- Straßenräuber Telegraphing still works
- loot tables match configured content
- Grenzmarken can be persisted when granted
- item upgrades remain persistent after reward flow
## 13. Definition of Done
The player can remain on the Verbrannte Straße and experience:
```text
different encounters
different mechanics
different rewards
first upgrades
visibly increasing strength
```
The location now feels like a real piece of the game rather than a technical test area.
## 14. Handoff
Next:
```text
Playable Slice 0.8 Wachtposten & First Elite
```

View File

@@ -0,0 +1,238 @@
# Ashen Realms Playable Slice 0.8: Wachtposten & First Elite
**Status:** Ready for implementation
**Prerequisite:** Playable Slice 0.7 Complete Verbrannte Straße
**Scope:** First progression inside a region and first elite challenge
**Primary Location:** Verlassener Wachtposten
**Next Slice:** Playable Slice 0.9 Aschengrube & First Boss
## 1. Goal
Introduce the first meaningful progression from one dangerous location to another.
The player should reach a new location, encounter stronger enemies, discover an elite target, improve equipment, and return strong enough to defeat it.
## 2. New location
Add:
```text
Verlassener Wachtposten
```
Connection:
```text
Verbrannte Straße
Verlassener Wachtposten
```
Travel duration:
```text
approximately 15 seconds
```
Travel remains server-authoritative.
## 3. Location functions
The Wachtposten should support:
```text
Jagd beginnen
Wachtposten untersuchen
NPC visible
travel back to Verbrannte Straße
future travel toward Aschengrube
```
The NPC may already be visually present, but full NPC/quest interaction is deferred to Slice 0.10.
## 4. Encounter pool
Use the existing world/content design as the source of truth.
Core enemies:
```text
Straßenräuber
Plünderer-Späher
Plünderer-Veteran
Plündererhauptmann
```
## 5. Plünderer-Späher
Role:
- lighter humanoid enemy
- familiar combat foundation
- part of Wachtposten progression
Use persisted content and data-driven mechanics.
## 6. Plünderer-Veteran
Role:
- first clearly tougher regular humanoid
- combines existing mechanics
Mechanics:
```text
Heavy Attack
+
defensive stance
```
The defensive stance may temporarily increase armor or otherwise use the established deterministic defensive mechanic.
Avoid adding a generic scripting engine.
## 7. Plündererhauptmann
Role:
```text
ELITE
```
The elite combines 23 already learned mechanics.
The elite should be:
- difficult or impractical for an unupgraded starting character
- manageable after meaningful Tier-1 upgrades
- farmable for a recognizable desirable reward
## 8. Elite combat duration
Target:
```text
610 rounds
```
This is a balancing goal, not a hard mechanical rule.
## 9. Elite loot
The elite must have a clear reason to be farmed.
Use the existing balancing/content data for its target rewards.
Do not invent a separate random loot pool if the project already defines the relevant Tier-1 upgrade source.
A desirable weapon such as the Aschenklinge may serve as a primary target where consistent with existing content.
## 10. Danger Rating
By this slice, danger ratings should use real effective player stats.
The backend should derive them from:
```text
CharacterStatsService
+
enemy / encounter power
```
Supported ratings:
```text
WEAK
MATCH
STRONG
VERY_DANGEROUS
DEADLY
```
Use the balancing thresholds as the initial calibration.
Do not calculate this in Angular.
## 11. Encounter UI
Elite encounters must remain part of the reusable EncounterCard system.
They may receive:
```text
ELITE label
stronger border treatment
higher visual emphasis
```
Do not create a completely separate elite hunting UI.
## 12. World UI
Add the Wachtposten as a real travel node.
The world screen should communicate:
- current location
- Verbrannte Straße connection
- Wachtposten connection
- current danger/recommended range
- future Aschengrube direction as appropriate
## 13. Explicit non-goals
Do not implement yet:
```text
full quest flow
merchant
boss
area completion
Dämmerwald
```
## 14. Required tests
Verify:
- location and connection persistence
- travel works in both intended directions
- encounter pool is location-driven
- Plünderer-Veteran mechanics work
- elite encounter classification is persisted
- Danger Rating uses authoritative effective character stats
- elite loot is server-generated
- an undergeared character receives a stronger danger rating than an upgraded one where expected
## 15. Definition of Done
The player can experience:
```text
reach Wachtposten
see stronger enemies
discover Elite
struggle or fail
farm upgrades
return
defeat Elite
```
This is the first direct playable proof of:
> Become stronger and return.
## 16. Handoff
Next:
```text
Playable Slice 0.9 Aschengrube & First Boss
```

View File

@@ -0,0 +1,245 @@
# Ashen Realms Playable Slice 0.9: Aschengrube & First Boss
**Status:** Ready for implementation
**Prerequisite:** Playable Slice 0.8 Wachtposten & First Elite
**Scope:** First region climax and first boss
**Primary Location:** Aschengrube
**Boss:** Hauptmann der Aschenbande
**Next Slice:** Playable Slice 0.10 First NPC & Quest
## 1. Goal
Implement the first true regional progression check.
The player reaches the hardest Aschenfelder location, fights stronger enemies, challenges the first boss, receives guaranteed meaningful progress, and discovers the future path toward the Dämmerwald.
## 2. New location
Add:
```text
Aschengrube
```
Connection:
```text
Verlassener Wachtposten
Aschengrube
```
Use the existing world/content design for travel duration, danger, artwork, and location metadata.
## 3. Regular encounter pool
Core encounters:
```text
Aschenwühler
Plünderer-Veteran
Verbrannter Jagdhund
```
Use the existing balancing and content definitions.
The location should feel more dangerous than the previous two hunting areas.
## 4. Boss access
The boss should not be rolled as a normal random hunt encounter.
The Aschengrube exposes a dedicated location action:
```text
Hauptmann herausfordern
```
This establishes the reusable concept of a boss/location action without creating a boss-specific one-off controller.
## 5. Boss
Implement:
```text
Hauptmann der Aschenbande
Level 3
BOSS
```
Mechanics:
```text
normal attack
telegraphed Heavy Attack
defensive phase / armor increase
below 30% HP:
more aggressive behavior
```
Use reusable combat mechanics rather than a bespoke boss script framework.
## 6. Boss duration
Target:
```text
814 rounds
```
This is a balancing target.
The boss should not be realistically comfortable for a fresh character, but should become manageable through the Tier-1 progression available in the Aschenfelder.
## 7. Boss reward rule
Introduce the first boss guarantee system.
### Roll A guaranteed progression
Always grant:
```text
1 high-quality Tier-1 item
```
Guaranteed pool:
```text
Verstärkte Lederjacke
Wachmannsbeinkleid
Aschenstiefel
Zeichen der Grenzwacht
```
### Roll B additional special drops
```text
20% Aschenklinge
8% Anhänger des verbrannten Hauptmanns
```
Guaranteed additional rewards:
```text
5070 Silver
80 XP
5 Grenzmarken
```
The guaranteed progression roll and special rolls are separate.
## 8. Loot architecture extension
Extend the existing loot system to support:
```text
guaranteed item pool
+
independent optional rolls
```
Do not implement the boss reward directly inside the controller.
The behavior must remain data-driven and reusable.
## 9. Boss completion persistence
Persist first boss completion / regional progression state.
The exact data structure should follow the existing project conventions.
At minimum, the server must know that the character has defeated the regional boss.
Do not rely on Angular state.
## 10. Future path discovery
After the first boss victory, expose the future progression hint:
```text
Ein Pfad in Richtung Dämmerwald wurde entdeckt.
```
The Dämmerwald itself does not need to be playable yet.
The world state may mark a future node/connection as discovered or unlocked according to the existing architecture.
## 11. Boss UI
The boss encounter should visually communicate that it is a major challenge.
Use:
- existing combat screen
- boss label
- stronger framing
- clear Telegraphing
- phase/status information
- existing combat log/event system
Do not build a separate game mode.
## 12. Explicit non-goals
Do not implement yet:
```text
Dämmerwald content
complex boss scripting DSL
multiple boss instances
raid mechanics
group combat
boss matchmaking
```
## 13. Required tests
Verify:
- boss can only be started through a valid server-side boss/location action
- boss combat uses persisted authoritative stats
- defensive phase changes combat behavior
- low-HP aggression triggers correctly
- boss victory persists
- boss reward is granted exactly once
- guaranteed Tier-1 item always appears
- special drop rolls remain independent
- XP, Silver and Grenzmarken match content rules
- page refresh does not duplicate boss reward
- future path discovery persists
## 14. Definition of Done
The player can:
```text
reach Aschengrube
fight regular encounters
challenge boss
read and react to mechanics
win
receive guaranteed progression item
receive boss rewards
discover route toward Dämmerwald
```
A boss victory must never end without meaningful progress.
## 15. Handoff
Next:
```text
Playable Slice 0.10 First NPC & Quest
```