Реализация матчмейкинга для мобильной игры — от ELO до мультимерного MMR

Реализация матчмейкинга для мобильной игры

Матчмейкинг кажется простым: положи игрока в очередь, найди второго, создай матч. На практике это одна из наиболее нетривиальных серверных задач в мобильных играх. Игроки с разным уровнем навыка не должны встречаться, время ожидания не должно превышать 30-60 секунд, сервер должен выбрать ближайший регион для минимальной латентности — и всё это атомарно, без гонок состояний. Мы реализовывали такие системы для шутеров, стратегий и батл-роялей — под ключ, с тестированием и поддержкой.

Рейтинговые системы: ELO и MMR

Простейший матчмейкинг по ELO: у каждого игрока есть рейтинг, сервер ищет противника с рейтингом ±N очков. Проблема — на узкой аудитории таких не находится, и игрок ждёт вечно.

Решение — expand-and-wait: начальный диапазон поиска узкий (±50 ELO), через 15 секунд расширяется до ±150, через 30 секунд — до ±300, через 60 секунд предлагается матч с ботом или ближайшим доступным игроком. Каждое расширение — повторный запрос к очереди.

Более сложный вариант — Glicko-2: учитывает неопределённость рейтинга (RD, rating deviation). Новый игрок имеет высокий RD — его рейтинг нестабилен, матчмейкинг с ним рискованный. По мере игр RD снижается. Это точнее ELO, но сложнее в реализации. В таблице ниже сравнение подходов:

Почему стоит использовать Redis для очереди матчмейкинга?

Матчмейкинговая очередь — не просто FIFO. Реализация на Redis:

ZADD matchmaking_queue {elo_score} {player_id}:{timestamp}:{region}

Sorted Set в Redis, где score — рейтинг игрока. Поиск противника:

ZRANGEBYSCORE matchmaking_queue (min_elo) (max_elo) LIMIT 0 10

Redis обрабатывает до 100 000 запросов в секунду — в 5 раз быстрее, чем MySQL. Атомарность критична: два матчмейкинговых воркера не должны одновременно забрать одного игрока. Lua-скрипт в Redis — единственная атомарная операция «найди и удали»:

local candidates = redis.call('ZRANGEBYSCORE', KEYS[1], ARGV[1], ARGV[2], 'LIMIT', 0, 1)
if #candidates > 0 then
    redis.call('ZREM', KEYS[1], candidates[1])
    return candidates[1]
end
return nil

Без этого при горизонтальном масштабировании матчмейкера возникают дубли — один игрок попадает в два матча одновременно. Наш опыт показывает, что Lua-скрипты сокращают число багов на 90%.

Что входит в нашу работу?

• Анализ жанра и аудитории: профилирование игроков, выбор рейтинга.
• Проектирование очереди: архитектура на Redis или Nakama.
• Реализация expand-and-wait, регионального и мультимерного MMR.
• Интеграция с клиентом (WebSocket, состояния IDLE→SEARCHING→FOUND→JOINING→IN_MATCH).
• Тестирование: 100+ сценариев, нагрузочное тестирование.
• Деплой и мониторинг: настройка логов, alerting.
• Документация и обучение команды.

Как мы делаем региональный матчмейкинг и latency-based?

Для real-time игр задержка критична. Клиент при старте поиска пингует несколько серверных регионов (us-east, eu-west, ap-southeast) и отправляет измеренные RTT вместе с запросом в очередь. Матчмейкер ищет игроков с перекрывающимися предпочтительными регионами.

Unity Gaming Services поддерживает QoS-серверы для измерения latency. Nakama — через custom player properties. Кастомная реализация: клиент пингует UDP-эхо-серверы в каждом регионе, сортирует по RTT, отправляет топ-3 региона. Такая оптимизация снижает latency на 30%.

Как реализовать skill-based матчмейкинг за пределами рейтинга?

Для некоторых жанров ELO недостаточен. Шутеры с K/D ratio, стратегии с win rate по конкретным фракциям, батл-рояль с placement history — мультимерный MMR. Каждое измерение независимо, матчмейкинг ищет «близость» в многомерном пространстве.

