- Logistik: Musik-Player Playlist-Modus (5 Gruppen, 20 Tracks) - Heli: End-Screen auf .ggs-endscreen, Mission-Bilder, Voice-Lines, Briefing-Audio - Logistik: Layout-Tausch Auftraege+Fahrzeuge links, Karte rechts - Logistik: Tier-1-Staedte ausgebaut, Auto-Timescale-Badge - Logistik: Roadnet/Railnet Dijkstra-Routing, Balance-Updates - Atlas: 5 Atlas-Inbox-Nachrichten (Cards-Pattern, DALL-E-Key, Musik-Playlists) - Status-Updates Heli + Logistik Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
7.3 KiB
Level-Progression + Balance-Regel R-1
Stand: 2026-04-23 Gilt fuer: Logistik Europa (Modul 11)
Dieses Dokument erklaert (1) die neue Innere Progression in Level 1 und (2) die Balance-Regel R-1 (Startbudget-Runway) inkl. Analyse warum Level 3 in seiner aktuellen Form dagegen verstoesst.
1. Level-1-Progression („Steigerung innerhalb eines Durchgangs")
Bisher: in L1 lief immer Wien → Salzburg → Wien → Salzburg → ...
immer genau 1 Auftrag parallel. Didaktisch stagniert — der Bearbeiter
lernt nach 2 Auftraegen nichts Neues.
Neue Mechanik
Die Engine fuehrt jetzt einen Progression-Zaehler:
game.progression = { round: 1, trucksBought: 0 }
round wird nach jeder abgeschlossenen Lieferung +1 erhoeht.
Dynamische Auftragsanzahl (nur L1)
| Runde | aktive Auftraege (max) | Idee |
|---|---|---|
| 1 | 1 | Tutorial — 1 Option, keine Wahl |
| 2 | 2 | Erste Wahl: direkt vs. away |
| 3 | 2 | Einuebung |
| 4+ | 3 | Parallel disponieren |
Implementiert in engine.js via _effectiveMaxContracts(game).
Der Config-Wert cfg.maxActiveContracts bleibt unveraendert (L1 = 1);
die Funktion ueberschreibt ihn dynamisch in L1.
Erweiterter Auftragspool
Bisher nur Wien ↔ Salzburg. Neu: Pool mit 5 Staedten (Wien,
Salzburg, Muenchen, Berlin, Hamburg — alle visibleFromLevel=1) und
Reward-Multiplikatoren, die Distanz-Unterschiede ausgleichen:
| Strecke | Luftlinie | Mult | Rationale |
|---|---|---|---|
| Wien ↔ Salzburg | ~300 km | 1.0 | Standard |
| Salzburg ↔ Muenchen | ~150 km | 0.8 | Kurz, weniger Wert |
| Wien ↔ Muenchen | ~430 km | 1.3 | Mittel |
| Muenchen ↔ Berlin | ~620 km | 1.5 | Weit |
| Wien ↔ Berlin | ~680 km | 1.7 | Sehr weit |
Der Pool wird staffelweise freigeschaltet:
- Runde 1-2: nur
mult ≤ 1.0(sanfter Einstieg) - Runde 3-4: bis
mult ≤ 1.4(Mittelweite) - Runde 5+: voller Pool
Away-Bonus: „direkt" vs. „woanders"
Bei 2-3 parallelen Auftraegen bevorzugt der Generator:
- Erster Auftrag aus Vehicle-Location (Bearbeiter hat sofort was zu tun)
- Zweiter/Dritter aus anderen Staedten (
awayBonus: trueFlag)
Der Spieler muss entscheiden: fahre direkt los (geringer Gewinn, keine Leerfahrt) ODER akzeptiere den Away-Auftrag (hoeherer Reward-Mult, aber Leerfahrt zum Pickup noetig). Implementiert wirtschaftlich sinnvoll durch den Reward-Multiplikator — der entschaedigt die erwartete Leerfahrt.
Auto-Buy-Kleiner-LKW
L1 ist Tutorial — der Spieler lernt Flottenvergroesserung als Konzept.
Sobald balance ≥ 15.000 €, kauft die Engine automatisch einen weiteren
TRUCK_SMALL (Kosten: 5.000 €). Max 3 Fahrzeuge auf L1.
Implementiert in _maybeAutoBuyVehicle(game). Feuert im Anschluss an
jede Followup-Generation.
Ab L2 wird das manuell (UI-Button, noch zu bauen) — siehe Offene Punkte.
2. Balance-Regel R-1: Startbudget-Runway
Regel-Wortlaut
Ein Level muss dem Bearbeiter mindestens 1.5 Tage „Luft" fuer Entscheidungen geben, bevor die Fixkosten das Startbudget aufbrauchen. Formal:
startBudget ≥ 1.5 × ( rentalCostPerDay × vehicleCount + idleCostPerHour × vehicleCount × 12 )Der Faktor 12 beim Idle kommt von einer Annahme „im Schnitt halbtags ungenutzt" — konservativ, aber nachvollziehbar.
Warum 1.5 Tage?
- Unter 1 Tag: Spieler ist in Runde 1 schon im Minus, bevor Auftrag abgeschlossen — reiner Frustrations-Einstieg.
- 1 Tag genau: knapp, wenn ein Event den ersten Auftrag verzoegert ist der Puffer weg.
- 1.5 Tage: genug Puffer fuer 1 Fehltrip + strategische Entscheidung (Fahrzeug stehen lassen statt fahren z.B.).
- 2+ Tage: zu bequem, fordert nicht zum wirtschaftlichen Denken auf.
1.5 ist der Kompromiss.
Pruefung der aktuellen Levels
| Level | startBudget | vc | rental | idle | Required R-1 | Ergebnis |
|---|---|---|---|---|---|---|
| L1 | 8.000 | 1 | 0 | 0 | 0 | ✅ PASSES |
| L2 | 5.000 | 3 | 200 | 5 | 1.170 | ✅ PASSES |
| L3 | 2.500 | 5 | 500 | 5 | 4.650 | ❌ FAILS (−2.150) |
L3-Diagnose im Detail
Taegliche Fixkosten auf L3:
- Miete: 5 × 500 = 2.500 €/Tag
- Idle (50 % Leerlauf): 5 × 5 × 12 = 300 €/Tag
- Summe: 2.800 €/Tag realistisch, 3.100 €/Tag worst case
Runway:
2.500 € / 2.800 €/Tag = 0.89 Tage(realistisch)2.500 € / 3.100 €/Tag = 0.81 Tage(worst case)
Der Bearbeiter wird in Stunde 20 schon in den roten Bereich rutschen, bevor der erste Profit-Auftrag (ca. Stunde 10-14) sein volles Netto eingebracht hat — das Zeit-Profil ist feindselig.
Gleichzeitig ist das Min-Ziel 20.000 € nach 72 h erreichbar (meine Python-Simulation: ≈ 28.000 € Endbilanz bei optimalem Spiel), aber der Puffer ist null — jedes Event zieht die Bilanz ins Minus.
Vorgeschlagener L3-Fix (muss von Atlas abgesegnet werden)
Option A (minimal): startBudget: 2500 → 5000
- Erfuellt R-1 knapp (benoetigt 4.650).
- Aendert didaktische Zielstellung nicht.
- +2.500 € = ~2.5 Standard-Auftraege Puffer.
Option B (moderat): startBudget: 2500 → 5000 UND vehicleCount: 5 → 4
- Reduziert Fixkosten auf 4 × 500 = 2.000/Tag + 4 × 5 × 12 = 240 → 2.240/Tag.
- R-1 fordert
1.5 × 2.240 = 3.360— 5.000 passt locker. - Weniger Fahrzeuge = einfacher zu ueberblicken.
Option C (strukturell): rentalCostPerDay: 500 → 300
- Fixkosten fallen auf 1.800 + 300 = 2.100/Tag.
- R-1 fordert 3.150 — 2.500 schafft's immer noch nicht.
- Kombiniert mit
startBudget 4000: 4.000 ≥ 3.150 → ok.
Meine Empfehlung: Option A (nur Budget hoch auf 5.000 €). Minimal-invasiv, aendert die „Profi"-Identitaet von L3 nicht — er bleibt knapp, aber nicht unfair. Die anderen Hebel (Miete, Strafen, Events) spuert der Spieler dann in Runde 2-3, nicht in Runde 1.
Laufzeit-Check als Invariante
Vorschlag an Atlas: Beim loadContent-Aufruf der Engine die Regel
automatisch pruefen und einen console.warn ausgeben, wenn ein Level
R-1 verletzt. Optional: bei strictMode (Test-Lauf) hart werfen.
// Vorschlag (pseudo):
function _validateLevelConfig(cfg) {
const daily = (cfg.rentalCostPerDay || 0) * (cfg.vehicleCount || 1)
+ (cfg.idleCostPerHour || 0) * (cfg.vehicleCount || 1) * 12;
const needed = 1.5 * daily;
if ((cfg.startBudget || 0) < needed) {
console.warn(`[Logistik] Level verletzt R-1: startBudget=${cfg.startBudget}, needed≥${needed.toFixed(0)}`);
}
}
3. Offene Punkte
- UI-Anzeige der Runde auf L1 („Runde 3 — 2 Auftraege, 1 davon woanders") — noch nicht gebaut. Derzeit sieht der Spieler die Steigerung nur indirekt (Anzahl Cards auf der Auftragsliste waechst).
- Manueller Fahrzeugkauf ab L2 — Buy-Button in der Fahrzeug-Liste.
Architektur:
LogistikEngine.buyVehicle(game, mode)Export + UI-Dialog mit Preisliste + Balance-Check. - Atlas-Review der Regel R-1 inkl. moeglicher L3-Balance-Anpassung.
Siehe Mail
2026-04-23-1730-logistik-l3-balance-und-rule-r1.md. - Away-Bonus-Badge in der UI: Contract-Cards mit
awayBonus: truesollten visuell markiert sein (z.B. ↗ Icon + „Leerfahrt noetig"-Text).