Реализация матчмейкинга для мобильной игры — от 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 дня.