Adminator
f22c5ebbfe
- 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) <noreply@anthropic.com>
1127 lines
23 KiB
Plaintext
1127 lines
23 KiB
Plaintext
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.
|