yourpart3/docs/FALUKANT_LOVERS_DAEMON_SPEC.md

# Falukant: Daemon-Spezifikation für Liebhaber, Mätressen, Ehezufriedenheit und uneheliche Kinder

## Zweck

Dieses Dokument beschreibt die konkrete Server- und Daemon-Logik für außereheliche Beziehungen im Familiensystem von Falukant. Es ergänzt das Grundkonzept in [FALUKANT_LOVERS_CONCEPT.md](/mnt/share/torsten/Programs/YourPart3/docs/FALUKANT_LOVERS_CONCEPT.md) um exakte Regeln für:

- laufende Kosten
- laufende Änderungen von Ansehen
- neues System `Ehe-Zufriedenheit`
- standesabhängige Wirkung von Ehe und Liebschaften
- mögliche Kinder aus Liebschaften
- gendergleiche Behandlung im Regelwerk

Das Dokument ist bewusst daemon-orientiert, also als Grundlage für periodische Verarbeitung im Backend.

## Bewusst vertagte Themen

Zwei Themen werden in dieser Spezifikation ausdrücklich nur vorgemerkt und nicht in die erste Umsetzung gezogen:

### Dienerschaft

`Dienerschaft` ist ein interessanter späterer Ausbau, weil sie gut zu Diskretion, Repräsentation, Hausstand und Kosten passt. Für die erste Version wird sie jedoch nicht als eigenes System modelliert.

Für Phase 1 gilt deshalb:

- Dienerschaft ist nur indirekt in den Unterhaltskosten enthalten
- keine eigenen Diener-Slots, Rollen oder Haushaltsobjekte
- keine gesonderte Interaktion mit Heimlichkeit oder Hofstatus

Später kann daraus ein eigenes Hausstands- oder Hofsystem entstehen.

### Balancing

Die in diesem Dokument genannten Zahlen sind Regelrahmen für die technische Umsetzung, nicht finale Produktionswerte.

Für Phase 1 gilt deshalb:

- Formeln und relative Verhältnisse sind wichtiger als absolute Zahlen
- Kosten-, Ansehens- und Zufriedenheitswerte werden später nach realen Spieltests feinjustiert
- Balancing ist eine eigene Nachphase und kein Blocker für die erste technische Integration

## Leitprinzipien

### 1. Gleichbehandlung der Geschlechter

Die Regeln für Ansehen, Ehezufriedenheit, Unterhalt, Skandal und soziale Bewertung gelten für männliche und weibliche Spielfiguren gleich.

Das heißt:

- dieselbe Beziehungsform erzeugt dieselben Grundkosten
- dieselbe Sichtbarkeit erzeugt dieselben Reputationsfolgen
- dieselbe Standeslage erzeugt dieselben Modifikatoren
- dieselbe Untreue erzeugt dieselbe Wirkung auf die Ehe

Biologische Unterschiede betreffen nur die Frage, ob aus einer konkreten Paarung natürlich ein Kind entstehen kann. Die soziale und spielmechanische Behandlung bleibt gleich.

### 2. Stand vor Moral

Das System bewertet nicht abstrakt „Treue“ oder „Untreue“, sondern:

- wie geordnet die Situation ist
- wie standesgemäß sie geführt wird
- wie sichtbar sie ist
- ob Ehe, Haus und Erbfolge destabilisiert werden

### 2a. Zu jung ist reputationsschädlich

Sehr junge Liebschaften sollen im Daemon nie neutral behandelt werden.

Das heißt:

- eine Beziehung kann technisch erlaubt sein
- sie kann aber trotzdem das Ansehen zusätzlich belasten
- dieser Malus kommt zusätzlich zu Sichtbarkeit, Skandal und Stand
- der Altersmalus gilt geschlechtsunabhängig

### 3. Daemon statt Einmal-Effekt

Kosten, Ehezufriedenheit, Sichtbarkeit und Ansehen werden nicht nur beim Anlegen oder Beenden einer Beziehung verändert, sondern laufend im Daemon fortgeschrieben.

## Bestehende Anknüpfungspunkte

Das System passt auf die vorhandenen Strukturen:

