commit f22c5ebbfe442258ee65a840864bc1fe410f35b7
Author: Thomas
Date: Mon Apr 13 16:43:42 2026 +0200
Stand 2026-04-13: PHP/MySQL Infrastruktur, Flussmanagement, Stadt-Prototyp
- PHP/MySQL Backend (XAMPP + Produktionsserver)
- Front-Controller, API-Endpunkte, Session-Management
- Flussmanagement-Simulation (Echtzeit, Punkt-basierter Fluss)
- Stadt & Raumplanung (Prototyp, Top-Down Kachelsystem)
- Klimawaechter 3D: Deiche kleiner, Baeume kippen, Budget angepasst
- persistence.ts: Dualer Speicher (localStorage + Server-API)
- 6 Unit-Test-Dateien fuer bestehende Simulationen
Co-Authored-By: Claude Opus 4.6 (1M context)
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..5a81401
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,7 @@
+node_modules/
+App/node_modules/
+App/dist/
+App/.env.local
+App/.env.production
+App/Don_t_Deploy/.env
+.claude/
diff --git a/.humanInput/FlussSimulation b/.humanInput/FlussSimulation
new file mode 100644
index 0000000..7d56301
--- /dev/null
+++ b/.humanInput/FlussSimulation
@@ -0,0 +1,594 @@
+Pflichtenheft
+Simulation „Flussmanagement“ für den Geografieunterricht
+1. Ziel des Projekts
+
+Ziel ist die Entwicklung einer interaktiven Simulation für den Geografieunterricht (Sekundarstufe I, 10–15 Jahre), in der Schülerinnen und Schüler ein Flusssystem steuern und dabei Zielkonflikte zwischen:
+
+Hochwasserschutz
+Landwirtschaft
+Ökologie
+Wirtschaft
+
+erkennen und ausbalancieren.
+
+Die Simulation soll sich wie ein Spiel anfühlen, aber fachlich korrekt und didaktisch wirksam sein.
+
+2. Zielgruppe
+Schülerinnen und Schüler (10–15 Jahre)
+Lehrpersonen (Geografie, ggf. fächerübergreifend)
+Einsatz im Klassenverband (Einzel- oder Gruppenarbeit)
+3. Zentrale didaktische Ziele
+
+Die Anwendung muss ermöglichen:
+
+Verständnis von Mensch–Umwelt-Systemen
+Erkennen von Zielkonflikten (Trade-offs)
+Einsicht in nichtlineare Zusammenhänge
+Bewertung von Eingriffen in Naturräume
+Reflexion historischer Entwicklungen (optional)
+4. Spielprinzip
+
+Der Spieler übernimmt die Rolle eines Entscheidungsträgers (z. B. Region/Behörde) und steuert Maßnahmen an einem Fluss.
+
+Grundmechanik
+Spieler wählt Steuermaßnahmen
+Simulation berechnet Auswirkungen
+Spieler sieht visuelle Veränderungen
+Spiel bewertet Ergebnis anhand mehrerer Ziele
+5. Spieldauer
+
+Das Spiel muss konfigurierbar sein:
+
+Leveltyp Dauer
+Kurzlevel 10–15 Minuten
+Standardlevel 20–30 Minuten
+Langlevel 30–40 Minuten
+Steuerung der Dauer über:
+Anzahl der Runden
+Anzahl aktiver Parameter
+Ereignisdichte
+Komplexität der Entscheidungen
+6. Spielstruktur
+6.1 Rundenbasiertes System
+
+Ein Level besteht aus mehreren Runden:
+
+Situation anzeigen
+Spieler trifft Entscheidungen
+Simulation wird berechnet
+Ergebnisse werden visualisiert
+ggf. Ereignis tritt ein
+6.2 Levelstruktur
+
+Levels unterscheiden sich durch:
+
+Rahmenbedingungen
+freigeschaltete Maßnahmen
+Zielgewichtung
+Schwierigkeit
+7. Steuergrößen (Spieleraktionen)
+
+Mindestens folgende Maßnahmen müssen implementiert werden:
+
+Flussbegradigung
+Dämme bauen
+Ausbaggern
+Auen freigeben
+Renaturierung
+Bewässerung
+
+Jede Maßnahme:
+
+hat Intensität (0–100)
+hat Kosten
+hat positive und negative Effekte
+8. Zustandsparameter (Simulation)
+
+Alle Werte liegen im Bereich 0–100:
+
+Risiken
+Lokales Hochwasser
+Hochwasser flussabwärts
+Erosion
+Nutzen
+Bodenfruchtbarkeit
+Biodiversität
+Grundwasser
+Nutzbare Fläche
+Wirtschaft
+9. Rahmenbedingungen
+
+Pro Level definierbar:
+
+Niederschlag
+Extremwetter
+Gefälle
+Bevölkerungsdruck
+Budget
+
+Diese sind nicht direkt steuerbar, beeinflussen aber die Simulation.
+
+10. Simulationslogik
+10.1 Grundprinzip
+
+Die Simulation basiert auf:
+
+direkten Effekten von Maßnahmen
+indirekten Wechselwirkungen zwischen Parametern
+nichtlinearen Funktionen
+10.2 Anforderungen an die Logik
+
+Die Simulation muss:
+
+nichtlinear sein (keine einfachen +/– Beziehungen)
+abnehmenden Nutzen bei steigender Intensität abbilden
+überproportionale Nebenwirkungen bei starken Eingriffen erzeugen
+Kettenreaktionen ermöglichen
+10.3 Beispielhafte Effekte
+Begradigung → mehr Fläche, aber mehr Hochwasser flussabwärts
+Dämme → lokaler Schutz, aber Nachteile für Landwirtschaft
+Renaturierung → ökologische Vorteile, aber weniger Fläche
+11. Bewertungssystem
+11.1 Zielbereiche
+
+Das Spiel bewertet:
+
+Sicherheit
+Ökologie
+Landwirtschaft
+Wirtschaft
+11.2 Mehrzielbewertung
+
+Es gibt keine perfekte Lösung.
+
+Gesamtscore basiert auf gewichteter Kombination:
+
+Score = f(Sicherheit, Ökologie, Landwirtschaft, Wirtschaft)
+
+Gewichtung ist je Level anpassbar.
+
+12. Balancing-Anforderungen
+
+Das System muss sicherstellen:
+
+12.1 Keine dominante Strategie
+Keine Maßnahme darf immer optimal sein
+12.2 Zielkonflikte
+Jede Maßnahme muss mindestens einen Nachteil haben
+12.3 Kontextabhängigkeit
+Wirkung hängt von Rahmenbedingungen ab
+12.4 Extremwerte vermeiden
+Maximale Eingriffe müssen Risiken erzeugen
+13. Spielmechaniken gegen Fehlverhalten
+Muss implementiert werden:
+Budgetbegrenzung
+Strafsystem für extreme Eingriffe
+Katastrophen bei kritischen Zuständen
+Bonus für ausgewogene Strategien
+14. Visualisierung
+
+Die Simulation muss visuell darstellen:
+
+Hochwasser (Überflutung)
+Flussverlauf (gerade vs. mäandrierend)
+Vegetation / Biodiversität
+Landwirtschaft (Ertrag sichtbar)
+Bebauung
+Wichtig:
+
+Jede Änderung im Modell muss sichtbar sein.
+
+15. Benutzeroberfläche
+Anforderungen
+einfache Bedienung (Schüler geeignet)
+klare Rückmeldung
+visuelle Feedbacks statt Zahlenlast
+Parameter optional einblendbar
+16. Admin-/Lehrermodus
+
+Muss enthalten:
+
+Auswahl von Levels
+Anpassung von:
+Budget
+Klima
+Zielgewichtung
+Aktivieren/Deaktivieren von Maßnahmen
+Festlegen der Spieldauer
+17. Technische Anforderungen
+Frontend
+Web-basiert (HTML, JS, optional TypeScript)
+responsiv
+keine Installation nötig
+Backend (optional)
+für Speicherung von Szenarien
+keine Pflicht für Minimalversion
+18. Erweiterbarkeit
+
+Das System muss modular aufgebaut sein, damit später ergänzt werden kann:
+
+historische Level
+weitere Naturprozesse
+andere geografische Themen
+19. Test- und Balancing-System
+
+Das System muss ein internes oder separates Modul enthalten, das:
+
+viele Strategien automatisch testet
+dominante Strategien erkennt
+Extremverhalten identifiziert
+Balanceprobleme meldet
+20. Abnahmekriterien
+
+Das System gilt als erfolgreich, wenn:
+
+ein Level in 10–40 Minuten spielbar ist
+mehrere unterschiedliche Strategien zum Erfolg führen
+keine einzelne Maßnahme dominiert
+Auswirkungen visuell nachvollziehbar sind
+Schüler Zielkonflikte erkennen können
+21. Anhänge
+Anhang A: Datenmodell (JSON)
+Anhang B: Beispiel-Simulationslogik
+Anhang C: Balancing-Tester
+
+(Diese basieren auf den zuvor entwickelten Modellen und werden als Referenz bereitgestellt.)
+
+Fazit
+
+Dieses Pflichtenheft beschreibt kein einfaches Spiel, sondern ein:
+
+dynamisches, nichtlineares, mehrzieliges Simulationssystem für didaktisches Lernen
+
+Wenn du willst, gehe ich im nächsten Schritt noch weiter und erstelle dir:
+
+konkrete Level (z. B. Nildelta, Industrialisierung, Alpenfluss)
+oder eine fertige Prompt-Version für eine Programmier-KI (z. B. Cursor, GPT, etc.)
+
+Das wäre der nächste logische Schritt.
+
+Ja mach das mit dem konkreten Level noch als Ergänzung
+
+Gut — ich ergänze das Pflichtenheft jetzt um konkrete, sofort implementierbare Level-Spezifikationen.
+Diese sind so formuliert, dass eine KI sie direkt in Datenstrukturen oder Code übersetzen kann.
+
+Ergänzung zum Pflichtenheft: Konkrete Leveldefinitionen
+22. Levelsystem – Struktur
+
+Jedes Level wird formal definiert durch:
+
+type LevelDefinition = {
+ id: string;
+ title: string;
+ description: string;
+
+ durationTargetMinutes: number;
+
+ initialState: State;
+ conditions: Conditions;
+
+ allowedControls: (keyof Controls)[];
+ controlLimits: Partial;
+
+ scoreWeights: {
+ safety: number;
+ ecology: number;
+ agriculture: number;
+ economy: number;
+ };
+
+ rounds: number;
+
+ events?: LevelEvent[];
+
+ winConditions: {
+ minScore?: number;
+ targetScores?: Partial;
+ };
+
+ loseConditions?: {
+ maxFloodLocal?: number;
+ maxFloodDownstream?: number;
+ minGroundwater?: number;
+ };
+};
+23. Level 1 – Einstieg: „Fluss und Siedlung“
+Ziel
+
+Grundverständnis von Hochwasser und einfachen Maßnahmen
+
+const level1: LevelDefinition = {
+ id: "L1",
+ title: "Fluss und Siedlung",
+ description: "Eine kleine Siedlung liegt an einem Fluss und ist regelmäßig von Hochwasser betroffen.",
+
+ durationTargetMinutes: 10,
+
+ rounds: 5,
+
+ initialState: {
+ floodLocal: 60,
+ floodDownstream: 40,
+ erosion: 30,
+ soilFertility: 60,
+ biodiversity: 70,
+ groundwater: 55,
+ usableLand: 40,
+ economy: 40
+ },
+
+ conditions: {
+ rainfall: 60,
+ extremeWeather: 30,
+ slope: 40,
+ populationPressure: 30,
+ budget: 120
+ },
+
+ allowedControls: ["levees", "floodplainRelease"],
+ controlLimits: {
+ levees: 60,
+ floodplainRelease: 60
+ },
+
+ scoreWeights: {
+ safety: 0.5,
+ ecology: 0.2,
+ agriculture: 0.15,
+ economy: 0.15
+ },
+
+ winConditions: {
+ minScore: 60
+ },
+
+ loseConditions: {
+ maxFloodLocal: 85
+ }
+};
+24. Level 2 – Landwirtschaft: „Fruchtbares Tal“
+Fokus
+
+Nutzen von Überschwemmungen vs. Risiko
+
+const level2: LevelDefinition = {
+ id: "L2",
+ title: "Fruchtbares Tal",
+ description: "Ein Tal lebt von fruchtbaren Böden durch regelmäßige Überschwemmungen.",
+
+ durationTargetMinutes: 20,
+
+ rounds: 7,
+
+ initialState: {
+ floodLocal: 55,
+ floodDownstream: 35,
+ erosion: 35,
+ soilFertility: 75,
+ biodiversity: 65,
+ groundwater: 60,
+ usableLand: 45,
+ economy: 50
+ },
+
+ conditions: {
+ rainfall: 65,
+ extremeWeather: 40,
+ slope: 35,
+ populationPressure: 40,
+ budget: 150
+ },
+
+ allowedControls: ["levees", "floodplainRelease", "irrigation"],
+
+ scoreWeights: {
+ safety: 0.25,
+ ecology: 0.2,
+ agriculture: 0.4,
+ economy: 0.15
+ },
+
+ winConditions: {
+ targetScores: {
+ agriculture: 65,
+ safety: 50
+ }
+ }
+};
+25. Level 3 – Industrialisierung: „Der gezähmte Fluss“
+Fokus
+
+Technische Eingriffe und ihre Folgen
+
+const level3: LevelDefinition = {
+ id: "L3",
+ title: "Der gezähmte Fluss",
+ description: "Der Fluss soll kontrolliert werden, um Städte und Industrie zu schützen.",
+
+ durationTargetMinutes: 25,
+
+ rounds: 8,
+
+ initialState: {
+ floodLocal: 50,
+ floodDownstream: 45,
+ erosion: 40,
+ soilFertility: 55,
+ biodiversity: 50,
+ groundwater: 50,
+ usableLand: 55,
+ economy: 60
+ },
+
+ conditions: {
+ rainfall: 60,
+ extremeWeather: 45,
+ slope: 50,
+ populationPressure: 70,
+ budget: 180
+ },
+
+ allowedControls: [
+ "levees",
+ "straightening",
+ "dredging"
+ ],
+
+ scoreWeights: {
+ safety: 0.4,
+ ecology: 0.1,
+ agriculture: 0.2,
+ economy: 0.3
+ },
+
+ events: [
+ {
+ round: 4,
+ type: "flood_event",
+ intensity: 70
+ }
+ ],
+
+ winConditions: {
+ minScore: 65
+ }
+};
+26. Level 4 – Systemdenken: „Fluss im Gleichgewicht“
+Fokus
+
+Mehrere Ziele gleichzeitig
+
+const level4: LevelDefinition = {
+ id: "L4",
+ title: "Fluss im Gleichgewicht",
+ description: "Finde eine Balance zwischen Sicherheit, Natur und Nutzung.",
+
+ durationTargetMinutes: 30,
+
+ rounds: 10,
+
+ initialState: {
+ floodLocal: 55,
+ floodDownstream: 50,
+ erosion: 45,
+ soilFertility: 60,
+ biodiversity: 60,
+ groundwater: 50,
+ usableLand: 50,
+ economy: 55
+ },
+
+ conditions: {
+ rainfall: 60,
+ extremeWeather: 50,
+ slope: 45,
+ populationPressure: 60,
+ budget: 180
+ },
+
+ allowedControls: [
+ "levees",
+ "straightening",
+ "floodplainRelease",
+ "renaturation",
+ "irrigation"
+ ],
+
+ scoreWeights: {
+ safety: 0.25,
+ ecology: 0.25,
+ agriculture: 0.25,
+ economy: 0.25
+ },
+
+ winConditions: {
+ minScore: 70
+ }
+};
+27. Level 5 – Speziallevel: Nildelta
+
+Bezug zur realen Welt und deinem Wunsch nach nicht einseitigem Denken
+
+Fokus
+
+Überschwemmung als Vorteil
+
+const level5: LevelDefinition = {
+ id: "L5",
+ title: "Nildelta",
+ description: "Die Überschwemmungen bringen fruchtbare Böden – aber auch Risiken.",
+
+ durationTargetMinutes: 35,
+
+ rounds: 10,
+
+ initialState: {
+ floodLocal: 65,
+ floodDownstream: 40,
+ erosion: 30,
+ soilFertility: 85,
+ biodiversity: 70,
+ groundwater: 65,
+ usableLand: 50,
+ economy: 60
+ },
+
+ conditions: {
+ rainfall: 40,
+ extremeWeather: 20,
+ slope: 20,
+ populationPressure: 70,
+ budget: 160
+ },
+
+ allowedControls: [
+ "levees",
+ "irrigation",
+ "floodplainRelease"
+ ],
+
+ scoreWeights: {
+ safety: 0.2,
+ ecology: 0.2,
+ agriculture: 0.45,
+ economy: 0.15
+ },
+
+ winConditions: {
+ targetScores: {
+ agriculture: 75
+ }
+ },
+
+ loseConditions: {
+ minGroundwater: 25
+ }
+};
+28. Ereignissystem (für alle Levels)
+type LevelEvent = {
+ round: number;
+ type: "flood_event" | "drought" | "economic_boost";
+ intensity: number;
+};
+
+Beispiele:
+
+Hochwasser
+Dürre
+wirtschaftlicher Boom
+29. Didaktische Progression
+Level Konzept
+1 Ursache-Wirkung
+2 Nutzen vs Risiko
+3 Technik vs Natur
+4 Systemdenken
+5 Realwelt + Transfer
+30. Abschluss
+
+Mit dieser Ergänzung hat deine KI jetzt:
+
+ein vollständiges Spielsystem
+ein Simulationsmodell
+ein Balancing-Konzept
+konkrete Leveldaten
+klare didaktische Struktur
\ No newline at end of file
diff --git a/.humanInput/StadtRaumplanung b/.humanInput/StadtRaumplanung
new file mode 100644
index 0000000..7d464ec
--- /dev/null
+++ b/.humanInput/StadtRaumplanung
@@ -0,0 +1,14 @@
+Pflichtenheft — Lernsimulation „Stadt & Raumplanung"
+(Gespeichert aus User-Input, 2026-04-13)
+
+Siehe Konversation fuer vollstaendiges Pflichtenheft.
+Kernpunkte:
+- Kachelbasierte Stadtsimulation, 2D Top-Down oder isometrisch
+- Strassen mit Anschlusslogik (N/E/S/W Connections)
+- Kacheltypen: Strasse, Wohngebiet, Geschaeft, Schule, Park, Industrie, Energie
+- Zustandsparameter: traffic, environment, economy, satisfaction, accessibility
+- Nichtlineare Simulation mit Zielkonflikten
+- Runden- oder Echtzeit-basiert
+- Lehrkraefte-Modul mit Vergleichsansicht
+- Balancing: keine dominante Strategie
+- 10-40 Minuten Spieldauer
diff --git a/.humanInput/stadtsimulation b/.humanInput/stadtsimulation
new file mode 100644
index 0000000..2c8f944
--- /dev/null
+++ b/.humanInput/stadtsimulation
@@ -0,0 +1,1126 @@
+Gut. Dann setze ich jetzt **Pflichtenheft V2** auf: **didaktisch sauber, technisch klar, bewusst einfacher als SimCity**, aber so präzise, dass eine KI es sauber umsetzen kann.
+
+---
+
+# Pflichtenheft V2
+
+## Lernsimulation „Stadt & Raumplanung“
+
+### für Schüler:innen von ca. 10 bis 15 Jahren
+
+---
+
+# 1. Projektziel
+
+Es soll eine webbasierte Lernsimulation entwickelt werden, in der Schüler:innen eine kleine Siedlung bzw. Stadt schrittweise aufbauen und weiterentwickeln. Das Spiel soll zentrale geographische und gesellschaftliche Zusammenhänge erfahrbar machen, insbesondere:
+
+* Raumplanung
+* Infrastruktur
+* Nahversorgung
+* Verkehr
+* Umwelt
+* Lebensqualität
+* Zielkonflikte zwischen Wachstum, Versorgung und Nachhaltigkeit
+
+Die Simulation ist **didaktisch priorisiert**. Sie soll **nicht** den Anspruch haben, eine realistische Stadtplanungssoftware zu sein, sondern ein **verständlich reduziertes System**, das sich spielerisch anfühlt und dennoch fachlich sinnvoll ist.
+
+---
+
+# 2. Didaktische Leitidee
+
+Die Anwendung soll Schüler:innen nicht nur „bauen lassen“, sondern ihnen zeigen, dass räumliche Entscheidungen Folgen haben.
+
+Die Lernenden sollen erkennen:
+
+* dass Gebäude und Infrastruktur voneinander abhängen
+* dass gute Versorgung nicht automatisch gute Umwelt bedeutet
+* dass Verkehr, Erreichbarkeit und Lebensqualität zusammenhängen
+* dass nicht jede kurzfristig gute Entscheidung langfristig sinnvoll ist
+* dass ausgewogene Planung oft besser ist als extreme Spezialisierung
+
+Die Simulation soll also **Systemdenken** fördern.
+
+---
+
+# 3. Zielgruppe
+
+Primäre Zielgruppe:
+
+* Schüler:innen im Alter von 10 bis 15 Jahren
+
+Sekundäre Zielgruppe:
+
+* Lehrpersonen im Fach Geografie
+* ggf. fachübergreifend mit Wirtschaft, Technik, Informatik oder Umweltbildung
+
+---
+
+# 4. Einsatzkontext
+
+Die Simulation ist in ein bestehendes Lernprogramm eingebettet. Sie ist **eine von mehreren Simulationen**.
+
+Daraus folgen diese Anforderungen:
+
+* Die Simulation muss ohne lange Einführung verständlich sein.
+* Eine Runde bzw. ein Level muss innerhalb einer Unterrichtsphase bearbeitbar sein.
+* Lehrpersonen sollen Ergebnisse mehrerer Schüler:innen vergleichen können.
+* Das System soll kompakt genug sein, damit es nicht die gesamte Plattform dominiert.
+
+---
+
+# 5. Spieldauer
+
+Die Simulation muss konfigurierbar sein, sodass einzelne Szenarien je nach Komplexität typischerweise zwischen **10 und 40 Minuten** dauern.
+
+## 5.1 Zielwerte
+
+* Kurzlevel: 10–15 Minuten
+* Standardlevel: 20–30 Minuten
+* Langlevel: 30–40 Minuten
+
+## 5.2 Einflussfaktoren auf die Dauer
+
+Die Spieldauer wird gesteuert durch:
+
+* Größe des Spielrasters
+* Anzahl freigeschalteter Kacheltypen
+* Anzahl der Runden
+* Anzahl der Ereignisse
+* Zahl der gleichzeitig sichtbaren Kennwerte
+* Komplexität der Ziele
+
+---
+
+# 6. Grundprinzip des Spiels
+
+Der Spieler entwickelt eine kleine Ansiedlung Schritt für Schritt weiter.
+
+Zu Beginn gibt es nur sehr wenige Elemente, zum Beispiel:
+
+* eine vorhandene Straße
+* wenige Häuser
+* freie Bauflächen
+* einen ersten Bedarf, etwa nach einem Nahversorger
+
+Im Laufe des Spiels kommen neue Anforderungen hinzu, zum Beispiel:
+
+* bessere Erreichbarkeit
+* mehr Wohnraum
+* Schule
+* Grünflächen
+* Verkehrsprobleme
+* sinkende Umweltqualität
+
+Der Spieler reagiert darauf, indem er **Kacheln platziert**. Diese Platzierungen verändern die Stadt und ihre Kennwerte.
+
+---
+
+# 7. Spielwelt und Darstellung
+
+## 7.1 Version A als verbindlicher Standard
+
+Die verbindliche Grundversion wird als **2D-Top-Down-Spiel** umgesetzt.
+
+Gründe:
+
+* klarer
+* technisch einfacher
+* robuster
+* didaktisch fokussierter
+* schneller umsetzbar
+
+## 7.2 Isometrie nur optional
+
+Eine pseudo-isometrische Darstellung ist **nicht Bestandteil der Pflichtversion**, kann aber später als Erweiterung ergänzt werden.
+
+---
+
+# 8. Spielfeld
+
+## 8.1 Raster
+
+Das Spielfeld besteht aus einem rechteckigen Raster aus gleich großen Kacheln.
+
+Empfohlene Größen:
+
+* klein: 8 × 8
+* mittel: 10 × 10
+* groß: 12 × 12
+
+Die Pflichtversion soll mindestens mit 10 × 10 sicher funktionieren.
+
+## 8.2 Kachelprinzip
+
+Jede Rasterzelle enthält genau eine Kachel. Eine Kachel kann leer sein oder einen bestimmten Typ haben.
+
+Beispiele:
+
+* leer
+* Straße
+* Kreuzung
+* Wohnhaus
+* Laden
+* Schule
+* Park
+* Industrie
+* Bushaltestelle
+
+---
+
+# 9. Zentrale Begriffe des Systems
+
+Das gesamte Modell basiert auf drei Ebenen:
+
+## 9.1 Rahmenbedingungen
+
+Das sind Ausgangsbedingungen, die der Spieler nicht direkt steuert.
+
+Beispiele:
+
+* Startbudget
+* Anfangsbevölkerung
+* Umweltwert
+* Größe des Spielfelds
+* Ziele des Levels
+
+## 9.2 Steuergrößen
+
+Das sind die Aktionen des Spielers.
+
+Beispiele:
+
+* Straße platzieren
+* Wohnhaus bauen
+* Laden bauen
+* Park bauen
+* Schule platzieren
+
+## 9.3 Folgeparameter
+
+Das sind die Werte, die sich durch die Entscheidungen verändern.
+
+Beispiele:
+
+* Verkehr
+* Umwelt
+* Zufriedenheit
+* Wirtschaft
+* Erreichbarkeit
+
+Diese Struktur muss in der Implementierung klar getrennt werden.
+
+---
+
+# 10. Kacheltypen der Pflichtversion
+
+Die Pflichtversion soll bewusst reduziert bleiben. Es werden nur die nötigsten Kacheltypen verlangt.
+
+## 10.1 Leerkachel
+
+* enthält keine Bebauung
+* hat keine Funktion
+* kann bebaut werden
+
+## 10.2 Straßenkacheln
+
+Pflichtversion:
+
+* Straße gerade horizontal
+* Straße gerade vertikal
+* Kurve
+* T-Kreuzung
+* Viererkreuzung
+* Sackgasse
+
+Jede Straßenkachel besitzt definierte Anschlüsse in die vier Himmelsrichtungen:
+
+* Norden
+* Osten
+* Süden
+* Westen
+
+## 10.3 Gebäudekacheln
+
+Pflichtversion:
+
+* Wohnhaus
+* Laden / Nahversorger
+* Schule
+* Park
+* Industrie / Gewerbe
+* Bushaltestelle
+
+## 10.4 Gebäudegröße
+
+In der Pflichtversion sind **alle Gebäude genau 1×1 Kachel groß**.
+
+Mehrfeld-Gebäude sind nicht Teil der Pflichtversion.
+
+---
+
+# 11. Kachel-Datenmodell
+
+Die KI soll intern mit einem strukturierten Tile-Modell arbeiten.
+
+Beispielstruktur:
+
+```ts
+type TileType =
+ | "empty"
+ | "road_straight_h"
+ | "road_straight_v"
+ | "road_curve_ne"
+ | "road_curve_es"
+ | "road_curve_sw"
+ | "road_curve_wn"
+ | "road_t_n"
+ | "road_t_e"
+ | "road_t_s"
+ | "road_t_w"
+ | "road_cross"
+ | "road_dead_n"
+ | "road_dead_e"
+ | "road_dead_s"
+ | "road_dead_w"
+ | "house"
+ | "shop"
+ | "school"
+ | "park"
+ | "industry"
+ | "bus_stop";
+```
+
+Jede Kachel muss zusätzlich folgende Eigenschaften besitzen:
+
+```ts
+type Tile = {
+ id: string;
+ x: number;
+ y: number;
+ type: TileType;
+ connections: {
+ north: boolean;
+ east: boolean;
+ south: boolean;
+ west: boolean;
+ };
+ buildCost: number;
+ effects: Partial;
+};
+```
+
+---
+
+# 12. Platzierungslogik
+
+## 12.1 Didaktische Grundentscheidung
+
+Falsche Platzierungen sollen **nicht hart blockiert**, sondern grundsätzlich erlaubt werden, sofern sie technisch möglich sind.
+
+Das ist bewusst so gewählt, weil Fehler didaktisch sichtbar werden sollen.
+
+## 12.2 Ungültige und problematische Platzierung
+
+Es gibt drei Kategorien:
+
+### A. technisch unmöglich
+
+Diese Aktionen werden nicht zugelassen.
+
+Beispiele:
+
+* außerhalb des Rasters platzieren
+* auf bereits belegter Kachel platzieren
+* ohne Budget bauen
+
+### B. technisch möglich, aber schlecht
+
+Diese Aktionen werden erlaubt und haben negative Folgen.
+
+Beispiele:
+
+* Straße endet sinnlos
+* Laden ohne Erreichbarkeit
+* Schule weit weg von Wohnhäusern
+* Industrie direkt neben Park oder Wohnhaus
+
+### C. sinnvoll
+
+Diese Aktionen verbessern das System.
+
+---
+
+# 13. Anschluss- und Erreichbarkeitslogik
+
+Dies ist ein zentrales Pflichtmerkmal.
+
+## 13.1 Straßennetz
+
+Straßen bilden ein Netz. Zwei benachbarte Straßen sind verbunden, wenn ihre Anschlussrichtungen zusammenpassen.
+
+Beispiel:
+
+* Kachel A hat Anschluss nach Osten
+* Kachel B rechts daneben hat Anschluss nach Westen
+* dann sind beide verbunden
+
+## 13.2 Erreichbarkeit von Gebäuden
+
+Gebäude gelten nur dann als „versorgt“ oder „aktiv“, wenn sie an das Straßennetz angeschlossen sind oder direkt an eine Straße angrenzen.
+
+Für die Pflichtversion reicht folgende Regel:
+
+* Ein Gebäude ist erreichbar, wenn mindestens eine der vier Nachbarkacheln eine passende Straßenkachel ist.
+
+Spätere Versionen könnten Netzwerkanalyse verwenden, aber das ist nicht Pflicht.
+
+---
+
+# 14. Spielziel
+
+Das Spielziel ist **nicht** nur „möglichst viel bauen“.
+
+Gewonnen wird ein Level, wenn definierte Zielwerte erreicht werden.
+
+Beispiele:
+
+* Mindestzufriedenheit
+* ausreichende Versorgung
+* Umwelt nicht zu schlecht
+* kein Verkehrschaos
+* Mindestwirtschaftswert
+
+Ein Level kann also nur bestanden werden, wenn mehrere Zielbereiche zugleich in einem akzeptablen Zustand sind.
+
+---
+
+# 15. Kernparameter der Simulation
+
+Die Pflichtversion soll mit wenigen, aber aussagekräftigen Parametern arbeiten.
+
+Alle Werte liegen auf einer Skala von 0 bis 100.
+
+## 15.1 Wirtschaft
+
+Wie gut die Stadt ökonomisch funktioniert.
+
+Beeinflusst durch:
+
+* Läden
+* Industrie
+* Versorgung
+* Zufriedenheit
+* Erreichbarkeit
+
+## 15.2 Zufriedenheit
+
+Wie zufrieden die Bevölkerung ist.
+
+Beeinflusst durch:
+
+* Erreichbarkeit
+* Versorgung
+* Parks
+* Schule
+* geringe Umweltbelastung
+* wenig Verkehrsprobleme
+
+## 15.3 Umwelt
+
+Qualität der Umwelt.
+
+Beeinflusst durch:
+
+* Parks positiv
+* Industrie negativ
+* hohe Verkehrsbelastung negativ
+
+## 15.4 Verkehr
+
+Belastung des Straßennetzes.
+
+Beeinflusst durch:
+
+* Anzahl Gebäude
+* fehlende Verbindungen
+* Industrie
+* schlechte Verteilung
+
+## 15.5 Versorgung
+
+Wie gut die Bevölkerung Zugang zu wichtigen Angeboten hat.
+
+Beeinflusst durch:
+
+* Laden
+* Schule
+* Bushaltestellen
+* Erreichbarkeit
+
+## 15.6 Erreichbarkeit
+
+Wie gut wichtige Gebäude miteinander verbunden sind.
+
+Beeinflusst durch:
+
+* Straßennetz
+* Lage
+* Isolation einzelner Kacheln
+
+---
+
+# 16. Simulationsphilosophie
+
+Die Simulation muss **einfach verständlich**, aber **nicht trivial** sein.
+
+Sie muss folgende Eigenschaften haben:
+
+* positive und negative Effekte zugleich
+* keine Maßnahme ist immer gut
+* extreme Spezialisierung soll Nachteile erzeugen
+* mehrere brauchbare Lösungswege sollen möglich sein
+
+---
+
+# 17. Simulationsmodell der Pflichtversion
+
+Die Pflichtversion darf mit einem diskreten Rundenmodell arbeiten.
+
+Nach jeder Runde oder nach jeder Bauaktion werden die Kennwerte neu berechnet.
+
+## 17.1 Vereinfachtes Modell
+
+Jede Kachel hat Grundeffekte.
+Zusätzlich kommen Lage- und Nachbarschaftseffekte hinzu.
+
+### Beispielhafte Grundeffekte
+
+| Kachel | Wirtschaft | Zufriedenheit | Umwelt | Verkehr | Versorgung |
+| -------------- | ---------: | ------------: | -----: | ------: | ---------: |
+| Haus | +2 | +1 | 0 | +1 | 0 |
+| Laden | +4 | +2 | -1 | +2 | +5 |
+| Schule | +1 | +5 | 0 | +1 | +4 |
+| Park | 0 | +4 | +6 | 0 | +1 |
+| Industrie | +6 | -3 | -6 | +4 | 0 |
+| Bushaltestelle | +1 | +2 | +1 | -1 | +3 |
+
+Diese Zahlen sind Startwerte und müssen konfigurierbar sein.
+
+---
+
+# 18. Nachbarschaftseffekte
+
+Neben den Grundeffekten müssen lokale Nachbarschaften berücksichtigt werden.
+
+## 18.1 Positive Beispiele
+
+* Park neben Haus: Zufriedenheit +2
+* Laden nahe Wohnhäusern: Versorgung +2
+* Schule nahe Wohnhäusern: Zufriedenheit +2
+* Bushaltestelle bei Laden oder Schule: Erreichbarkeit +2
+
+## 18.2 Negative Beispiele
+
+* Industrie neben Haus: Zufriedenheit -4, Umwelt -3
+* Industrie neben Park: Umwelt -4
+* Sackgassenhäufung: Verkehr +2
+* isolierter Laden ohne Anbindung: Wirtschaft -3, Versorgung -4
+
+---
+
+# 19. Reichweitenmodell
+
+Für die Pflichtversion genügt ein einfaches Distanzmodell auf Rasterbasis.
+
+## 19.1 Empfohlene Reichweiten
+
+* Laden versorgt Häuser im Umkreis von 3 Kacheln
+* Schule wirkt im Umkreis von 4 Kacheln
+* Park wirkt im Umkreis von 2 Kacheln
+* Bushaltestelle verbessert Erreichbarkeit im Umkreis von 3 Kacheln
+
+Die Distanz kann zunächst als Manhattan-Distanz berechnet werden.
+
+---
+
+# 20. Rundenablauf
+
+Ein Level läuft rundenbasiert.
+
+## 20.1 Pflichtablauf pro Runde
+
+1. Aktuelle Stadt anzeigen
+2. Ereignis oder Bedarf anzeigen
+3. Spieler erhält Budget für die Runde oder nutzt vorhandenes Budget
+4. Spieler platziert 1 bis n Kacheln
+5. Spiel berechnet neue Kennwerte
+6. Spiel zeigt Feedback
+7. Prüfen auf Sieg / Niederlage / Fortsetzung
+
+---
+
+# 21. Ereignissystem
+
+Das Spiel soll über Ereignisse oder Meldungen gesteuert werden, damit es nicht bloß ein freies Bauen ist.
+
+## 21.1 Typen von Ereignissen
+
+* Bedarfsmeldungen
+* Warnungen
+* Zielmeldungen
+* Zwischenfeedback
+
+## 21.2 Beispiele
+
+* „Die Bewohner wünschen sich einen kleinen Laden.“
+* „Die Verkehrsbelastung steigt.“
+* „Die Umweltqualität sinkt.“
+* „Viele Häuser sind schlecht versorgt.“
+* „Ein Park würde die Lebensqualität verbessern.“
+
+## 21.3 Funktion
+
+Ereignisse dienen dazu:
+
+* die Aufmerksamkeit zu lenken
+* den nächsten sinnvollen Schritt vorzuschlagen
+* die Komplexität schrittweise aufzubauen
+
+---
+
+# 22. Progression
+
+Die Simulation muss neue Elemente schrittweise freischalten.
+
+## 22.1 Didaktische Reihenfolge
+
+Empfohlene Stufen:
+
+### Stufe 1
+
+* Straße
+* Haus
+* Laden
+
+### Stufe 2
+
+* Park
+* Bushaltestelle
+
+### Stufe 3
+
+* Schule
+
+### Stufe 4
+
+* Industrie
+
+Diese Progression ist Pflichtbestandteil des Designs, auch wenn einzelne Levels später davon abweichen dürfen.
+
+---
+
+# 23. UI der Pflichtversion
+
+## 23.1 Hauptaufbau
+
+Die Benutzeroberfläche besteht mindestens aus vier Bereichen:
+
+### A. Spielfeld
+
+Raster mit allen Kacheln
+
+### B. Werkzeugleiste
+
+Auswahl der verfügbaren Kacheln
+
+### C. Statusbereich
+
+Anzeige der wichtigsten Kennwerte
+
+### D. Nachrichtenbereich
+
+Ereignisse, Hinweise, Feedback
+
+---
+
+## 23.2 Interaktion
+
+Pflichtversion:
+
+* Kachel in der Werkzeugleiste anklicken
+* Zielzelle im Raster anklicken
+* Kachel wird platziert, wenn dies technisch zulässig ist
+* Kennwerte aktualisieren sich danach
+
+Optional:
+
+* Hover-Vorschau
+* Kostenanzeige vor Platzierung
+
+---
+
+# 24. Visuelle Sprache
+
+Die Grafik soll bewusst einfach und klar sein.
+
+## 24.1 Pflichtversion
+
+* 2D
+* reduzierte Symbole
+* gut erkennbare Gebäude
+* Straßen müssen sofort lesbar sein
+
+## 24.2 Stil
+
+* freundlich
+* nicht überladen
+* kinder- und jugendgerecht
+* kein realistischer Stil notwendig
+
+## 24.3 Emojis
+
+Emojis dürfen optional für kleine Animationen oder Objekte verwendet werden, etwa:
+
+* Fahrzeuge
+* Gesichter für Zufriedenheit
+* Warnsymbole
+
+Sie dürfen aber nicht die Kernlesbarkeit des Spielfelds ersetzen.
+
+---
+
+# 25. Balancing-Grundsätze
+
+Die KI muss das Spiel so programmieren, dass keine triviale Patentlösung entsteht.
+
+## 25.1 Pflichtregeln
+
+* Ein Kacheltyp darf nicht allein das Spiel „lösen“.
+* Industrie darf Wirtschaft verbessern, aber Umwelt und Zufriedenheit verschlechtern.
+* Parks dürfen Umwelt und Zufriedenheit verbessern, aber keine Wirtschaft ersetzen.
+* Straßen erhöhen Erreichbarkeit, können aber zu viel Verkehrsfläche erzeugen.
+* Eine gute Lösung muss mehrere Ziele gleichzeitig berücksichtigen.
+
+---
+
+# 26. Bewertungslogik
+
+Die Pflichtversion benötigt ein Mehrzielsystem.
+
+## 26.1 Primäre Zielwerte
+
+* Wirtschaft
+* Zufriedenheit
+* Umwelt
+* Versorgung
+* Verkehr
+* Erreichbarkeit
+
+## 26.2 Umrechnung in Endbewertung
+
+Zusätzlich zu den Einzelwerten soll das Spiel einen Gesamtscore berechnen.
+
+Beispiel:
+
+```ts
+totalScore =
+ 0.22 * economy +
+ 0.24 * satisfaction +
+ 0.18 * environment +
+ 0.16 * supply +
+ 0.12 * accessibility +
+ 0.08 * (100 - traffic);
+```
+
+Die genaue Gewichtung muss pro Level konfigurierbar sein.
+
+---
+
+# 27. Balance-Index
+
+Neben dem Gesamtscore soll ein zweiter Wert berechnet werden:
+
+## 27.1 Balance-Index
+
+Dieser misst, wie ausgewogen die Lösung ist.
+
+Ziel:
+
+* extreme Einseitigkeit sichtbar machen
+
+Beispiel:
+
+* sehr hohe Wirtschaft, aber sehr schlechte Umwelt und Zufriedenheit → niedriger Balance-Index
+
+Der Balance-Index kann über die Streuung der Teilwerte berechnet werden.
+
+---
+
+# 28. Sieg- und Niederlagenbedingungen
+
+## 28.1 Sieg
+
+Ein Level gilt als bestanden, wenn:
+
+* Mindestscore erreicht ist
+* keine harten Negativbedingungen verletzt sind
+* das Rundenziel erreicht wurde
+
+## 28.2 Niederlage
+
+Ein Level gilt als verloren, wenn z. B.:
+
+* Budget aufgebraucht und Ziel klar verfehlt
+* Verkehr zu hoch
+* Zufriedenheit zu niedrig
+* Versorgung zu niedrig
+* Umwelt zu niedrig
+
+Konkrete Schwellwerte müssen je Level definiert werden.
+
+---
+
+# 29. Lehreransicht
+
+Die Simulation ist in ein Lernprogramm eingebettet. Daher muss sie auswertbar sein.
+
+## 29.1 Pflichtdaten pro Spiel
+
+Es müssen mindestens diese Daten gespeichert oder an das übergeordnete System zurückgegeben werden:
+
+* Schüler-ID oder Sitzungs-ID
+* Level-ID
+* Startzeit
+* Endzeit
+* Gesamtdauer
+* Endscore
+* Balance-Index
+* Endwerte aller Hauptparameter
+* Anzahl gesetzter Kacheln pro Typ
+* Anzahl problematischer Platzierungen
+* Sieg / Niederlage
+
+## 29.2 Optionale Lehrpersoneninformationen
+
+Diese Daten können zusätzlich angezeigt werden:
+
+* Strategieprofil
+* Schwerpunkt der Planung
+* einseitige oder ausgewogene Lösung
+* häufigste Fehler
+* Zahl unverbundener Straßen
+* Zahl schlecht versorgter Häuser
+
+Diese Punkte sind als optionale Erweiterung zu behandeln, aber die Datenbasis soll vorbereitet werden.
+
+---
+
+# 30. Auswertungsmodell für Lehrpersonen
+
+Die Lehrperson soll nicht nur sehen, wer „gewonnen“ hat, sondern auch, wie.
+
+## 30.1 Beispielhafte Ergebnisansicht
+
+| Name | Score | Balance | Wirtschaft | Umwelt | Zufriedenheit | Kommentar |
+| ---- | ----: | ------: | ---------: | -----: | ------------: | ---------------------------------------- |
+| A | 78 | 74 | 70 | 72 | 80 | ausgewogene Lösung |
+| B | 81 | 43 | 92 | 28 | 40 | wirtschaftlich stark, ökologisch schwach |
+
+## 30.2 Automatische Kommentare
+
+Optional generierte Kommentare:
+
+* „Die Stadt ist wirtschaftlich stark, aber Umwelt und Zufriedenheit leiden.“
+* „Die Lösung ist gut ausbalanciert.“
+* „Viele wichtige Gebäude sind schlecht erreichbar.“
+* „Es wurden zu viele isolierte Straßen gebaut.“
+
+---
+
+# 31. Technische Architektur
+
+Die KI soll die Anwendung modular aufbauen.
+
+## 31.1 Empfohlene Hauptmodule
+
+* Grid Engine
+* Tile Placement Logic
+* Road Connectivity Logic
+* Simulation Engine
+* Event Engine
+* Scoring Engine
+* UI Renderer
+* Session / Save Adapter
+* Teacher Data Export
+
+## 31.2 Technologie
+
+Pflichtversion:
+
+* HTML
+* CSS
+* JavaScript oder TypeScript
+
+Empfehlung:
+
+* TypeScript
+
+Rendering:
+
+* Canvas oder DOM/SVG
+
+Für Version A ist beides möglich.
+Wenn die KI sauber strukturieren kann, ist ein rasterbasiertes Canvas-Rendering sinnvoll. DOM/SVG ist ebenfalls akzeptabel, wenn die Implementierung einfacher und stabiler wird.
+
+---
+
+# 32. Persistenz
+
+Die Pflichtversion braucht keine komplexe Datenbank im Spiel selbst.
+
+Es muss aber möglich sein:
+
+* Spieldaten pro Sitzung zu speichern
+* Ergebnisse an ein übergeordnetes Lernsystem zu übergeben
+
+Falls keine Plattformanbindung vorhanden ist, genügt vorerst:
+
+* lokaler Speicher
+* JSON-Export
+* Callback-Schnittstelle
+
+---
+
+# 33. Datenformate
+
+Die KI soll Leveldaten nicht hart im Code verankern, sondern über Konfigurationsobjekte steuern.
+
+## 33.1 Beispielstruktur für ein Level
+
+```ts
+type LevelConfig = {
+ id: string;
+ title: string;
+ description: string;
+ gridWidth: number;
+ gridHeight: number;
+ rounds: number;
+ startBudget: number;
+ unlockedTileTypes: TileType[];
+ targetWeights: {
+ economy: number;
+ satisfaction: number;
+ environment: number;
+ supply: number;
+ accessibility: number;
+ traffic: number;
+ };
+ winThreshold: number;
+ loseThresholds: {
+ minEnvironment?: number;
+ minSatisfaction?: number;
+ minSupply?: number;
+ maxTraffic?: number;
+ };
+ initialTiles: Array<{
+ x: number;
+ y: number;
+ type: TileType;
+ }>;
+ scriptedEvents: Array<{
+ round: number;
+ message: string;
+ hint?: string;
+ }>;
+};
+```
+
+---
+
+# 34. Beispiellevel der Pflichtversion
+
+## 34.1 Level 1: Kleine Ansiedlung
+
+Ausgangslage:
+
+* wenige Häuser
+* eine Straße
+* viel freie Fläche
+
+Ziel:
+
+* Nahversorgung schaffen
+* Zufriedenheit erhöhen
+* kein Verkehrschaos erzeugen
+
+Freigeschaltet:
+
+* Straße
+* Haus
+* Laden
+
+Dauer:
+
+* 10–15 Minuten
+
+## 34.2 Level 2: Wachsende Gemeinde
+
+Neu:
+
+* Park
+* Bushaltestelle
+
+Ziel:
+
+* Versorgung und Lebensqualität verbessern
+
+Dauer:
+
+* 15–25 Minuten
+
+## 34.3 Level 3: Schule für den Ort
+
+Neu:
+
+* Schule
+
+Ziel:
+
+* Erreichbarkeit und Zufriedenheit
+
+Dauer:
+
+* 20–30 Minuten
+
+## 34.4 Level 4: Industrie oder Umwelt?
+
+Neu:
+
+* Industrie
+
+Ziel:
+
+* Wirtschaft stärken, aber Umwelt und Zufriedenheit nicht ruinieren
+
+Dauer:
+
+* 25–40 Minuten
+
+---
+
+# 35. Testanforderungen
+
+Die KI soll nicht nur das Spiel bauen, sondern auch ein kleines internes Testsystem vorsehen.
+
+## 35.1 Pflicht-Checks
+
+* Straßenanschlüsse korrekt?
+* Gebäude erreichbar?
+* Score-Berechnung korrekt?
+* Level gewinnbar?
+* Level nicht mit nur einer Maßnahme trivial lösbar?
+
+## 35.2 Balancing-Checks
+
+Die Implementierung soll so vorbereitet sein, dass automatisierte Tests mehrere Baukonstellationen durchspielen können.
+
+Mindestens soll prüfbar sein:
+
+* ob ein einzelner Kacheltyp zu stark ist
+* ob bestimmte Levels ungewinnbar sind
+* ob Extremstrategien das Spiel kaputt machen
+
+---
+
+# 36. Nicht-Ziele der Pflichtversion
+
+Diese Punkte sind ausdrücklich **nicht** Teil der Pflichtversion:
+
+* echtes 3D
+* frei drehbare Kamera
+* komplexe Energieversorgung
+* Wasserleitungen
+* komplexe Einwohner-Simulation pro Person
+* Echtzeitverkehr mit Pfadsuche für hunderte Einheiten
+* mehrfeldrige Großgebäude
+* Netzwerk-Multiplayer
+
+Diese Themen können später ergänzt werden, sollen die Pflichtversion aber nicht verkomplizieren.
+
+---
+
+# 37. Abnahmekriterien
+
+Das Projekt gilt als erfolgreich umgesetzt, wenn folgende Punkte erfüllt sind:
+
+## 37.1 Fachlich
+
+* Zielkonflikte sind erkennbar
+* Planung hat sichtbare Folgen
+* mehrere Lösungswege sind möglich
+
+## 37.2 Didaktisch
+
+* Schüler:innen verstehen die Grundidee ohne lange Erklärung
+* das Spiel ist in 10–40 Minuten spielbar
+* die Lehrperson kann Ergebnisse vergleichen
+
+## 37.3 Technisch
+
+* Raster und Platzierung funktionieren stabil
+* Kennwerte werden korrekt aktualisiert
+* Leveldaten sind konfigurierbar
+* Ergebnisse können gespeichert oder übergeben werden
+
+## 37.4 Spielerisch
+
+* das Spiel motiviert zum Ausprobieren
+* Fehlentscheidungen sind sichtbar
+* keine triviale „immer gleiche“ Gewinnstrategie dominiert
+
+---
+
+# 38. Konkrete Arbeitsanweisung an die KI
+
+Die KI soll auf Basis dieses Pflichtenhefts eine erste lauffähige Version entwickeln mit folgenden Prioritäten:
+
+## Priorität 1
+
+* stabiles Raster
+* Kachelplatzierung
+* Straßennetzlogik
+* Grundsimulation
+* 1 spielbares Level
+
+## Priorität 2
+
+* mehrere Level
+* Ereignissystem
+* Score und Balance-Index
+* Ergebnisansicht
+
+## Priorität 3
+
+* Lehreransicht
+* Export / Schnittstelle
+* Balancing-Verbesserungen
+* grafische Verfeinerung
+
+---
+
+# 39. Umsetzungshinweis
+
+Die KI soll **nicht** versuchen, SimCity nachzubauen.
+Die KI soll eine **kleine, klare, didaktisch reduzierte Lernsimulation** entwickeln, die von der grundsätzlichen Logik klassischer Aufbauspiele inspiriert ist, aber wesentlich einfacher, transparenter und schulgeeignet bleibt.
+
+---
+
+# 40. Empfohlener nächster Schritt
+
+Auf Basis dieses Pflichtenhefts ist der sinnvollste nächste Schritt:
+
+1. daraus eine **Programmier-Prompt-Version** für eine KI zu machen
+ oder
+2. direkt eine **erste MVP-Version** in TypeScript/HTML zu erzeugen
+
+Wenn du willst, mache ich dir als Nächstes die **ultrapraktische Prompt-Fassung für Cursor / GPT / Claude Code**, damit eine KI sofort mit der Implementierung beginnen kann.
diff --git a/App/.env.example b/App/.env.example
new file mode 100644
index 0000000..da8d1fb
--- /dev/null
+++ b/App/.env.example
@@ -0,0 +1,6 @@
+# GeoGraSim — Environment Configuration
+DB_HOST=localhost
+DB_NAME=geograsim
+DB_USER=root
+DB_PASS=
+DB_PORT=3306
diff --git a/App/.htaccess b/App/.htaccess
new file mode 100644
index 0000000..6adf55c
--- /dev/null
+++ b/App/.htaccess
@@ -0,0 +1,18 @@
+RewriteEngine On
+RewriteBase /geograsim/App/
+
+# Statische Dateien direkt ausliefern
+RewriteRule ^dist/ - [L]
+RewriteRule ^assets/ - [L]
+RewriteRule ^node_modules/ - [L]
+RewriteRule ^src/ - [L]
+
+# Bestehende Dateien/Ordner direkt ausliefern
+RewriteCond %{REQUEST_FILENAME} -f
+RewriteRule . - [L]
+
+RewriteCond %{REQUEST_FILENAME} -d
+RewriteRule . - [L]
+
+# Alles andere -> Front Controller
+RewriteRule ^(.*)$ index.php [QSA,L]
diff --git a/App/dashboard.html b/App/dashboard.html
new file mode 100644
index 0000000..b1cc41b
--- /dev/null
+++ b/App/dashboard.html
@@ -0,0 +1,297 @@
+
+
+
+
+
+ GeoGraSim — Lehrkräfte-Dashboard
+
+
+
+
+
+
+
⚠️ Demo-Mockup — alle Daten sind erfunden, kein Backend angeschlossen
+
+
+
+
+
+
+
+
+
+
+
+
Klasse 1A — Übersicht
+
24 Schüler*innen · Letzte Aktivität: vor 2 Stunden
+
+
+
+
+
+
+
+
+
+
+
Aktive Schüler*innen
+
18 / 24
+
↗ +3 seit gestern
+
+
+
Abgeschlossene Simulationen
+
142
+
↗ 87% Erfolgsquote
+
+
+
Durchschn. Lernzeit
+
23 min
+
pro Simulation
+
+
+
Identifizierte Fehlkonzepte
+
5
+
⚠ Aufmerksamkeit nötig
+
+
+
+
+
+
+
+
+
🔴 Live: Treibhauseffekt-Simulator
+
12 von 24 Schüler*innen bearbeiten gerade die Simulation.
+
+
+
+
Schüler*in
Phase
Fortschritt
Zeit
+
+
+
+
👤 Anna B.
+
Observe
+
+
14:32
+
+
+
👤 Lukas F.
+
Reflect
+
+
18:45
+
+
+
👤 Sara M.
+
Predict
+
+
05:12
+
+
+
👤 Tim H.
+
Pausiert
+
+
09:20
+
+
+
👤 Emma K.
+
Reflect
+
+
21:08
+
+
+
+
+
+
+
+
💡 Erkannte Fehlkonzepte
+
+
+ Ozonloch ≠ Treibhauseffekt
+ 7 Schüler*innen haben in ihrer Vorhersage erwähnt, dass das "Ozonloch" für die Erwärmung verantwortlich sei.
+ → Empfehlung: Im Plenum klarstellen.
+
+
+
+ Lineare statt logarithmische Beziehung
+ 5 Schüler*innen haben "doppelt so viel CO₂ = doppelt so warm" angenommen.
+ → Empfehlung: Klimasensitivität gemeinsam besprechen.
+
+
+
+ Albedo nicht verstanden
+ 3 Schüler*innen haben Albedo nicht verändert. → Optionale Vertiefung anbieten.
+
+
+
🎯 Lernziele-Erreichung (Klasse)
+
+
Treibhauseffekt verstehen83%
+
+
+
CO₂-Temperatur-Zusammenhang71%
+
+
+
Abgrenzung zum Ozonloch54%
+
+
+
+
+
+
+
+
⚙️ Module für Klasse 1A freigeschaltet
+
+
+
🌡️
+
+
Treibhauseffekt-Simulator
+
1. Klasse · 20 min · Schwierigkeit: Standard
+
+
+
+
+
🌋
+
+
Erdbeben-Simulator
+
1. Klasse · 25 min · Schwierigkeit: Standard
+
+
+
+
+
⚡
+
+
Energiemix-Simulator
+
2. Klasse · 25 min · Erst nächstes Jahr
+
+
+
+
+
🏗️
+
+
Raumplanung Gemeinde
+
3. Klasse · 45 min · Erst in 2 Jahren
+
+
+
+
+
+
+
+
+
🗳️ Live-Abstimmung starten
+
Stelle deiner Klasse eine Frage. Das Ergebnis fließt direkt in die laufende Simulation ein.
Der Fluss lebt — er ändert jedes Jahr seinen Lauf! Baue Siedlungen und Felder, aber schütze sie mit Deichen. Begradige den Fluss wenn nötig, aber die Natur rächt sich flussabwärts.