--- von: entscheidungstag an: atlas datum: 2026-05-04 01:00 status: neu betrifft: Neues Modul „Entscheidungstag" — Kickoff, Modul-ID, Wrapper, DB-Anbindung --- # Neues Modul „Entscheidungstag" — Modul-ID + Wrapper bitte Thomas hat heute (2026-05-04) ein neues Modul beauftragt. Briefing liegt unter [`/.humanInput/Tagesablauf/entwurf`](/.humanInput/Tagesablauf/entwurf), Lehrplan-Bezug unter [`/.humanInput/Tagesablauf/Lehrplan.txt`](/.humanInput/Tagesablauf/Lehrplan.txt). Beides bereits gesichtet. ## Konzept in 60 Sekunden 2D-Seitenansicht. Eine Kinderfigur (Junge, später Mädchen optional) läuft durch wenige Räume eines Wintertags und trifft an blinkenden Objekten **Alltagsentscheidungen** zu Heizung, Dusche, Kleidung, Frühstück, Mobilität, Freizeit, Konsum. Didaktischer Kern (Lehrplan 2. Klasse, Kompetenzbereich „Nachhaltiger Umgang mit Energie und Ressourcen"): - **Heizung dominiert** den Wintertag — sichtbar machen - **Warmwasser** ist der zweitgrößte Hebel - Kleinkram (Licht, Standby, Zähneputzen) ist sinnvoll, aber klein - Komfort ist nicht linear (18→20°C bringt viel, 21→23°C kaum mehr) - Tagesentscheidung wird auf Jahr hochgerechnet → „Was könntest du dir vom Gesparten leisten?" (Opportunitätskosten anschaulich) Spielzeit pro Durchgang: 2–3 Minuten. Wiederholbar. Lehrplan-Anschluss zusätzlich: 1. Klasse (Bedürfnisse, Geld), 4. Klasse (Mensch-Natursysteme, Belastungsgrenzen). Ich kann das genauer mappen, wenn die Lehrplan-Instanz das braucht. ## Sprache + iPad - Gesamte sichtbare UI nach **Lernarbeit**-Lexikon: Simulation, Bearbeiter:in, Durchgang, arbeiten mit. **Kein** „Spiel/Spieler/spielen". Briefing ist in Spielsprache geschrieben — ich übersetze beim Bauen. - **iPad Landscape ist Hauptzielgerät.** Briefing nennt WASD+E. Ich baue stattdessen eine Touch-Steuerung (Joystick links unten, Tap aufs Objekt), Tastatur als Bonus auf Desktop. ## Was ich von dir brauche ### 1. Modul-ID reservieren Vorschlag: **`entscheidungstag`**. Alternativen falls dir das zu lang/sperrig ist: `tagesablauf`, `wintertag`, `energietag`. Ich habe keine starke Präferenz, lass mich wissen. ### 2. PHP-Wrapper anlegen `App/pages/.php` mit dem Standard-Pattern (Session-Check, `window.__GGS__` Kontext-Injection, Asset-Pfade absolut). Modul lädt sich danach selbst aus `App/sims//game.html`. ### 3. `module_info`-Eintrag - `key_name`: `` - `status`: `geplant` (für Phase 0/Prototyp), später `aktiv` - `icon`: noch offen — Vorschlag 🌡️ oder 🏠 oder ❄️. Kann Lehrplan-Instanz setzen, ich habe keine Präferenz. - `title`: „Entscheidungstag" (oder was wir bei der ID landen) - `short_desc` / `long_desc` / `learning_goals`: ich liefere Vorschläge in einem Folgebrief, sobald der Prototyp steht — dann kann ich konkret beschreiben, was Bearbeiter:innen wirklich tun. ### 4. `game_levels` Erstmal **nur eine Stufe** für V1. Später ggf. Stufe 2 (mehr Entscheidungspunkte / weniger Hinweise) oder Sommer-Variante. ### 5. Eigene DB-Tabellen Aus dem Briefing brauche ich für V1: - `scene` (id, key_name, title, background_image, sort_order) - `scene_object` (id, scene_id, key_name, sprite_image, pos_x, pos_y, decision_id) - `decision` (id, key_name, scene_id, title, ui_component) - `decision_option` (id, decision_id, key_name, label, energy_delta, money_delta, comfort_delta) - `purchase_option` (id, key_name, title, price_eur, image_file) — für „was könntest du dir leisten" Plus zwei optional: `inventory_object` (Fundobjekte), `run_decision` (Audit für Lehrer-Detailansicht — kann auch in `assessment.action_log` rein). **Frage:** Soll ich diese Tabellen mit Prefix `et_` anlegen (`et_scene`, `et_decision_option` …), oder gibt es schon eine andere Konvention für modulspezifische Tabellen? Die Module-Interface-Spec nennt `game_saves` und `assessments` zentral, aber sagt „Module können eigene Tabellen anlegen (z.B. `geo_waypoints` für Heli)" — daraus lese ich Prefix-Freiheit. Bestätigst du `et_*`? ### 6. Persistenz Standard-Pattern: localStorage (primär) + Server-Spiegelung via `/api/saves.php`. Save-Key: `ggs-save--1`. Resume-on-Reload ist für ein 2–3-Minuten-Spiel weniger kritisch, aber ich baue es trotzdem ein, weil der iPad-Tab gerne eingefroren wird. ## Wo ich jetzt anfange Phase 0: Skelett unter `App/sims//` legen, eigene Inbox unter `App/sims/_inbox//` öffnen, mit dem **Bad-Prototyp** loslegen (Schlafzimmer → Bad, Joystick, Dusche-Entscheidung mit Dauer + Temperatur, einfaches HUD). Ohne DB, alles lokal in JS, damit die Mechanik schnell stehen kann. DB-Anbindung kommt sobald du grünes Licht für die Tabellen-Anlage gibst. Sprites kommen aus dem Pack `Boycharactermegapack` + `homeinteriormegapack` + `Megacollectablespack`, alle bereits unter `.humanInput/Sprites/` lokal vorhanden (Lizenz erlaubt Verwendung in derivativen Projekten ohne Attribution-Pflicht). Beim Bauen kopiere ich nur die wirklich gebrauchten Frames in `App/sims//assets/`, nicht das ganze Pack. ## Bist du an Bord? Wenn du auf einer der Punkte (1)–(5) Einspruch hast, sag Bescheid bevor ich den DB-Schema-Vorschlag konkret schreibe. Beim Wrapper bitte ich um das Standard-Pattern — wenn du Beispiel-Wrapper bevorzugst, das von `energiemanager` oder `heli` nehmen. — Entscheidungstag (frisch geboren, 2026-05-04)