- Beziehungen werden bereits über `Relationship` geführt in [relationship.js](/mnt/share/torsten/Programs/YourPart3/backend/models/falukant/data/relationship.js)
- Kinder werden bereits über `ChildRelation` geführt in [child_relation.js](/mnt/share/torsten/Programs/YourPart3/backend/models/falukant/data/child_relation.js)
- Ansehen ist bereits auf dem Charakter vorhanden in [character.js](/mnt/share/torsten/Programs/YourPart3/backend/models/falukant/data/character.js)
- Stand ist bereits über `titleOfNobility` abbildbar in [title_of_nobility.js](/mnt/share/torsten/Programs/YourPart3/backend/models/falukant/type/title_of_nobility.js)
- `lover` ist bereits ein vorhandener Beziehungstyp

## Neue Spielwerte

## A. Pro Spielfigur: Ehezufriedenheit

Neuer Charakter- oder Ehewert:

- `marriageSatisfaction`
- Wertebereich `0..100`
- Standardwert bei frischer Ehe: `55`

Interpretation:

- `0..19`: offene Ehekrise
- `20..39`: stark belastet
- `40..59`: angespannt bis normal
- `60..79`: stabil
- `80..100`: sehr stabil

Wichtig:

- Ehezufriedenheit gehört zur Ehebeziehung, nicht zur Person allein.
- Technisch ist dafür eine eigene Beziehungstabelle oder eine Erweiterung der Ehe-`Relationship` sinnvoll.
- Für eine erste Version kann der Wert aber auf der Ehebeziehung gespeichert werden.

## B. Pro Liebhaber-Beziehung

Für jede Beziehung vom Typ `lover` werden zusätzliche Felder benötigt.

Pflichtfelder:

- `loverRole`
  - `secret_affair`
  - `lover`
  - `mistress_or_favorite`
- `affection`
  - `0..100`
- `visibility`
  - `0..100`
- `discretion`
  - `0..100`
- `maintenanceLevel`
  - `0..100`
- `statusFit`
  - `-2..2`
- `monthlyBaseCost`
  - integer
- `active`
  - boolean
- `acknowledged`
  - boolean
- `exclusive`
  - boolean optional

Abgeleitete, nicht zwingend gespeicherte Werte:

- `monthlyTotalCost`
- `reputationDeltaDaily`
- `marriageDeltaDaily`
- `scandalRiskDaily`
- `pregnancyChanceMonthly`

## C. Optionaler Kinderwert

Für Kinder aus Liebschaften wird kein neues Kindmodell benötigt. `ChildRelation` reicht, benötigt aber zusätzlich:

- `legitimacy`
  - `legitimate`
  - `acknowledged_bastard`
  - `hidden_bastard`
- `birthContext`
  - `marriage`
  - `lover`
- `publicKnown`
  - boolean

## Standesgruppen

Für alle Daemon-Berechnungen werden Adelstitel auf vier Gruppen verdichtet:

### Gruppe 0: niedrige Stände

- `noncivil`
- `civil`
- `sir`

### Gruppe 1: wohlhabende Bürger und lokale Oberschicht

- `townlord`
- `by`
- `landlord`

### Gruppe 2: niederer und mittlerer Adel

- `knight`
- `baron`
- `count`
- `palsgrave`
- `margrave`
- `landgrave`

### Gruppe 3: hoher Adel und Herrschaft

- `ruler`
- `elector`
- `imperial-prince`
- `duke`
- `grand-duke`
- `prince-regent`
- `king`

Diese Gruppen steuern:

- Toleranz gegenüber sichtbaren Liebschaften
- erforderliches Unterhaltsniveau
- Wirkung auf Ehezufriedenheit
- Strafe bei Skandal

## Taktung im Daemon

Empfohlene Verarbeitung:

- `daily tick`: alle 24 Ingame-Stunden
- `monthly tick`: alle 30 Ingame-Tage

Aufteilung:

### Daily Tick

- Sichtbarkeit und Diskretion anpassen
- Ehezufriedenheit anpassen
- Ansehen anpassen
- Skandalrisiko prüfen
- Ereignisse auslösen

### Monthly Tick

