Problem
Bei einem Mehrspieler-Spiel darf der Client nicht die Quelle der Wahrheit sein. Wird Logik im Client entschieden, ist sie manipulierbar. Zustand muss zentral, konsistent und autoritativ gehalten werden.
Alle Projekte
Aufbau-Strategiespiel
Ogygia
Ein Aufbau- und Strategiespiel in der Tradition von Die Stämme und OGame, angesiedelt in der späten Bronzezeit. Die gesamte Spiellogik liegt in PostgreSQL, der Client schickt nur Absichten und rechnet selbst nichts aus.
Ansatz
Die gesamte Spiellogik liegt in PostgreSQL, geschrieben in PL/pgSQL auf einem nicht exponierten Schema. Der Zustand wird beim Lesen aus der vergangenen Zeit berechnet, dazu ein geplanter Durchlauf für einzelne Ereignisse. Die Welt läuft also weiter, auch wenn niemand die App offen hat.
Wirkung
Spielbar in Version 0.8.2, mit Wirtschaft, asynchronem PvP, Spionage und Bündnissen. Regeln und Zustand liegen an genau einem Ort, der Client muss nicht vertrauenswürdig sein.
Architektur
Die Datenbank entscheidet.
Der Client stellt dar und schickt Absichten. Regeln, Züge und Zustand liegen server-autoritativ in PostgreSQL.
ClientFlutter · zeigt an, sendet Absichten
API · RLSSupabase · Auth, Row Level Security
Kein vertrauenswürdiger Client. Das gesamte Regelwerk läuft als Datenbankfunktionen. Öffentliches Repository mit README und Versionen, der Quellcode bleibt privat.
Gameplay
Palast und Karte
Rohstoffe mit mitlaufendem Countdown, Bau, Forschung und Militär als getrennte Stränge, ein Katalog mit Kosten und Voraussetzungen, dazu die Weltkarte. Derselbe Build läuft auf Tablet und Telefon, das Layout folgt der Breite.
Live-Demo
Das Dorf ausprobieren
Ein spielbarer Ausschnitt des Palast-Bildschirms, direkt im Browser. Rohstoffe ticken, der Katalog listet echte Gebäude, ein Klick auf „Bauen“ reiht eines mit mitlaufendem Countdown ein. Ohne Login, der Fortschritt setzt sich beim Neuladen zurück.
Live-Demo des Dorf-Aufbaus, ohne Anmeldung. Beim ersten Klick werden einige Megabyte geladen, der Fortschritt wird nicht gespeichert.