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 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
• Kinder werden bereits über ChildRelation geführt in child_relation.js
• Ansehen ist bereits auf dem Charakter vorhanden in character.js
• Stand ist bereits über titleOfNobility abbildbar in 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.