- Unterhaltskosten abbuchen
- Beziehungskosten neu berechnen
- Kinderchance prüfen
- Statuswechsel prüfen

## Kostenmodell

## 1. Grundkosten pro Monat

### secret_affair

- Basis: `10`

### lover

- Basis: `30`

### mistress_or_favorite

- Basis: `80`

Diese Werte sind Ingame-Basiswerte und sollen relativ zu Falukant-Geldwerten noch feinjustiert werden.

## 2. Standesmultiplikator

### Gruppe 0

- `x 1.0`

### Gruppe 1

- `x 1.6`

### Gruppe 2

- `x 2.6`

### Gruppe 3

- `x 4.0`

Begründung:

- Höhere Stände können sich die Beziehung leisten.
- Gleichzeitig muss sie teurer sein, weil „standesgemäß“ mehr Aufwand verlangt.

## 3. Unterhaltsfaktor

`maintenanceFactor = 0.6 + (maintenanceLevel / 100) * 1.2`

Beispiele:

- `0` => `0.6`
- `50` => `1.2`
- `100` => `1.8`

Niedrige Versorgung spart kurzfristig Geld, erhöht aber später Sichtbarkeit, Unzufriedenheit und Skandalrisiko.

## 4. Status-Fit-Kosten

Wenn `statusFit < 0`, steigen Kosten für Diskretion und Konfliktpflege:

- `statusFit = -1` => `+15 %`
- `statusFit = -2` => `+35 %`

## 5. Monatsformel

`monthlyTotalCost = round(baseCost * rankMultiplier * maintenanceFactor * statusFitModifier)`

## 6. Folgen bei Nichtzahlung

Wenn der Monatsbetrag nicht vollständig gezahlt werden kann:

- `affection -8`
- `discretion -6`
- `visibility +8`
- `marriageSatisfaction -4` falls verheiratet
- `reputation -1` sofort, falls `visibility >= 40`

Bei zwei aufeinanderfolgenden Monaten Unterversorgung:

- tägliches Skandalrisiko zusätzlich `+2 %`

## Ehezufriedenheit: Grundmodell

## 1. Basistendenz pro Tag

Jede bestehende Ehe bewegt sich täglich leicht Richtung `55`, wenn keine besonderen Faktoren wirken.

Formel:

- wenn `marriageSatisfaction > 55`: `-1` alle 3 Tage
- wenn `marriageSatisfaction < 55`: `+1` alle 5 Tage

So bleiben Ehen nicht dauerhaft extrem, wenn nichts passiert.

## 2. Modifikatoren durch Liebschaften

Nur wenn eine aktive Ehe und mindestens eine aktive Liebschaft existiert.

### Gruppe 0

- heimliche Liebschaft: `-1` pro Tag
- lover: `-2` pro Tag
- Mätresse/Favorit: `-3` pro Tag

### Gruppe 1

- heimliche Liebschaft: `-1` pro Tag
- lover: `-1` pro Tag
- Mätresse/Favorit: `-2` pro Tag

### Gruppe 2

- heimliche Liebschaft: `0 bis -1` pro Tag
- lover: `-1` pro Tag
- Mätresse/Favorit: `-1` pro Tag

### Gruppe 3

- heimliche Liebschaft: `0`
- lover: `0`
- Mätresse/Favorit: `+1 / 0 / -1` je nach Ordnung

Für Gruppe 3 gilt:

- `+1`, wenn:
  - `visibility <= 35`
  - `maintenanceLevel >= 65`
  - `marriageSatisfaction >= 45`
  - nur eine aktive Mätresse/Favorit vorhanden
- `0`, wenn die Lage geordnet, aber nicht positiv ist
- `-1`, wenn die Beziehung sichtbar Unruhe erzeugt

Das bildet den gewünschten Spezialfall ab:

- Bei einem König kann eine diskrete, geordnete Nebenbeziehung die Ehe sogar entlasten oder stabilisieren.
- Dieselbe Lage kippt ins Negative, wenn sie chaotisch oder öffentlich demütigend wird.

## 3. Zusätzliche Ehemodifikatoren

### Positive Faktoren

