Ein Wirtschaftsspiel darf hart sein. Spieler können schlechte Entscheidungen treffen, Geld verlieren und merken, dass ihr Geschäftsverständnis ein Update braucht. Geht der Fortschritt jedoch durch einen Wechsel des Anmeldesystems verloren, ist das eine ziemlich fragwürdige Lehrmethode.
Alistera Game ist ein Wirtschaftsstrategiespiel im Kontext Dubais. Konzept und Entwicklung werden im Projekt Andrey Merzhalilov zugeschrieben. Mein Fall behandelt die technische Plattform und Entwicklungswerkzeuge: eigenständige Anwendung, Spielermigration, Datenstruktur und kontrollierte Änderungen mit AI.
Hier ist das Team einer fiktiven Firma in Alistera Game geöffnet. Personen, Auslastung und verfügbare Spielaktionen lassen sich ansehen; echte Spielstände werden in diesem Fenster nicht verwendet.
Unternehmensteam
Archivierte Oberfläche · Demodaten
Vor dem Fortschrittstransfer muss die Person feststehen
Die Anwendung nutzt React, TypeScript und Vite sowie Cloudflare Workers und D1 im Backend. Die Registrierung wird per E-Mail und Magic Link bestätigt. Beim Wechsel aus dem alten System lässt sich ein Spieler nicht allein daran erkennen, dass er eine bekannte Adresse eingibt.
Eine Verbindung zur zuvor bestätigten Identität ist nötig. Erst danach wird der erreichte Fortschritt übertragen. Sonst kann eine schöne neue Anmeldung fremde Spielstände verteilen oder alle wieder von vorn beginnen lassen.
Dies ist ein vorbereiteter Stand derselben Firma nach ihrem ersten abgeschlossenen Projekt. Er zeigt die Fortsetzung des Spiels, ohne alle vorherigen Schritte erneut durchlaufen zu müssen.
Unternehmen in Woche zwei
Archivierte Oberfläche · Demodaten
Für Nutzer soll das unspektakulär wirken. Für Entwickler ist es der Transfer eines wertvollen Zustands, bei dem „fast dieselbe Person“ eine völlig unzulässige Definition ist.
Auch Spielregeln brauchen eine Quelle
Das Projekt enthält ein formales Game-Design-Modell und Werkzeuge, die es in verknüpfte Ansichten kompilieren. Index und Atlas helfen beim Untersuchen des Spiels, ohne eine weitere unabhängige Regelkopie zu werden. Balanceprüfungen gelten für ein bestimmtes Modell; ein gelungenes Diagramm beweist allein keine Balance.
Der separate Dienst Dubai Numbers erstellt Datenschnappschüsse nach eigenem Zeitplan. Das Spiel erhält sie über eine Dienstverbindung. Das ist besser, als während eines Zugs ein Sprachmodell eine plausible aktuelle Stadtzahl erfinden zu lassen. Ein Schnappschuss hat ein Datum, Daten haben eine Quelle und Geltungsgrenzen.
Der Autor braucht ein Werkzeug, dem man nicht versehentlich das ganze Spiel übergibt
Für Projektänderungen wird Alistera Author entwickelt: eine private Oberfläche zur AI-Arbeit über MCP. Man kann Quellcode ansehen und Änderungen vorbereiten. Eine Änderung hat eine Ausgangsrevision, einen erwarteten Dateizustand und einen gespeicherten Patch.
Danach werden eine konkrete Version geprüft, Staging vorbereitet und die Abnahme durchgeführt. Eine Werkzeugantwort allein beweist nicht, dass die Änderung Prüfungen bestanden hat. Der Prozess darf nicht jedes erfolgreiche Gespräch automatisch in Production zusammenführen.
Bei einem Spiel ist das besonders interessant: Eine Zeile ist schnell geändert, die Folgen zeigen sich vielleicht erst viele Züge später. Ein Agent kann eine neue Mechanik vorschlagen. Das umgebende System soll klären helfen, welches Spiel daraus genau entsteht.
Mein Anteil ist die technische Plattform und der Prozess prüfbarer Änderungen. Die Urheberschaft des Spiels bleibt bei Andrey. Team und Stand der zweiten Woche zeigen den Spielablauf; allein beweisen sie weder Balance noch die Einsatzreife aller Autorenwerkzeuge.
Verwandte Beiträge: Studio und Zusammenarbeit · Operatives CRM von Alistera.
@nevsky_alexander
Auf Instagram: Dubai jenseits der Postkarte — Familie, Stadt, Entdeckungen und das Leben zwischen den Projekten. Auf Threads: laute Gedanken über Design und KI. Auf YouTube: Videos, die mehr Platz brauchen als eine Story. Folgt mir dort, wo ihr euch wohlfühlt, und lasst uns in Kontakt bleiben