nda case — visuals are illustrative, the live ui is hidden
объём работы
Мы начали с пяти моментов, в которых соревновательный матч теряет ценность: сезонный сброс обрывает непрерывность прогресса, переходы в лобби лишают игрока контекста, неявка или выход одного участника впустую тратят время остальных, сбой сервера ставит под угрозу результат, а непрозрачные правила честной игры разрушают доверие. BAKS должна сохранять время, прогресс и доверие игрока на всём пути, поэтому единицей продукта стало не найденное лобби, а матч, завершившийся валидным результатом.
BAKS объединяет клиент игрока, группу и лобби, подбор матчей, рейтинг, систему честной игры, оркестрацию игровых серверов и результаты матча в единый жизненный цикл. Рейтинг, матчмейкинг, доверие и серверный цикл реализованы в backend-контрактах и коде; раздел «Играть» существует как frontend-прототип с управлением состояниями. Сначала мы проверили гипотезы на синтетических сценариях, тестах переходов и backend-протоколов; следующий уровень проверки — реальный стенд CS2 и закрытая альфа.
Я отвечал за продуктовое направление, дорожную карту и приоритеты, управлял командой и процессом реализации, вёл UX/UI, дизайн-систему и анимацию, а ключевые frontend-интерфейсы собирал самостоятельно. Backend и игровые серверы разрабатывались вместе с командой.
продуктовые решения
рейтинг без сезонного сброса
Новый сезон не стирает оценку навыка. После периода бездействия неопределённость растёт, а отображаемый рейтинг может снизиться, чтобы следующие матчи быстрее откалибровали уровень игрока. Внешний ранг переносится по относительной позиции с указанием источника. Единый движок заранее рассчитывает изменение за победу и поражение; итог может включать ограниченный положительный бонус за личную игру.
лобби как договор о матче
Группа, готовность, поиск, разминка, вето, выбор стороны, подключение и результаты остаются в одной сцене, не теряя контекста. Дополнительные сигналы меняют исходное распределение по командам только при явном улучшении. При снижении ликвидности ограничения постепенно ослабляются, чтобы стремление к точности не превращалось в бесконечную очередь.
восстановление вместо отмены
До назначения матча Flash Fill приглашает одиночного игрока в остановившийся поиск. После назначения Flash Save ищет замену на ту же роль и тот же сервер. В пределах ограниченной защиты поражение не снимает рейтинг, а победа засчитывается полностью. Если замену найти не удаётся, при неявке группы возвращаются в поиск, а уже начавшийся матч продолжается в неполном составе. Протокол реализован; проверка на реальном стенде CS2 ещё не проводилась.
надёжность сервера как часть продукта
Auto-region выбирает доступный регион со свободной ёмкостью и учитывает пинг, переданный клиентом. Повторное назначение не может создать второй сервер. При постоянном хранилище результат сохраняется до отправки, а после перезапуска оркестратор повторно подключается к сохранившемуся матчу или явно отменяет потерянный. Надёжность становится частью пути игрока, а не невидимой инфраструктурой.
доверие без чёрного ящика
Trust API показывает только общий статус, безопасные факторы и способы его улучшить, скрывая логику детекторов и личности отправителей жалоб. Подозрение на смурфинг не приводит к наказанию: оно может ускорить калибровку вверх и повлиять на баланс. Если сигнал становится достаточно сильным или повторяется, система отправляет случай на ручную проверку, а не применяет автоматическую блокировку. После постоянного бана читера чистым игрокам отдельной корректировкой возвращается итоговая потеря рейтинга за недавно аннулированные матчи.
этапы работы
до — матч был разделён между системами
Ключевые backend-модули уже существовали, но рейтинг, лобби, сервер и результат не складывались для игрока в единый путь, а frontend отставал от платформенной основы.
один завершённый матч как главная цель
После исследования категории мы сформулировали продуктовый тезис: отличие создаёт непрерывность матча, а не количество функций. Я пересобрал дорожную карту и приоритеты команды вокруг первого завершённого матча.
контракты и критические состояния
Единый контракт жизненного цикла связал рейтинг, лобби, замену и сервер, а также синхронизировал дизайн, frontend, backend и игровые серверы вокруг неполных данных, неявок, выходов игроков и недоставленных результатов.
команда, реализация и тесты
Я вёл работу над опытом игрока и самостоятельно собрал оболочку продукта, главный экран, раздел друзей и типизированную машину состояний раздела «Играть». Общие компоненты, токены и правила анимации стали единым языком реализации, а критические переходы проверялись автоматическими тестами и синтетическими сценариями.
следующий этап — проверка в реальной среде
Далее — интеграция с реальной авторизацией и realtime-данными, проверка связки CS2 и MatchZy и закрытая альфа. Она позволит измерить завершение первого матча, долю игр, восстановленных после выхода участника, успешность подключения и регистрации результата, а также начало второго матча.