- Ehepartner regelmäßig beschenkt: `+1` pro Tag für 5 Tage
- großes Fest oder Hochzeitspflege: `+2..+5` einmalig
- keine aktive Liebschaft und hohe Versorgung des Hauses: `+1` alle 4 Tage

### Negative Faktoren

- sichtbare Liebschaft `visibility >= 60`: `-2` pro Tag
- Liebschaft mit `minAge <= 15`: zusätzlich `-1` pro Tag
- Kind aus Liebschaft wird bekannt: `-8` einmalig
- zwei oder mehr aktive Liebschaften: `-2` pro Tag zusätzlich
- Unterhaltsausfall bei Mätresse/Favorit: `-1` pro Tag

## Ansehen: Grundmodell

Ansehen wird im Daily Tick pro aktiver Liebschaft angepasst.

## 1. Basiswert pro Beziehungsform

### secret_affair

- `-0.2` pro Tag

### lover

- `-0.4` pro Tag

### mistress_or_favorite

- `-0.6` pro Tag

Diese Werte sind Rohwerte vor Modifikatoren.

## 2. Sichtbarkeitsfaktor

`visibilityFactor = 0.4 + (visibility / 100) * 1.6`

Beispiele:

- `0` => `0.4`
- `50` => `1.2`
- `100` => `2.0`

## 3. Standesmodifikator auf Reputationsverlust

### Gruppe 0

- `x 1.8`

### Gruppe 1

- `x 1.3`

### Gruppe 2

- `x 1.0`

### Gruppe 3

- `x 0.7`

Aber:

- bei Gruppe 3 gilt nur dann `0.7`, wenn die Beziehung geordnet ist
- bei Skandal, Erbfolgedruck oder offener Demütigung springt Gruppe 3 auf `1.5`

## 4. Ordnungsbonus

Wenn alle Bedingungen erfüllt sind:

- `maintenanceLevel >= 65`
- `discretion >= 60`
- `visibility <= 35`
- maximal eine aktive Mätresse/Favorit

dann:

- Gruppe 2: `+0.1` Ansehen pro Tag statt Malus bei `mistress_or_favorite`
- Gruppe 3: `+0.2` Ansehen pro Tag statt Malus bei `mistress_or_favorite`

Das repräsentiert:

- geordneten Überfluss
- höfische Attraktivität
- kontrollierte Nebenbeziehung ohne Hauschaos

Für `secret_affair` und normalen `lover` gibt es keinen positiven Reputationswert.

## 5. Tagesformel

`dailyReputationDelta = baseValue * visibilityFactor * rankModifier`

Dann:

- Ordnungsbonus anwenden, falls aktiv
- auf `[-3, +1]` pro Tag je Beziehung begrenzen

## 5a. Altersmalus bei zu jungen Liebschaften

Zusätzlich zur normalen Reputationsformel wird ein eigener Altersmalus berechnet.

Grundlage ist immer das jüngere Alter der beiden Beteiligten:

- `minAge <= 13`: `ageReputationDelta = -1.5` pro Tag
- `minAge <= 15`: `ageReputationDelta = -0.8` pro Tag
- `minAge <= 17`: `ageReputationDelta = -0.3` pro Tag
- `minAge >= 18`: `ageReputationDelta = 0`

Dann gilt:

`finalDailyReputationDelta = dailyReputationDelta + ageReputationDelta`

Zusatzregel:

- wenn `minAge <= 15` und `visibility >= 50`, zusätzlicher Malus `-0.5` pro Tag

Damit gilt dann:

`finalDailyReputationDelta = dailyReputationDelta + ageReputationDelta + visibilityYoungPenalty`

Interpretation:

- junge Beziehungen sind schon im privaten Bereich reputationsschädlich
- sichtbare junge Beziehungen schaden noch stärker
- der Malus kommt zusätzlich zu allen übrigen Skandal- und Sichtbarkeitsfolgen

## 6. Harte Malus-Ereignisse

Zusätzliche Einmal-Effekte:

- öffentliches Gerücht: `-3`
- kirchlicher Tadel: `-5`
- bekanntes Kind aus Liebschaft: `-6`
- Erbfolgestreit durch uneheliches Kind: `-10`
- zwei sichtbare Liebschaften gleichzeitig: `-4`

