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.