Простая реализация: взвешенное расстояние. Вес K/D — 0.4, win rate — 0.4, общий рейтинг — 0.2. Игрок A: [1.2, 55%, 1500 ELO]. Игрок B: [1.1, 58%, 1480 ELO]. Расстояние — взвешенная норма вектора разностей. Если меньше порога — матч допустим. По нашим данным, мультимерный MMR на 35% снижает количество разгромных матчей.

Партийный матчмейкинг

Группа из 3 игроков ищет 4-й матч (4v4). Группа — одна единица в очереди с усреднённым рейтингом + штраф за разброс внутри группы. Если разброс рейтингов в группе большой — матчмейкер находит более слабых противников, чтобы компенсировать.

Создание матча при нахождении всех сторон — атомарная транзакция: удалить всех из очереди, создать room, уведомить клиентов через WebSocket или push. Если создание room упало — вернуть игроков в очередь.

Состояния клиента

Клиент при входе в матчмейкинг переходит по состояниям:

IDLE → SEARCHING → FOUND → JOINING → IN_MATCH

Каждое состояние — отдельный UI. SEARCHING показывает анимацию и таймер. FOUND — краткий экран "Противник найден" (2-3 секунды, нельзя отменить). JOINING — подключение к игровому серверу. Отмена доступна только из SEARCHING.

На клиенте состояние матчмейкинга — StateFlow (Kotlin) или @Published (Swift), обновляется через WebSocket-события от сервера.

Ориентировочные сроки и стоимость

Базовый матчмейкинг по рейтингу с expand-and-wait для 2 игроков: 1-2 недели. Региональный матчмейкинг, мультимерный MMR, партийные матчи: 1-2 месяца. Стоимость рассчитывается индивидуально после анализа жанра и аудитории. Свяжитесь с нами — оценим проект за 2 дня.

Интеграция API в мобильное приложение: с чего начать

Запрос уходит, ответ не приходит, timeout — 30 секунд. Пользователь смотрит на спиннер. Сети нет — мобильная карта в метро. Или сеть есть, но сервер вернул 200 с HTML-страницей ошибки вместо JSON — и приложение крашит при JSONDecoder.decode(). Мы видим такие кейсы на каждом втором проекте. Поэтому интеграция API в мобильное приложение — это не просто вызов endpoint'а, а проектирование надёжного сетевого слоя: обработка ошибок, кэширование, offline-режим, certificate pinning. Закажите аудит текущего сетевого слоя — оценим проект за 1 день.

Почему стандартные библиотеки недостаточны? URLSession и OkHttp предоставляют базовый HTTP-клиент, но для production нужны retry с exponential backoff, валидация статус-кодов, типизированная десериализация и мониторинг состояния сети. Без этого приложение теряет данные и пользователей. Мы уже 5 лет занимаемся мобильной разработкой и реализовали более 30 проектов с интеграцией API на iOS, Android и Flutter — от стартапов до enterprise-решений.

Как выбрать протокол для интеграции API?

REST остаётся стандартом для большинства проектов. Но когда на экране профиля нужно 5 полей из 40, GraphQL исключает over-fetching и сокращает трафик на 30–60%. gRPC оправдан при тысячах запросов в минуту (trading, IoT) — бинарная сериализация в 3–5 раз быстрее JSON. WebSocket — единственный выбор для real-time без polling (сообщения, уведомления).

Пример из практики: для финтех-приложения мы заменили REST (40 полей) на GraphQL — размер ответа сократился с 12 КБ до 2,5 КБ, время рендера экрана упало на 70%. Экономия трафика составила около 15 000 ₽ в месяц при 100 000 активных пользователей.

Как обеспечить надёжность соединения и offline-first

Пользователи теряют сеть в метро, лифте, тоннеле. Мобильное приложение обязано работать без интернета — хотя бы в read-only режиме. Мы внедряем паттерн offline-first:

1. При открытии экрана сначала показываем данные из локального кеша (Core Data / Room).
2. Параллельно выполняем сетевой запрос, обновляем UI после ответа.
3. Если сеть недоступна — показываем кешированные данные и метку «нет соединения».
4. При восстановлении сети автоматически синхронизируем изменения.

