Veresk: как перестать выпускать патч ради одной цифры в балансе

Вы: Снизь health первого босса в staging до 800 и опубликуй.
Агент: читаю текущее значение, меняю на 800, публикую. Готово: health = 800 в production.
Игрок: О, босса понерфили!

Что здесь произошло - разберем ниже, а пока...

Привет! Это пост от команды MyIndie. Мы используем Veresk в своих проектах (это мой pet-проект), включая сам MyIndie, и решили рассказать о нём сообществу: что он решает, кому подходит и с чего начать, если захотите попробовать.

Знакомая ситуация

После плейтеста или первых отзывов почти всегда находится полтора-два десятка мелких правок: здоровье одного босса, сложность третьего уровня, щедрость ежедневной награды. Каждая правка — это одна-две цифры в балансе. Но чтобы они попали к игрокам, нужен новый билд и его распространение — будь то сборка для стенда на джеме, обновление в тестовой группе или релиз в сторе. Для мобильных игр сюда добавляется ещё и очередь на ревью в Apple и Google — от нескольких часов до нескольких дней. Но даже без сторов сам цикл «поправил — пересобрал — раздал» занимает время, которое хочется тратить на игру, а не на доставку одной цифры.

Зачем это нужно нам самим

Для нас это не только игровая история. На MyIndie мы через Veresk храним расширяемый список критериев оценки гейм-джемов — новый критерий перед очередным джемом можно добавить без релиза фронтенда. Там же — справочники платформ и жанров игр: когда появляется новая категория, её не нужно вшивать в код. Такие списки меняются чаще, чем мы выпускаем обновления платформы — то же самое соображение, которое приводит разработчиков игр к remote config для баланса.

Что такое Veresk

Veresk — сервис удалённой конфигурации: настраиваемые значения хранятся в файлах (в статье — JSON), редактируются в браузере и публикуются версией, которая уходит на CDN. Приложение само решает, когда запросить обновлённые файлы — через SDK (Node.js, Unity) или обычный HTTP-запрос.

Снижаем здоровье босса

Давайте попробуем разобрать кейс на более приближенном к нам примере!

Есть игра, в игре есть боссы, а у боссов есть здоровье!

Предполагается, что параметры боссов уже вынесены в конфиг: разработчик заранее подключил загрузку файла bosses.json и использует значения из него в логике боя. Это обязательное условие — без него правки в Veresk ни на что не повлияют, игра просто не будет знать, что их нужно читать.

В этом примере рабочая версия называется production, а staging создана от неё.

Допустим, после плейтеста мы решили уменьшить здоровье первого босса с 1200 до 800:

[
   {
      "id": "firstBoss",
      "name": "Pivo",
      "health": 800
   }
]

Дальше это выглядит так:

1. Меняем health первого босса в bosses.json версии staging.
2. Публикуем staging.
3. Запускаем готовую тестовую сборку, настроенную на staging, и проверяем бой.
4. Сравниваем staging с production и переносим проверенные изменения — копируем именно этот файл из staging в production. Публикация staging не трогает production — это разные версии, и обновлять нужно каждую отдельно.
5. Публикуем production.
6. Игра, настроенная на production, получает новое значение при следующей проверке обновлений: Veresk делает файл доступным на CDN, а момент, когда конкретный клиент его заберёт, определяет сама игра.

Что Veresk добавляет сверх обычного JSON-файла

Если нужно поменять одно значение в одном файле для одного окружения, может хватить обычного JSON на хостинге и ручной выкладки — отдельный сервис ради этого не обязателен. Veresk закрывает то, что начинает болеть, когда файлов, окружений и людей, которые их меняют, становится больше:

• Редактирование в браузере с проверкой синтаксиса — геймдизайнеру не нужен доступ к репозиторию.
• Тестовые версии через наследование — в staging достаточно изменить только тот файл, который действительно меняется: остальные файлы версия продолжает наследовать от production, дублировать их вручную не нужно.
• Перенос проверенных изменений между версиями — можно перенести выбранный файл, предварительно сравнив изменения между версиями.
• Публикация с историей — через git-интеграцию видно, кто и когда опубликовал какую версию для какого потребителя.

Коротко про код

Подключение занимает несколько строк. В Unity:

using VereskSDK;
using VereskSDK.Models;
using Newtonsoft.Json;

VereskAPI.Init(new VereskSetupData
{
    BaseUrl = "<CDN base URL>",
    ProjectId = "<project id>",
    Version = "production",
    Consumer = "game-client",
});
Dictionary<string, string> configs = await VereskAPI.LoadConfigs();
var balance = JsonConvert.DeserializeObject<Balance>(configs["balance"]);

Потребитель определяет набор файлов для клиента — например, игры или сервера. Это не механизм ограничения доступа: опубликованные файлы доступны по ссылке.

Если на устройстве нет сети, Unity SDK использует последние файлы из локального кеша. При самом первом запуске без сети и без кеша приложению нужно самостоятельно обработать ошибку загрузки.

Для Node.js-сервисов пример подключения есть в документации SDK.

Что ещё стоит знать

• Шифрование для чувствительных файлов. Файл можно пометить зашифрованным — на CDN он уйдёт шифротекстом. Но ключ шифрования нельзя передавать на игровой клиент: его можно извлечь из билда, поэтому шифрование имеет смысл только для серверных потребителей.
• Версию можно заблокировать на запись, чтобы то, что уже отдаётся игрокам, никто не поправил по ошибке.
• Текущее состояние конфигов, а также история и авторство изменений, может параллельно синхронизироваться с git-репозиторием.

Где Veresk не лучший вариант

Если вы уже используете Unity Gaming Services или Firebase, сначала оцените их remote config. Если нужны таргетинг по игрокам и встроенные эксперименты — в Veresk их нет.

Нам было важнее не привязываться к конкретной экосистеме и быстро редактировать конфиг без лишней настройки — для этого мы выбрали Veresk.

Если вы работаете с AI-агентами

У Veresk есть MCP-сервер с теми же правами, что у REST API. Тот же пример с боссом можно отдать агенту — Claude Code, Codex, Cursor или Claude Desktop:

Создавать проекты или менять роли агент через MCP не может — только то, что доступно токену, которым он пользуется.

Попробовать на своём проекте

Начните с одного параметра тестовой игры — например, здоровья противника. Вынесите его в конфиг, подключите загрузку и проверьте изменение после публикации.

Пошаговый пример — в быстром старте. Условия использования — на сайте.

Сейчас есть интеграции для Unity и Node.js. Интеграции для других платформ и движков (например, Godot) планируем добавлять по запросам сообщества — и будем рады, если вы поможете нам в развитии экосистемы Veresk.