Как модернизировать live-игру, которой 15 лет, не переписывая её с нуля — колонка Playkot

В колонке для App2Top руководитель разработки SuperCity Кирилл Иванов рассказал, как команда Playkot постепенно переводила работающую игру с Flash на HTML5, не переписывая клиент с нуля и не нарушая привычный опыт игроков. Материал опубликован 10 ноября 2026 года.

🎮 Почему модернизация зрелой игры — это сложно

SuperCity была запущена в 2011 году и работает уже 15 лет. Сегодня её клиент построен на TypeScript и PixiJS, а на бэкенде по-прежнему используется PHP. При этом отдельные части системы сохраняют решения эпохи Flash: художники продолжают работать в Adobe Animate, контент должен оставаться совместимым с существующими производственными процессами, а часть браузерной инфраструктуры поддерживает интерфейсы, изначально спроектированные под Flash Player.

В теории модернизация выглядит просто: определить проблемную технологию, заменить её современным стеком, убрать старые зависимости и продолжить разработку. На практике всё сложнее. Для Playkot модернизация никогда не означала замену каждого старого компонента — задача состояла в том, чтобы постепенно отказаться от технологии, которую перестала поддерживать индустрия, сохранив игру, знакомую аудитории.

🔄 Первая миграция: проблема игроков решена, но не разработки

Первый серьёзный шаг по отказу от Flash сделали, когда браузеры начали прекращать его поддержку. Немедленно переписывать весь клиент не стали: вместо этого использовали слой конвертации, который преобразовывал существующий код на ActionScript в JavaScript для рабочей версии игры. Одновременно PixiJS адаптировали так, чтобы он воспроизводил поведение, которого игра ожидала от Flash Player. Для пользователей проблема была решена — SuperCity продолжила работать в браузере без старого плагина.

Но из процесса разработки Flash не исчез: код по-прежнему писали на ActionScript и конвертировали при сборке, что усложняло отладку и поддержку. Со временем стала заметна и другая проблема — Flash превращался в изолированную технологию. Всё меньше инженеров хотели с ним работать, новые инструменты почти не появлялись, экосистема перестала развиваться, а доступная внешняя экспертиза сокращалась. В какой-то момент стало ясно, что реалистичной альтернативы миграции не осталось.

🧩 Успешная live-игра — больше, чем код

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

В утилитарном приложении изменение интерфейса может доставлять неудобства, но пользователь обычно способен освоить новый путь к тому же результату. В игре интерфейс, обратная связь, ритм и накопившееся чувство знакомого продукта сами являются частью опыта. Заменив всё это одновременно, можно заставить давних игроков заново изучать то, что они никогда не просили менять.

Существовала и более традиционная инженерная проблема: за годы работы SuperCity накопила большое количество интеграций и платформенных зависимостей. Пересоздание их всех с нуля, повторная валидация и полный регрессионный прогон потребовали бы значительных инвестиций — команда взяла бы работающую игру, заново построила значительную её часть, а затем ещё и заплатила бы за доказательство, что новая версия работает так же, как старая. Гарантий сопоставимой бизнес-ценности при этом не было. Поэтому выбрали постепенные изменения: измерять эффект каждого шага и не трогать работающие части системы без чёткой причины.

🛠 Сохраняйте контракт, меняйте то, что за ним

Одним из ключевых архитектурных решений стало сохранение интерфейса взаимодействия, на который опиралась игра. Flash Player фактически выполнял роль контракта: через известные вызовы игра могла попросить его отрисовать объект, воспроизвести или изменить звук, выполнить другую операцию. После отказа от Flash этот контракт воссоздали: реализация под ним изменилась, но вызывающему коду не требовалось знать детали нового окружения. Если игра просит показать анимацию, этой части кода не должно быть важно, какая технология её отрисовывает — Flash Player или Pixi.

У подхода есть цена: слой совместимости сохраняет технический долг и со временем требует дополнительной адаптации. Но переписывание всех зависимых систем обошлось бы значительно дороже и создало бы больше рисков.