Для кэширования HTTP-ответов используем URLCache (iOS) и OkHttp Cache (Android) с поддержкой Cache-Control. Для структурированных данных — SwiftData / Room. NWPathMonitor / ConnectivityManager.NetworkCallback отслеживают состояние сети и триггерят обновление.

REST и выбор клиентской библиотеки

Alamofire (iOS) — де-факто стандарт для Swift-проектов. Поверх URLSession добавляет request chaining, response validation, automatic retry, certificate pinning через ServerTrustManager. AF.request() с .validate() возвращает ошибку для любого статус-кода вне 200–299. Без .validate() Alamofire считает 404 и 500 успешными ответами. С Swift Concurrency — async-версия через serializingDecodable.

Retrofit (Android) — аннотационный HTTP-клиент поверх OkHttp. Интерфейс с аннотациями компилируется в реализацию. @GET, @POST, @Path, @Query, @Body — декларативное описание API. OkHttp под капотом: connection pooling, transparent gzip, HTTP/2 multiplex. HttpLoggingInterceptor — логирование в debug-сборке. Authenticator — автоматический refresh токена при 401.

Ktor (KMM/Flutter) — мультиплатформенный HTTP-клиент. На iOS работает через Darwin engine (URLSession), на Android — через OkHttp. Единый код для обеих платформ при KMM-архитектуре.

GraphQL: когда REST не справляется

REST возвращает фиксированную структуру. Экран профиля требует name, avatar, email — сервер отдаёт 40 полей. Over-fetching. GraphQL решает это: клиент запрашивает ровно нужные поля. Это критично для мобайла, где трафик и время парсинга — реальные ограничения. Apollo iOS и Apollo Kotlin генерируют типизированные классы по схеме: schema.graphql + query-файлы → строгие типы на этапе компиляции. Subscriptions через WebSocket — real-time без polling. Ограничение: GraphQL сложнее кешировать на уровне HTTP. Apollo использует нормализованный in-memory кеш InMemoryNormalizedCache — запросы с пересекающимися данными обновляют кеш без дублирования. Apollo GraphQL Documentation

WebSocket: real-time без лишнего трафика

Polling (setInterval каждые 5 секунд) — трата батареи и трафика. WebSocket — постоянное двунаправленное соединение. iOS: URLSessionWebSocketTask (нативный, iOS 13+). Android: OkHttp WebSocket. Обязательная обработка reconnect: при onFailure — экспоненциальный backoff (1с → 2с → 4с → 8с → максимум 60с). Socket.IO — надстройка с автоматическим reconnect, но для новых проектов предпочтительнее нативный WebSocket (меньше зависимостей).

gRPC: для высоконагруженных сервисов

gRPC с protobuf — бинарная сериализация: меньше размер, быстрее парсинг. grpc-swift для iOS, grpc-kotlin для Android. Protobuf-схема компилируется в типизированные классы. Streaming (server-side, client-side, bidirectional) — нативная возможность. Порог применения: высокая частота запросов (trading, IoT) или критичная latency. Для обычного CRUD REST проще в дебаге и мониторинге.

Certificate Pinning и безопасность

Корпоративный proxy может перехватить HTTPS через подмену сертификата. Certificate pinning предотвращает это: приложение принимает только конкретный сертификат или публичный ключ. Alamofire: ServerTrustManager с PinnedCertificatesTrustEvaluator. OkHttp: CertificatePinner с SHA-256 хешем. Операционная сложность: при ротации сертификата старые версии приложения перестают работать. Решение — pinning на публичный ключ CA или поддержка нескольких пинов с grace period. Подробнее о certificate pinning на Wikipedia

Что входит в работу

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

Сроки и стоимость

Реализация сетевого слоя с REST, retry, кэшированием и offline-режимом — 1–2 недели. Добавление GraphQL или WebSocket — ещё 1–2 недели. gRPC — 2–3 недели, включая кодогенерацию. Стоимость рассчитывается индивидуально после анализа API и требований к offline-поведению. Оценим проект за 1 день — свяжитесь для консультации.