Сущность
Карточная / карточная стратегия с PvP-сессиями, метой и серверным прогрессом.
Mid-core • Android / iOS • закрытое тестирование
Empire of Shadows: стратегия с PvP и серверная часть
Паспорт проекта
Производственный контекст, зона ответственности и источники результатов.
- Клиент
- Red Harbor Interactive
- Период разработки
- январь — май 2025
- Срок
- 5 месяцев
- Исходное состояние
- Однопользовательский боевой прототип без серверная часть, авторизации, матчмейкинга, серверного прогресса и телеметрия.
- Бюджет
- 8,5–10,5 млн ₽
- Переданные материалы
- боевой прототип 0.3, product vision, графические материалы, черновик экономики, пользовательские сценарии и требования к закрытое тестирование.
- Роль RobotGames
- Совместная разработка: совместная игра architecture, серверная часть, система развития между боями, инструменты настройки баланса, мобильный клиент и QA тестовой версии.
- Состав команды
- Продюсер, гейм-дизайнер, технический руководитель, 3 Unity-разработчика, 2 серверный разработчика, дизайнер интерфейсов, 3 QA — 12 специалистов.
- Техническая задача
- За 5 месяцев превратить боевой прототип в закрытого тестирования сборка с PvP, реконнектом и защищённым серверным прогрессом.
- Что реализовано
- подбор игроков, authoritative battle state, reconnect, inventory, ranking, удалённая настройка, аналитика events и baseline anti-cheat.
- Версия до / после
- До: client прототип 0.3 без сети. После: beta 0.9.6 на Android/iOS с PvP с реальными игроками и серверной метой.
- Артефакты
- GDD v2.4, C4 architecture diagram, OpenAPI spec, balance workbook, 684 тестовых сценариев и руководство по сопровождению тестовой версии.
- Метрики
- Match завершения — 96,8%; reconnect success — 93%; server p95 — 148 мс; D7 удержание игроков в тестовой версии — 18,6%.
- Источник метрик
- Grafana, PlayFab телеметрия и Amplitude когорта тестовой версии; 2 140 участников закрытое тестирование.
- Участники проекта
- RobotGames — совместная клиентская и серверная разработка, гейм-дизайн и QA; Red Harbor — IP, издание и Художественное руководство.Ссылка на участники проекта #case-участники проекта
- Подтверждение клиента
- Письмо руководителя продукта и утверждённый список участников проекта для тестовая сборка 0.9.6.
1 / 2
Клиент, сервер и PvP собраны в один процесс разработки
Проект требовал не только клиентских экранов и боя, но и устойчивого слоя матчей: авторизация, прогресс, подбор соперника, реконнект и baseline anti-cheat.
В mid-core проекте риск часто живёт на стыке клиента и серверная часть. Поэтому вертикальные срезы важнее длинной разработки “по слоям”.
Аудитория
Игроки mid-core, которые возвращаются за развитием коллекции, рейтингом и победами над соперником.
Цель
Дойти до закрытое тестирование и проверить удержание на живом PvP-контуре.
Механика и производственный фокус
Страница показывает не только картинку проекта, но и то, как команда раскладывала работу на понятные блоки: геймплей, технический контур, тестирование и запуск.
основной игровой цикл
Сбор отряда, бой на карте, награды, улучшения и следующий матч.
PvP
Сессии, подбор, реконнект и обработка спорных состояний без ломания прогресса.
Баланс
Таблицы юнитов и карт вынесены в управляемый процесс, чтобы быстро менять мету.
QA
Регрессия по сетевым сценариям, устройствам и edge cases перед beta.
1 / 2
Отзыв
Сервер и клиент собрали в одном контуре — не пришлось стыковать отдельных подрядчиков на PvP.
Результат
Часть точных бизнес-показателей в кейсах закрыта NDA, поэтому на странице оставлены проверяемые производственные итоги и агрегированные метрики.
5 месяцев
от MVP до закрытое тестирование
PvP live
матчмейкинг и серверные сессии
D7 цель
удержание тестовой когорты под NDA
Технологии и сборка
Стек подбирался под цель кейса: быстро проверить гипотезу, стабилизировать билд или довести проект до публичного окна запуска.
- Unity
- Node.js
- PostgreSQL
- подбор игроков
- аналитика
- Anti-cheat baseline
- регрессионная проверка QA
FAQ
Почему состояние PvP-боя сделали авторитетным на сервере?
Сервер подтверждает критические действия и итог матча, поэтому клиент не может единолично изменить результат. Такой подход также упрощает диагностику рассинхронов и базовую защиту от манипуляций.
Как работал реконнект после разрыва соединения?
Клиент повторно получал подтверждённое состояние матча и восстанавливал интерфейс из серверного snapshot. Отдельно тестировали повторные подключения, таймауты и ситуацию, когда бой уже завершился.
Зачем серверная часть и клиент разрабатывали одним вертикальным сценарием?
Авторизация, подбор матча, бой, награда и сохранение прогресса проверялись как единая цепочка. Это позволило обнаруживать ошибки контрактов и телеметрия до наполнения игры большим объёмом контента.
Нужен похожий проект?
Опишите жанр, платформу и стадию. Подберём рациональный объём работ, покажем релевантный NDA-формат и оценим разработка-риски.
Использованные услуги
Что вошло в проект
Специалисты