~/work/infinity-talesLive
Infinity Tales
KI-Rollenspiel mit verzweigten Handlungssträngen, Charakter-Progression und KI-generierter Szenenkunst. Komplett neu geschrieben von Firebase + React zu Go + PostgreSQL + Svelte für volle Datenkontrolle. Multi-Provider-LLM-Integration via OpenRouter.
Was es macht
Ursprünglich als React-PWA auf Firebase gebaut. Vollständiger Rewrite auf Go-Backend + PostgreSQL für vollständige Datenkontrolle und Kontrolle über die LLM-Vertrauensgrenze. Svelte-SSR-Frontend. Multi-Provider-LLM-Integration via OpenRouter mit Prompt-Engineering zur konsistenten Verwaltung von Inventar, Quest-Status und Charakterentwicklung über unbegrenzte Handlungsstränge. KI-Bildgenerierung pro Szene, Charakter-Customization, XP-Progression, Mehrsprachigkeit in 5 Sprachen.
Problem
Eine verzweigte Geschichte muss Quests, Inventar, Charaktere und frühere Entscheidungen über Modellaufrufe hinweg konsistent halten.
Die ursprüngliche Firebase- und React-Implementierung begrenzte die Kontrolle über Persistenz und Modellgrenze.
Rahmenbedingungen
- Modellausgaben sind nicht deterministisch, während der Spielzustand dauerhaft und abfragbar bleiben muss.
- Dasselbe Narrativsystem bedient fünf Sprachen und mehrere Modelle über OpenRouter.
Wie es gebaut ist
- Spieler interagieren mit einem Svelte-SSR-Frontend.
- Das Frontend spricht mit einer Go-API, die Quests, Inventar und Story-State verfolgt.
- PostgreSQL persistiert Spiel- und Charakterdaten.
- Die API verzweigt zu LLM-Providern über OpenRouter und zur Bildgenerierung für Szenen-Art.
Engineering-Entscheidungen
Neuentwicklung mit Go und PostgreSQL
API, Persistenzmodell und LLM-Vertrauensgrenze selbst kontrollieren.
Trade-off Die vollständige Neuentwicklung verzögerte Produktarbeit und ersetzte verwaltete Firebase-Dienste.
Zustand außerhalb des Modellkontexts halten
Quests, Inventar und Charakterfortschritt brauchen dauerhaften Anwendungszustand.
Trade-off Das Backend muss strukturierten Zustand mit generativen Ausgaben abgleichen.
OpenRouter als Provider-Grenze
Die Story-Engine funktioniert modellübergreifend ohne providerspezifische Frontend-Logik.
Trade-off Die Anwendung hängt von einer externen Routing-API ab.
Nachweise
- Sprachen
- 5
- Eigenes Backend
- Go · PostgreSQL
- Modellgrenze
- OpenRouter
Laut aktuellem Produktinhalt unterstützt
Ersetzt Firebase-Persistenz
Multi-Provider-Integration
Highlights
- Full-Stack-Rewrite Migration von Firebase + React zu Go + PostgreSQL + Svelte für volle Datenkontrolle, Server-Side-Rendering und Kontrolle über die LLM-Integrationsschicht.
- KI-gestützte Game-Engine Multi-Provider-LLM-Integration via OpenRouter verfolgt Inventar, Quests und Charakterentwicklung über unbegrenzte Handlungsstränge mit KI-generierter Kunst pro Szene.