Neva. От компьютерного клуба до киберспортивной платформы

Neva начиналась с практической задачи: проводить собственные киберспортивные турниры и не собирать процесс вручную из таблиц, чатов и отдельных игровых сервисов.

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

Так внутренняя система компьютерного клуба постепенно превратилась в самостоятельную платформу для игроков, команд и организаторов.

Мы подключились не к чистому листу. У Neva уже были кодовая база, дизайн и часть функциональности.

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

Поэтому начали с технического и продуктового погружения:

• провели код-ревью существующей системы;
• разобрали взаимосвязи между разделами;
• определили участки для рефакторинга;
• помогли уточнить пользовательские сценарии;
• проверяли дизайн-решения с точки зрения логики и реализации;
• после этого приступили к разработке новых модулей.

Визуальный дизайн платформы разрабатывала команда клиента. Круто выступали в роли технических и продуктовых супервайзеров.

Мы помогали проверять:

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

Так дизайн оставался работой клиентской команды, а мы помогали сделать его логичным, реализуемым и связанным с настоящими правилами киберспорта.

Legacy-проект нельзя безопасно развивать, пока команда не понимает, какие части системы зависят друг от друга.

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

Ключевой принцип — не переписывать всё ради переписывания, а постепенно отделять рабочие части системы от тех, которые мешали дальнейшей разработке.

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

Поэтому модули нельзя было проектировать и разрабатывать изолированно.

Страница турнира объединяет информацию, которая нужна участникам на разных этапах:

• параметры и статус турнира;
• организатора, регион и формат;
• регистрацию и подтверждение участия;
• список команд;
• турнирную сетку;
• расписание матчей;
• регламент;
• общий чат.

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

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

Мы разработали отображение пар, этапов и результатов так, чтобы пользователь мог быстро понять:

• кто с кем играет;
• какой раунд идёт сейчас;
• кто уже прошёл дальше;
• какой матч завершён;
• где ещё не определены участники;
• когда состоится следующая игра.

Сетка связана со страницами матчей и расписанием: результат одной встречи влияет на последующие пары и дальнейшее движение турнира.

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

Мы разработали календарную систему с дневным и недельным представлением, временными слотами и разными ролями пользователей.

Сценарий переноса включает:

1. Выбор матча.
2. Предложение новой даты и времени.
3. Отправку заявки другой стороне.
4. Подтверждение или отклонение капитаном либо организатором.
5. Обновление расписания.
6. Системные уведомления для участников.

У разных дисциплин отличаются правила, данные и подготовка к матчу. Поэтому одну универсальную страницу нельзя было просто наполнить разными картинками.

CS2

В матчах учитываются карты, стороны T и CT, формат серии, процесс выбора и исключения карт, результаты раундов, статистика и демо-записи.

Dota 2

Для Dota 2 важны стороны Dire и Radiant, очередность выбора, герои, стадии pick/ban и собственный набор статистических показателей.

При этом обе дисциплины должны оставаться частями одной платформы с общей логикой статусов, команд и турнирных переходов.

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

В макетах предусмотрены:

• составы обеих команд;
• капитаны и роли участников;
• таймеры и обратный отсчёт;
• coin flip;
• выбор первой или второй очереди;
• T/CT для CS2;
• Dire/Radiant для Dota 2;
• выбор и исключение карт;
• название и пароль сервера;
• состояния загрузки и ожидания.

Это один из наиболее насыщенных логикой разделов: действия одной команды определяют доступные действия другой.

Мы разработали разделы, в которых пользователь существует и за пределами конкретного матча.

Профиль игрока

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

Страница команды

Командный раздел объединяет состав, игроков, тренеров, менеджеров, спонсоров, историю, активные и прошедшие турниры, а также статистику по дисциплинам.

Общение

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