## Sichtbarkeit und Diskretion

Diese Werte verändern sich täglich.

## Sichtbarkeit + pro Tag

- `+1`, wenn `maintenanceLevel < 35`
- `+1`, wenn `affection < 30`
- `+2`, wenn `statusFit = -2`
- `+1`, wenn bereits ein Ehekonflikt aktiv ist

## Sichtbarkeit - pro Tag

- `-1`, wenn `discretion >= 60`
- `-1`, wenn `maintenanceLevel >= 70`

## Diskretion + pro Tag

- `+1`, wenn `maintenanceLevel >= 70`

## Diskretion - pro Tag

- `-1`, wenn `maintenanceLevel < 35`
- `-1`, wenn `visibility > 60`

Beide Werte bleiben in `0..100`.

## Skandalrisiko

Tägliche Grundchance:

`baseScandalChance = 1 %`

Modifikatoren:

- `+ visibility / 25`
- `+2 %`, wenn verheiratet
- `+2 %`, wenn `statusFit = -2`
- `+3 %`, wenn `maintenanceLevel < 25`
- `+3 %`, wenn zwei oder mehr aktive Liebschaften bestehen
- `+6 %`, wenn `minAge <= 13`
- `+3 %`, wenn `minAge <= 15`
- `+1 %`, wenn `minAge <= 17`
- `-2 %`, wenn `discretion >= 75`
- `-2 %`, wenn Gruppe 3 und Beziehung geordnet als Mätresse/Favorit geführt wird

Deckel:

- Minimum `0 %`
- Maximum `25 %` pro Tag

Mögliche Ereignisse:

- Gerücht
- Ehekrach
- Forderung nach höherem Unterhalt
- kirchlicher Tadel
- Erpressung
- Kind wird bekannt

## Kinder aus Liebschaften

## 1. Grundsatz

Kinder aus Liebschaften sind möglich.

Sie sollen:

- nicht die Ehe ersetzen
- das Familiensystem erweitern
- vor allem bei höheren Ständen politische und soziale Reibung erzeugen

## 2. Technische Bedingung

Im aktuellen biologischen Modell nur bei gegengeschlechtlicher Paarung.

Die soziale Behandlung bleibt gleich:

- weibliche und männliche Spielfiguren erzeugen dieselben Ansehens- und Ehefolgen
- das System bewertet nicht unterschiedlich nach Geschlecht

## 3. Monatschance auf Kind

Nur wenn:

- Beziehung aktiv ist
- beide Figuren im fruchtbaren Altersbereich sind
- `affection >= 45`
- `maintenanceLevel >= 30`
- kein Sperrstatus aktiv

Empfohlene Monatswahrscheinlichkeit:

### secret_affair

- `2 %`

### lover

- `4 %`

### mistress_or_favorite

- `6 %`

Modifikatoren:

- `+2 %`, wenn `affection >= 75`
- `-2 %`, wenn `visibility >= 70` und Beziehung instabil ist
- `-3 %`, wenn eine Figur deutlich über den Fruchtbarkeitsgrenzen liegt

Deckel:

- Minimum `0 %`
- Maximum `12 %`

## 4. Status des Kindes

Bei Geburt aus Liebschaft:

- `birthContext = lover`
- `legitimacy = hidden_bastard` standardmäßig

Wenn die Spielfigur das Kind anerkennt:

- `legitimacy = acknowledged_bastard`
- `publicKnown = true`

Das Kind darf nicht automatisch Erbe werden.

Nur explizite spätere Sonderregeln dürfen Erbfolgedruck erzeugen.

## 5. Folgen eines Kindes aus Liebschaft

### Sofortfolgen

- `marriageSatisfaction -8`
- `reputation -4`

### Wenn öffentlich bekannt

- Gruppe 0: zusätzlich `-4`
- Gruppe 1: zusätzlich `-5`
- Gruppe 2: zusätzlich `-6`
- Gruppe 3: zusätzlich `-8`

### Wenn Kind anerkannt wird

