В игре можно обанкротиться. Потерять сохранение — уже проблема разработчика

Экономическая игра имеет право быть суровой. Игрок может принять плохое решение, потерять деньги и обнаружить, что его представление о бизнесе нуждается в обновлении. Но если он потерял результат из-за смены системы входа, это уже довольно сомнительный образовательный приём.

Alistera Game — бизнес-стратегия в дубайском контексте. Авторство концепции и разработки игры в проекте закреплено за Андреем Мержалиловым. Мой кейс здесь — работа над технической платформой и инструментами развития: самостоятельное приложение, перенос игроков, устройство данных и управляемые изменения с AI.

Здесь открыта команда вымышленной компании в Alistera Game. Можно рассмотреть людей, нагрузку и доступные игровые действия; сохранения реальных игроков в этом окне не используются.

Команда компании

Архивный интерфейс · демонстрационные данные

Прежде чем перенести прогресс, нужно узнать человека

Приложение использует React, TypeScript и Vite, серверную часть на Cloudflare Workers и D1. Регистрация подтверждается через email и magic link. При переходе со старой системы существующего игрока нельзя узнать только по тому, что он напечатал знакомый адрес.

Нужна связь с подтверждённой прежней личностью. После неё переносится накопленный результат. Иначе красивый новый вход способен либо раздать чужие сохранения, либо начать всем жизнь заново.

Это подготовленное состояние той же компании после первого завершённого проекта. Оно позволяет увидеть продолжение игрового сценария, не проходя все предыдущие шаги заново.

Компания на второй неделе

Архивный интерфейс · демонстрационные данные

Для пользователя это должно выглядеть спокойно. Для разработчика — как перенос ценного состояния, где «почти тот же человек» является совершенно неприемлемым определением.

Правила игры тоже нуждаются в источнике

В проекте есть формальная модель игрового дизайна и инструменты, которые компилируют её в связанные представления. Индекс и атлас помогают рассматривать устройство игры, не становясь ещё одной независимой копией правил. Проверки баланса относятся к определённой модели; удачная диаграмма сама по себе баланс не доказывает.

Отдельный сервис Dubai Numbers готовит снимки данных по своему расписанию. Игра получает их через служебную связь. Это лучше, чем во время хода просить языковую модель сочинить правдоподобную текущую цифру о городе. Снимок имеет дату, а данные — источник и границы применимости.

Автору нужен инструмент, которому нельзя случайно отдать всю игру

Для изменения проекта развивается Alistera Author — частный интерфейс работы с AI через MCP. Можно рассмотреть исходники и подготовить изменение. У правки есть исходная ревизия, ожидаемое состояние файлов и сохранённый patch.

Дальше проверяется конкретная версия, готовится staging и проводится приёмка. Само получение ответа от инструмента не считается доказательством, что изменение прошло проверки. Автоматически сливать любую удачную беседу в production этот процесс не должен.

Это особенно интересно в игре: одну строку легко поменять, последствия могут проявиться через много ходов. Агент умеет предложить новую механику. Система вокруг него должна помочь понять, какую именно игру мы после этого получим.

Моя часть этого кейса — техническая платформа и процесс проверяемых изменений. Авторство игры остаётся за Андреем. Команда и состояние второй недели в демонстрации позволяют рассмотреть ход игры; сами по себе они не доказывают ни её баланс, ни готовность всех авторских инструментов.

Связанные истории: Студия и совместная работа · Операционная CRM Alistera.