"Projekt Chimera" ist ein hybrides Krimi-Dinner-Erlebnis, das physische soziale Interaktion mit einer digitalen App-Komponente verbindet. Das Alleinstellungsmerkmal ist der Einsatz einer zweistufigen KI-Architektur, die nicht nur einzigartige narrative Szenarien generiert, sondern diese auch proaktiv auf logische Konsistenz validiert und korrigiert.
+Die Architektur basiert auf einer klaren Trennung: Supabase dient als dedizierter Service für die Benutzerauthentifizierung, während alle Spieldaten (Szenarien, Spieler, Spielstände) in einer separaten, dedizierten PostgreSQL-Datenbank gehostet werden. Ein zentrales FastAPI-Backend fungiert als sichere Schnittstelle zwischen den Clients und beiden Diensten.
+Die Generierung jedes Spiels folgt einem strengen, zweistufigen Prozess, um die narrative Qualität und logische Integrität zu gewährleisten.
+ +In dieser Phase agiert die KI als kreativer Autor. Sie erhält einen umfassenden Prompt, der die gewünschten Rahmenbedingungen (Szenario-Beschreibung, Rundenanzahl) vorgibt. Die genaue Spieleranzahl wird dynamisch aus der Lobby übernommen, kurz bevor die KI die Generierung startet.
+Der rohe Output aus Schritt 1 wird nun an eine zweite KI-Instanz übergeben, die als akribischer Logik-Lektor agiert. Die KI wird instruiert, das gesamte Szenario anhand einer Checkliste von potenziellen Fehlern zu überprüfen:
+Die KI korrigiert gefundene Fehler minimalinvasiv, um die kreative Essenz nicht zu verändern, und gibt ein logisch wasserdichtes Spielszenario aus.
+Die Architektur ist auf maximale Kontrolle und Skalierbarkeit ausgelegt. Die React Native-Clients kommunizieren ausschließlich mit dem FastAPI-Backend. Supabase wird als reiner Authentifizierungs-Provider genutzt. Echtzeit-Updates werden über eine WebSocket-Verbindung vom FastAPI-Server an die Clients gepusht.
+ ++ graph TD + subgraph "Spieler-Geräte" + P1["React Native Apps"] + end + + subgraph "Authentifizierung" + Auth["Supabase Auth"] + end + + subgraph "Sicheres Backend" + FastAPI["FastAPI Server+
REST & WebSockets"] + end + + subgraph "Spieldaten-Bank" + PG_DB["PostgreSQL DB"] + end + + subgraph "Externe Dienste" + OAI["OpenAI API"] + end + + %% Verbindungen + P1 -- "1. Login" --> Auth + P1 -- "2. API Calls (mit Token)" --> FastAPI + + FastAPI -- "3. KI Call" --> OAI + FastAPI -- "4. DB-Zugriff" --> PG_DB + + FastAPI -- "5. WebSocket Updates" --> P1 +
Die UI-Konzepte werden als klare, moderne Wireframes visualisiert, um den gesamten App-Flow von der Erstellung bis zum Spiel darzustellen.
+Noch kein Konto? Jetzt registrieren
+Bereits ein Konto? Zum Login
+Tech-Konferenz 2035
+Status: Aktiv (Runde 2/3)
+ +Villa Vendetta
+Status: Lobby (0 Spieler)
+ +Die Spieleranzahl ist flexibel (mind. 3 Spieler) und wird in der Lobby durch die Anzahl der beigetretenen Spieler bestimmt.
+Spiel-Lobby
+Teile diesen Code mit deinen Mitspielern:
+Deine Rolle
+Du hast vor einem Monat bei einem nicht genehmigten Experiment die Stromversorgung der Station überlastet, was zu einem kritischen Ausfall führte. Nur das Opfer wusste davon.
+Deine Rolle
+HINWEIS #3
+Ein zerrissener Brief wurde gefunden. Die Worte "Schulden" und "letzte Warnung" sind lesbar.
+HINWEIS #1
+Das Opfer wurde mit einem schweren Gegenstand erschlagen.
+Deine Rolle
+Evelyn Reed (CEO)
+Die ehrgeizige CEO des Konkurrenzunternehmens. Es ist bekannt, dass sie und das Opfer eine erbitterte Rivalität pflegten.
+Ivan Petrov (Sicherheitschef)
+Der loyale, aber jähzornige Sicherheitschef. Er war für den Schutz des Opfers verantwortlich.
+Deine Rolle
+16:30 - 16:45 Uhr
+Streitgespräch mit dem Opfer im Labor.
+16:45 - 17:00 Uhr
+Alleine im Büro, E-Mails beantwortet.
+17:00 - 17:20 Uhr
+Gespräch mit Ivan Petrov in der Cafeteria. (Dein Alibi)
+ca. 17:30 Uhr (TODESZEITPUNKT)
+Ivan Petrov!
+Sein Motiv war Rache, da das Opfer ihn erpresst hat. Die Mordwaffe war ein schwerer Schraubenschlüssel aus dem Werkzeugraum.
+Spoiler-freie Steuerung (im Spiel)
+Achtung: Generiert nur die Hinweise für die AKTUELLE Runde neu. Nur nutzen, wenn Hinweise fehlerhaft wirken.
+Beendet das Spiel für alle und startet die Lobby neu.
+Das Backend wird zur zentralen API für die gesamte Spiellogik. Alle Endpunkte erfordern ein gültiges Supabase JWT.
+POST /game/create: Erstellt ein neues Spiel, ruft OpenAI auf, speichert in PG_DB.POST /game/{game_code}/join: Fügt einen Spieler zu einem Spiel hinzu.GET /game/{game_code}/state: Ruft den aktuellen Zustand eines Spiels ab.POST /game/{game_code}/vote: Gibt eine Stimme für einen Charakter ab.GET /game/{game_code}/character: Ruft die Charakterdetails für den authentifizierten Spieler ab./ws/{game_code}: WebSocket-Endpunkt für Echtzeit-Updates./ws/... Endpunkt des Backends herzustellen und auf Updates zu lauschen.Die dedizierte PostgreSQL-Datenbank enthält die gesamte Spiellogik, während Supabase ausschließlich für die Identitätsverwaltung zuständig ist.
+ +| Spalte | +Datentyp | +Beschreibung | +
|---|---|---|
| id | uuid | Eindeutige ID für ein Spiel. |
| created_at | timestamp | Zeitstempel der Erstellung. |
| host_id | uuid | Referenz auf die User-ID des Hosts aus Supabase. |
| game_code | varchar | Kurzer Code zum Beitreten (z.B. "GHY-781"). Indiziert! |
| status | varchar | Aktueller Status (setup, lobby, active, finished). |
| game_data | jsonb | Das komplette KI-generierte Szenario. |
| Spalte | +Datentyp | +Beschreibung | +
|---|---|---|
| id | uuid | Eindeutiger Eintrag für einen Spieler in einem Spiel. |
| game_id | uuid | Verweist auf das zugehörige Spiel in `games`. |
| player_id | uuid | Referenz auf die User-ID aus Supabase (kann `NULL` sein). |
| player_name | varchar | Der im Spiel angezeigte Name des Spielers. |
| character_id | varchar | Verknüpft den Spieler mit seiner Rolle im `game_data`-JSON. |
Diese einzelne Spalte ist das narrative Herzstück jedes Spiels. Hier wird das gesamte, von der KI generierte und validierte JSON-Objekt gespeichert.
+Du bist ein preisgekrönter Autor von Kriminalromanen. Deine Aufgabe ist es, ein vollständiges, komplexes und fesselndes Krimi-Dinner-Szenario zu erstellen. Halte dich exakt an die vorgegebene JSON-Struktur.
+Erstelle ein Krimi-Dinner-Szenario für 5 Spieler über 3 Runden. Das Thema lautet: "Ein Mord auf einer Tech-Konferenz im Jahr 2035". Erstelle für jeden Charakter einen lückenlosen Zeitstrahl mit Zeitblöcken (z.B. "16:30-16:45") und verteile die Hinweise logisch auf die Runden. Generiere das vollständige Spiel-JSON und stelle sicher, dass der Mord logisch aufgeklärt werden kann.
+Du bist ein extrem detailorientierter und logisch denkender Lektor. Deine Aufgabe ist es, das dir vorgelegte Krimi-Szenario auf Widersprüche und Logikfehler zu überprüfen und minimalinvasiv zu korrigieren.
+Hier ist ein JSON-Objekt. Bitte agiere als Logik-Lektor. Überprüfe es auf: Zeitlinien-Konflikte (sind die Zeitstrahlen aller Charaktere widerspruchsfrei?), Motiv-Schwäche, Unlösbarkeit, Inkonsistente Charakter-Aktionen. Gib das vollständige, korrigierte JSON zurück.
[Hier wird das gesamte JSON aus Schritt 1 eingefügt]
Der Lebenszyklus eines Spiels ist in mehrere Phasen unterteilt, wobei jede Runde einem definierten Zeitfenster entspricht, um den Zeitstrahl zu strukturieren.
+status: setup)
+ Der Host kann ein Spiel generieren, lange bevor es stattfindet. In dieser Phase erhält er den Einladungscode und eine spoiler-freie Übersicht über Thema und Charakter-Namen zur Vorbereitung.
+status: lobby)
+ Am Tag des Spiels öffnet der Host die Lobby. Die Spieler treten mit dem Code bei. Der Host kann Spieler hinzufügen/entfernen und hat die Option, das Szenario neu zu generieren, bevor er das Spiel startet.
+Nach dem Spielstart weist das Backend jedem Spieler eine Rolle zu und sendet die geheimen Informationen an das jeweilige Gerät.
+status: active)
+ Das Spiel verläuft in Runden, die jeweils einem Zeitfenster zugeordnet sind (z.B. Runde 1: 16-18 Uhr). In jeder Runde gibt das System neue Hinweise frei. Spieler können ihren persönlichen Zeitstrahl und alle bisherigen Hinweise einsehen.
+status: finished)
+ Nach der letzten Runde wird die Abstimmung freigeschaltet. Danach folgt die Auflösung, bei der der Mörder und alle Geheimnisse enthüllt werden.
+Die App wird kein kostenloses Basis-Modell anbieten. Die Monetarisierung erfolgt direkt über die Nutzung der Spiunktion.
+Nutzer zahlen einen monatlichen oder jährlichen Beitrag und erhalten dafür ein festes Kontingent an Spielen (z.B. die Möglichkeit, 2 Spiele pro Woche zu generieren und zu spielen).
+Alternativ zum Abo können Nutzer einzelne Spiele per Einmalkauf freischalten. Dies bietet maximale Flexibilität für Gelegenheitsspieler.
+/game/create Endpunkt verhindert Missbrauch (z.B. nur ein Spiel alle 5 Minuten pro Nutzer).Aufgrund der Verarbeitung von E-Mail-Adressen für die Authentifizierung sind folgende Punkte für den Launch zwingend erforderlich:
++ "Projekt Chimera" ist ein hybrides Krimi-Dinner-Erlebnis, das + physische soziale Interaktion mit einer digitalen App-Komponente + verbindet. Das Alleinstellungsmerkmal ist der Einsatz einer + zweistufigen KI-Architektur, die nicht nur einzigartige narrative + Szenarien generiert, sondern diese auch proaktiv auf logische + Konsistenz validiert und korrigiert. +
++ Die Architektur basiert auf einer klaren Trennung:{" "} + Supabase dient als dedizierter Service für die + Benutzerauthentifizierung, während alle Spieldaten (Szenarien, + Spieler, Spielstände) in einer{" "} + separaten, dedizierten PostgreSQL-Datenbank{" "} + gehostet werden. Ein zentrales FastAPI-Backend{" "} + fungiert als sichere Schnittstelle zwischen den Clients und + beiden Diensten. +
++ Die Generierung jedes Spiels folgt einem strengen, zweistufigen + Prozess, um die narrative Qualität und logische Integrität zu + gewährleisten. +
++ Die Architektur ist auf maximale Kontrolle und Skalierbarkeit ausgelegt. Die React Native-Clients kommunizieren ausschließlich mit dem FastAPI-Backend. Echtzeit-Updates werden über eine WebSocket-Verbindung gepusht. +
+
+ {`
+ graph TD
+ subgraph "Spieler-Geräte"
+ P1["React Native Apps"]
+ end
+ subgraph "Authentifizierung"
+ Auth["Supabase Auth"]
+ end
+ subgraph "Sicheres Backend"
+ FastAPI["FastAPI Server
REST & WebSockets"]
+ end
+ subgraph "Spieldaten-Bank"
+ PG_DB["PostgreSQL DB"]
+ end
+ subgraph "Externe Dienste"
+ OAI["OpenAI API"]
+ end
+ P1 -- "1. Login" --> Auth
+ P1 -- "2. API Calls (mit Token)" --> FastAPI
+ FastAPI -- "3. KI Call" --> OAI
+ FastAPI -- "4. DB-Zugriff" --> PG_DB
+ FastAPI -- "5. WebSocket Updates" --> P1
+ `}
+
+ Die UI-Konzepte werden als klare, moderne Wireframes visualisiert, um den gesamten App-Flow darzustellen.
+POST /game/createPOST /game/{'{game_code}'}/joinGET /game/{'{game_code}'}/statePOST /game/{'{game_code}'}/voteGET /game/{'{game_code}'}/character/ws/{'{game_code}'}Die dedizierte PostgreSQL-Datenbank enthält die gesamte Spiellogik.
+| Spalte | Datentyp | Beschreibung |
|---|---|---|
| id | uuid | Eindeutige ID für ein Spiel. |
| host_id | uuid | Referenz auf die User-ID des Hosts. |
| game_code | varchar | Kurzer Code zum Beitreten. |
| status | varchar | setup, lobby, active, finished. |
| game_data | jsonb | Das komplette KI-generierte Szenario. |
| Spalte | Datentyp | Beschreibung |
|---|---|---|
| id | uuid | Eindeutiger Eintrag für einen Spieler. |
| game_id | uuid | Verweist auf das zugehörige Spiel. |
| player_id | uuid | Referenz auf die User-ID aus Supabase. |
| player_name | varchar | Der im Spiel angezeigte Name. |
| character_id | varchar | Verknüpft den Spieler mit seiner Rolle. |
Du bist ein preisgekrönter Autor von Kriminalromanen...
Erstelle ein Krimi-Dinner-Szenario für 5 Spieler...
Du bist ein extrem detailorientierter und logisch denkender Lektor...
Hier ist ein JSON-Objekt. Bitte agiere als Logik-Lektor...
Nutzer zahlen einen monatlichen oder jährlichen Beitrag für ein festes Kontingent an Spielen.
+Alternativ können Nutzer einzelne Spiele per Einmalkauf freischalten.
+