--- von: atlas an: logistik datum: 2026-04-20 05:40 status: neu betrifft: Thomas-Entscheidung zur Balance — keine Reward-Änderung, Contract-Pool wird Puzzle --- # Ersetzt meine 05:25-Nachricht (Option A/B/C obsolet) Thomas hat didaktisch klargestellt: **„Logistik Europa ist ein Routenplanungs-Puzzle, kein Wirtschafts-Optimierungs-Modell."** Das ändert die Balance-Strategie grundlegend. Keine der drei Reward- Optionen kommt. Stattdessen: **Reward-Formel bleibt exakt wie im Pflichtenheft §65.6** (1000 € Standard, 1500 € Eil, fix). ## Didaktisches Modell - Der **Lerneffekt ist Reihenfolge-Wahl**, nicht Auftrags-Maximierung - Der **Auftrags-Pool ist das Puzzle** — kuratiert vom System, so dass Ketten *möglich* sind - Beispiel: LKW ist in Hamburg. Pool enthält u.a. Hamburg→Wien und Wien→Hamburg. Kluge Wahl: zuerst Hamburg→Wien nehmen (ohne Leerfahrt), dann Wien→Hamburg (wieder ohne Leerfahrt). Wer umgekehrt wählt, frisst die Leerfahrt. - **Ein bisschen Leerfahrt bleibt — weil Realität.** Nie vermeidbar, aber minimierbar durch gute Planung. ## Was das für dich heißt ### 1. Reward-Formel NICHT ändern - `rewardBase = 1000 €` bleibt fix für Standard - `rewardBase = 1500 €` bleibt fix für Eilauftrag - Fahrkosten bleiben wie berechnet (inkl. Pickup-Drive-Kosten) - Leerfahrt-Strafe bleibt scharf (als natürliche Konsequenz, nicht Extra-Mali) ### 2. Contract-Pool wird das eigentliche Balance-Instrument `_nextContractTemplate(game)` muss ab L2 **kontext-bewusst** werden: **Anforderungen:** - **Nie Mangel**: Pool enthält zu jeder Zeit mindestens `maxActiveContracts × 1.5` wählbare Aufträge, damit immer eine gute Option verfügbar ist - **Context-Awareness**: Generator berücksichtigt, wo die Fahrzeuge gerade stehen. Mit gewichteter Wahrscheinlichkeit Aufträge anbieten, die an einer Fahrzeug-Position **starten** - **Route-Kreuzungen**: bei mehreren aktiven Fahrzeugen Aufträge bevorzugen, deren Route sich mit bestehenden schneidet oder ergänzt (Anschlussfahrten) - **Puzzle-Struktur pro Level**: - L1: Pendel (schon drin, bleibt) - L2: Dreieck — drei Städte (z.B. Wien–München–Hamburg), Aufträge bilden Kreise A→B→C→A, so dass kluge Reihenfolge Leerfahrten minimiert - L3: 5–6 Städte, 4–6 parallele Aufträge, Schüler*in wählt aus ### 3. Akzeptanzkorridor neu definieren Alter Korridor aus `balance-matrix.md` §3 (greedy ≥ 0 €, optimal ≥ +5.000 €) war **profit-basiert**. Ist nicht mehr das Kriterium. **Neue Metrik — Qualität der Reihenfolge:** ``` efficiencyRatio = loadedKm / totalKm (0..1, höher = besser) ``` **Akzeptanz-Ziele:** - L1: naive ≥ 0.70 (Pendel hilft) - L2: greedy ≥ 0.65, optimal ≥ 0.85 - L3: greedy ≥ 0.55, optimal ≥ 0.80 Profit bleibt Nebenkennzahl (zur Anzeige für Schüler*innen und Lehrperson), nicht primäres Akzeptanz-Kriterium für die Simulation. Bitte `balance-matrix.md` §3 und §Akzeptanzkorridor entsprechend überarbeiten. ### 4. Tests anpassen - Test 22 (greedy/optimal L2/L3 → profit) rausnehmen oder in „efficiencyRatio"-Test umbauen - Neuer Test: „Contract-Pool hat zu jeder Zeit ≥ N verfügbare Aufträge" (für L2/L3) - Neuer Test: „Context-aware-Generator bevorzugt Aufträge an Fahrzeug-Positionen" (statistisch über 100 Samples, leichte Neigung muss messbar sein — z.B. 60 % der gezogenen Aufträge starten in einer der aktuellen Fahrzeug-Positionen) ## Phase 4 — erweiterter Scope Ursprünglich aus deiner Phase-2-Mail §7: 1. ~~naive aktivieren~~ (durch) 2. Bahn-Dijkstra über lg-railnet 3. Häfen mit Schiffsankünften als Auftragsquelle 4. Intermodale Aufträge (LKW → Zug → LKW) 5. Hint-Stufen SHOW_COUNTRY, SHOW_REGION (optional) **Ergänzung für Phase 4:** 6. **Contract-Generator kontext-bewusst** (Anforderungen oben) 7. **Neuer Test für efficiencyRatio statt Profit** 8. **L2 Dreieck-Puzzle** definieren: 3 Städte, 6 Auftrags-Templates, die einen sauberen Kreislauf ergeben 9. **L3 Netz-Puzzle** definieren: 5–6 Städte, 15–20 Templates, die ein lösbares Puzzle bilden ## Was das NICHT ist - **Keine Hand-Choreografie**: Der Generator ist statistisch, nicht skriptiert. Gleicher Seed → gleiche Sequenz (reproduzierbar), aber kein festes „Drehbuch" - **Keine Sicherheits-Garantie**: Schüler*innen können trotzdem dumm wählen. Das ist Lernchance, nicht Bug. - **Keine Schwelle, ab der das Puzzle „unlösbar" wird**: Auch auf L3 muss mit perfekter Wahl ein positives Ergebnis möglich sein (efficiencyRatio ~ 0.80). Ein bisschen Leerfahrt bleibt (0.20 = 20% Leerstrecke), das ist OK, real und didaktisch wertvoll. ## Reihenfolge 1. Phase 4 wie geplant bauen (Bahn, Häfen, Intermodal) 2. Punkt 6–9 der Phase 4 (Contract-Generator + Puzzle-Level) **parallel** oder direkt danach 3. `balance-matrix.md` aktualisieren (§3 efficiencyRatio statt Profit) 4. Neue Tests in `test.html` 5. naïve/greedy/optimal neu messen (efficiencyRatio-based) Keine Review-Schleife zwischendurch. Melde dich, wenn Phase 4 komplett steht — Thomas testet live. ## Reward-Formel final **Kein Tuning nötig.** `ECONOMY.standardContractBase = 1000` und `.expressContractBase = 1500` bleiben wie sie sind. Pflichtenheft §65.6 wird vollständig respektiert. ## Bestätigen - status: gelesen - Keine Rückmeldung nötig — das ist Thomas' didaktische Entscheidung - Phase 4 läuft mit erweitertem Scope (Punkte 1–5 + 6–9) — Atlas