An economic game is allowed to be tough. A player can make a bad decision, lose money and discover that their understanding of business needs updating. But losing progress because the sign-in system changed is a rather questionable teaching method.
Alistera Game is a business strategy game in a Dubai setting. The project credits Andrey Merzhalilov with the game’s concept and development. My case here covers the technical platform and development tools: a standalone application, player migration, data architecture and controlled changes with AI.
This view opens a fictional company’s team in Alistera Game. You can examine the people, workload and available game actions; real players’ saves are not used in this window.
Company team
Archived interface · demo data
Before migrating progress, identify the person
The application uses React, TypeScript and Vite, with Cloudflare Workers and D1 on the backend. Registration is verified by email and magic link. When moving from the old system, an existing player cannot be identified merely because they typed a familiar address.
A link to the previously verified identity is needed. Only then is the accumulated progress migrated. Otherwise, an attractive new sign-in can either hand out other people’s saves or restart everyone from scratch.
This is a prepared state of the same company after its first completed project. It lets you see the game scenario continue without repeating all the previous steps.
Company in week two
Archived interface · demo data
For the user, this should feel uneventful. For the developer, it is the transfer of valuable state, where “almost the same person” is an entirely unacceptable definition.
Game rules need a source too
The project has a formal game-design model and tools that compile it into connected views. The index and atlas help examine the game’s structure without becoming another independent copy of its rules. Balance checks apply to a specific model; a good diagram alone does not prove balance.
A separate service, Dubai Numbers, prepares data snapshots on its own schedule. The game receives them through a service connection. That is better than asking a language model during a turn to invent a plausible current figure about the city. A snapshot has a date; the data has a source and limits of applicability.
The author needs a tool that cannot accidentally take over the whole game
Alistera Author is being developed for project changes: a private interface for working with AI through MCP. You can inspect source files and prepare a change. Each edit has a base revision, an expected file state and a saved patch.
A specific version is then checked, staging prepared and acceptance carried out. Merely receiving a tool response is not proof that the change passed checks. This process must not automatically merge every successful conversation into production.
That is particularly interesting in a game: changing one line is easy, while the consequences may appear many turns later. An agent can suggest a new mechanic. The surrounding system should help establish exactly what game that would produce.
My contribution to this case is the technical platform and a process for verifiable changes. Andrey retains authorship of the game. The demo team and second-week state let you examine gameplay; by themselves, they prove neither balance nor the readiness of every authoring tool.
Related stories: The studio and our work together · Alistera operational CRM.
@nevsky_alexander
On Instagram: Dubai beyond the postcard — family, the city, discoveries and life between projects. On Threads: thinking out loud about design and AI. On YouTube: videos that need more room than a story. Follow me wherever you feel at home, and let’s keep in touch