Следующим крупным шагом стал отказ от ActionScript непосредственно в разработке и переход на TypeScript, завершившийся спустя годы после первой браузерной миграции. Причин две: приоритеты (пока инженеры обновляют технологическую основу, live-игра продолжает выпускать контент, события должны запускаться, серверы — справляться с нагрузкой, а внешние платформы вводят обязательные требования) и масштаб зависимостей. За годы вокруг SuperCity создали утилиты для конвертации ассетов, процессы сборки, внутренние приложения и инструменты для разных специалистов — зависимость от Flash не ограничивалась клиентом. Если бы на TypeScript перевели только клиент, узкое место просто переместилось бы в другую часть производственного процесса.

🎨 Старое не означает неправильное

Арт-пайплайн показывает, почему модернизация — не повод удалить всё, что связано с Flash. За годы существования SuperCity накопилось около 80 ГБ графических ассетов: зданий, декораций, персонажей и другого контента. Художники по-прежнему используют Adobe Animate. С технологической точки зрения инструмент может выглядеть очевидным кандидатом на замену, но с точки зрения производства расчёт другой: новый инструмент должен обеспечивать как минимум прежнее качество и скорость работы. Если качество ассетов снижается — страдает продукт, если сохраняется, но каждый релиз требует больше времени — страдает производство. Альтернативы изучали, однако замену, преимущества которой оправдали бы перестройку всего процесса, пока не нашли. Возраст технологии сам по себе не является достаточной причиной для её замены: компонент становится приоритетом для модернизации, когда начинает создавать существенные ограничения.

Сохранение Adobe Animate не означает, что работа с графикой осталась прежней. Раньше художник зачастую не мог точно увидеть, как ассет будет вести себя в игре, пока разработчики не подготовят рабочую сборку, — это удлиняло цикл обратной связи. Арт нередко создаётся задолго до выхода новой функции, и если проблема конвертации, артефакт рендеринга или другое визуальное отличие обнаруживаются только при подготовке тестовой сборки, исправлять их приходится слишком поздно. Команда создала браузерный инструмент предпросмотра — упрощённую версию игры: художник может загрузить ассет и сразу увидеть, как он выглядит в игровом окружении, а изменение цветов, искажение пикселей и другие проблемы конвертации становятся заметны сразу. Это изменило и распределение ответственности: теперь автор ассета может самостоятельно проверить результат и подготовить его к следующему этапу. Контроль качества сохраняется, но инженерам больше не нужно вручную связывать каждый этап производства.

⚙️ Внутренняя ERP и автоматизация тестирования

Со временем принцип «убрать разработчиков из работы, которая не требует разработчиков» вышел за пределы работы с графикой. За последние несколько лет значительную часть внутренних инструментов перестроили в систему, которую Кирилл Иванов называет внутренней ERP для игры. Исторически инженеры участвовали почти в каждом этапе подготовки релиза: переводы, арт, игровые и промоконфигурации и другие материалы в итоге сходились на разработчиках, прежде чем можно было собрать рабочую версию, — инженерная команда становилась узким местом.

Новые инструменты разделили зоны ответственности. Специалист, отвечающий за игровую конфигурацию, может самостоятельно её опубликовать, а система знает, как собрать итоговый результат. Гейм-дизайнер может изменить баланс или подготовить прототип новой функции и протестировать его, не прося разработчика вручную проводить каждый артефакт через пайплайн. Процессы, которые раньше требовали нескольких дней, координационных встреч и участия инженеров, теперь могут занимать несколько часов, а в некоторых случаях взаимодействие сводится всего к нескольким действиям во внутреннем инструменте. Главный результат — не в том, что все стали техническими специалистами, а наоборот: гейм-дизайнеру больше не нужно разбираться в ветках Git, чтобы протестировать изменение баланса, нарративному специалисту — понимать внутреннее устройство пайплайна, чтобы обновить контент, а художнику — ждать разработчика, чтобы увидеть ассет в игре.

Переход на HTML5 не создал проблему автоматизированного браузерного тестирования с нуля — Flash и раньше был плохо доступен стандартным инструментам. Но после миграции команда лишилась привычных возможностей отладки Flash, а HTML5 canvas принёс свои ограничения: для браузерной автоматизации canvas может выглядеть как чёрный прямоугольник, в нём нет удобных DOM-элементов, соответствующих каждому зданию или компоненту интерфейса. Поэтому визуальные проверки требуют других подходов: есть внутренние инструменты отладки для изучения слоёв рендеринга, часть проверок выполняется с помощью изображений и сравнения скриншотов, однако многие сценарии всё равно сложнее автоматизировать, чем в обычном веб-интерфейсе. Базовые сквозные сценарии уже автоматизированы: можно развернуть сборку, запустить игру, привести её в нужное состояние и проверить, например, размещение здания или сбор ресурса.