- laufende Monatskosten `+20..+80` je Stand
- zusätzliche Ereignisse zu Versorgung, Namen und Status

## Standesabhängigkeit der Ehe

Die Ehe darf nicht in allen Ständen gleich funktionieren.

## Gruppe 0

- Ehe ist vor allem ökonomische Stabilität
- Liebschaften belasten den Haushalt direkt
- Ehezufriedenheit reagiert stark negativ

## Gruppe 1

- Ehe ist Haus- und Rufgemeinschaft
- diskrete Affären sind denkbar, aber riskant
- sichtbare Liebschaften schaden deutlich

## Gruppe 2

- Ehe ist Hauspolitik und Nachfolgeordnung
- Mätressen können vorkommen, aber nur kontrolliert
- Ehezufriedenheit reagiert weniger moralisch, stärker auf öffentliche Ordnung

## Gruppe 3

- Ehe ist Dynastie, Bündnis und Hofordnung
- eine diskrete Mätresse/Favorit kann den ehelichen Druck senken, solange:
  - die offizielle Ehe respektiert bleibt
  - keine Erbfolge bedroht wird
  - kein öffentlicher Gesichtsverlust entsteht

Deshalb ist bei hohen Ständen ein positiver Effekt auf die Ehe ausdrücklich zulässig, aber nur in geordneten Fällen.

## Empfohlene Umsetzung im Daemon

Reihenfolge pro Daily Tick:

1. aktive Ehen laden
2. aktive Liebschaften laden
3. Sichtbarkeit und Diskretion fortschreiben
4. Ehezufriedenheit pro Ehe fortschreiben
5. Ansehen pro Charakter fortschreiben
6. Skandalereignisse prüfen
7. Benachrichtigungen schreiben

Reihenfolge pro Monthly Tick:

1. Monatskosten je Liebschaft berechnen
2. Geld abbuchen
3. Unterversorgungsfolgen anwenden
4. Kinderchance prüfen
5. neue Kinder aus Liebschaften anlegen
6. Folgeereignisse erzeugen

## Minimale technische Erweiterungen

Für eine erste umsetzbare Version werden mindestens benötigt:

### Beziehungserweiterung

- Zusatzfelder an `relationship` oder neue Nebentabelle `relationship_state`

### Ehewert

- `marriage_satisfaction` an Ehebeziehung

### Kind-Zusatzfelder

- `legitimacy`
- `birth_context`
- `public_known`

### Daemon-Konfiguration

- täglicher Falukant-Familienjob
- monatlicher Falukant-Familienjob

## MVP-Empfehlung

Für die erste produktive Version empfehle ich diesen Schnitt:

### Enthalten

- aktive Liebschaften
- Monatskosten
- tägliche Ansehensänderung
- Ehezufriedenheit
- standesabhängige Unterschiede
- Kinderchance aus Liebschaften
- sichtbare Darstellung in FamilyView

### Noch nicht im MVP

- Erpressungsketten
- kirchliche Sonderereignisse
- gerichtliche Konflikte
- Sonderrechte unehelicher Kinder
- komplexe Hofintrigen
- Dienerschaft als eigenes System
- finales Balancing aller Zahlenwerte

## Abnahmekriterien

Die erste technische Umsetzung gilt als korrekt, wenn:

1. jede aktive Liebschaft monatlich Kosten erzeugt
2. jede aktive Liebschaft täglich das Ansehen verändert
3. verheiratete Figuren täglich Ehezufriedenheit verändern
4. hohe Stände bei geordneter Mätresse/Favorit einen neutralen oder leicht positiven Eheeffekt haben können
5. sichtbare oder schlecht versorgte Liebschaften zu Ansehensverlust führen
6. Kinder aus Liebschaften entstehen können
7. weibliche und männliche Spielfiguren regelgleich behandelt werden

## Offene Implementierungsfrage

Vor dem Coden sollte noch genau entschieden werden:

- ob die Zusatzwerte direkt in `relationship` landen
- oder in eine neue Tabelle wie `falukant_data.relationship_state`

Fachlich ist beides möglich. Für Wartbarkeit und spätere Ereignisse ist eine eigene Zustands-/Detailtabelle sauberer.