geograsim/.humanInput/stadtsimulation

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<SimulationEffects>;
};
```

---

# 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.