Более сложная проблема связана с состоянием live-игры: два пользователя могут видеть разные окна, события, предложения и интерфейсы в зависимости от платформы, прогресса, когорты и времени, поэтому тест, работавший вчера, завтра может столкнуться с другим набором событий или предложений LiveOps. Автоматизация должна учитывать не только место нажатия, но и причину, по которой состояние игрока отличается от ожидаемого, а для некоторых сценариев полное решение этой задачи сегодня обошлось бы дороже ручного тестирования. Автоматизацию оценивают по тому, устраняет ли она реальное ограничение, — сам по себе рост доли автоматизированных процессов целью не является.

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

📈 Главное преимущество — не сам TypeScript

Отказ от Flash изменил язык разработки, но одно из главных улучшений — расширение круга специалистов, способных работать над SuperCity. Найти инженера, который знает Flash, хочет продолжать на нём писать, интересуется игровой индустрией и готов работать над зрелым продуктом, становилось всё сложнее; TypeScript в значительной степени снял это ограничение. Не менее важный результат — сокращение инженерного участия в повседневном производстве: разработчикам больше не нужно вручную сопровождать каждый этап подготовки контента, художники могут самостоятельно проверять больше ассетов, а гейм-дизайнеры — создавать прототипы и настраивать игровые системы. Внутренние инструменты собирают материалы, которые раньше требовали целой цепочки людей и технических операций, а некоторые процессы сократились с нескольких дней до нескольких часов. Для команды это более содержательная метрика модернизации, чем полное отсутствие устаревших компонентов в кодовой базе.

В SuperCity по-прежнему есть старый код, системы, которые хотелось бы улучшить, и технологии, которые со временем могут быть заменены, — при этом пересматриваются даже относительно недавно созданные части игры. В подходе ориентируются на метрики, а не на возраст технологии: если что-то загружается медленно, изучают проблему, после устранения самого существенного узкого места становится заметно следующее — и работа продолжается. Результаты влияют на обе стороны продукта: игроки получают более быструю загрузку, меньше сбоев и более быстрый отклик, а инфраструктуре может требоваться меньше ресурсов для обеспечения того же качества работы. Для долгоживущего продукта модернизация — постоянная работа по сохранению возможности развиваться.

Если бы Кириллу Иванову пришлось консультировать другую команду успешного продукта возрастом 10–15 лет, он начал бы с определения границ, а не с выбора нового движка: чего команда хочет добиться, что она способна изменить с учётом людей, технологий и ресурсов и что нельзя сломать в процессе. Для зрелой live-игры последний вопрос касается и инфраструктуры, и аудитории: технически элегантная миграция может оказаться провальной, если разрушит привычный игрокам опыт. Он также скептически относится к смене технологий ради подражания — переход другой студии на Unity, Cocos или иной популярный стек сам по себе ничего не говорит о потребностях SuperCity, у каждого зрелого продукта свои ограничения. Совет: сначала понять, чего вы хотите, что вы можете сделать и что вы не можете позволить себе сломать, а всё остальное пропускать через здравый смысл.

В итоге команда постепенно устраняла ограничения вокруг существующей игры: Flash исчез из повседневной разработки клиента, слои совместимости защищали работающие системы, пока менялась их реализация, а внутренние инструменты позволили профильным специалистам самостоятельно выполнять задачи, ранее зависевшие от инженеров. Автоматизацию внедряли там, где она давала ощутимый эффект, и сохраняли ручное тестирование там, где оно оставалось экономически оправданным. Такой подход позволяет менять технологии под работающей игрой, не заставляя ни аудиторию, ни команду начинать всё заново.

🍓 Sweet Berries — это самый выгодный способ пополнить счёт в мобильных играх. Быстрый донат с самой низкой комиссией в РФ. Гарантия сохранности вашего аккаунта.