Ігровий сервер для кооперативного екшену - авторитетна симуляція, матчмейкінг та античит на базі Node.js + Colyseus

Початкова ситуація полягає в тому, що існує прототип кооперативної гри в Unity (Netcode для GameObjects) для 2-8 гравців. З'явилися проблеми на P2P - розсинхронізація, відсутність компенсації лагов, хост виходить - матч розвалюється, чітери змінюють параметри шкоди і швидкості. Вам потрібно перейти на спеціалізований авторитетний сервер із кімнатами, пошуком партнерів і мінімальними античітами, зберігаючи поточну логіку бою та інвентарю.

Технічне середовище - Linux (Ubuntu 22.04), Docker, Node.js 20 LTS, Colyseus 0.15+, Redis (для черг та присутності), PostgreSQL (для акаунтів та прогресу), Nginx (TLS termination), GitHub Actions (CI). Клієнт Unity 2022 LTS, транспорт WebSocket (без WebRTC). Розгортання в одному регіоні (поки що без мульти-регіону).

Що має вийти - робочий серверний backend з авторитетною симуляцією ключових механік (пересування, отримання втрат, смерть/респаун, лут та інвентар) та інфраструктурою матчів. Результат повинен бути відтворюваним у Docker Compose і мати базовий набір метрик/логів для діагностики.

Обсяг робіт з етапів
1) Аналіз поточної мережевої моделі – розібрати протокол повідомлень клієнта, виділити стани, які мають стати серверними, та запропонувати схему подій/снапшотів. Підсумком має бути документ на 1-2 сторінки з переліком authoritative state, списком client commands та планом міграції.
2) Реалізація сервера Colyseus
- Кімнати матчів із життєвим циклом: очікування – запуск – гра – завершення
- Matchmaking по режиму та діапазону MMR (спрощено) з чергою у Redis
- Авторитетна обробка команд клієнта: input movement, use item, attack, pickup, drop
- Серверна валідація: швидкість, частота атак, радіуси підбору, cooldowns
- Tickrate 20/s, снапшоти стану 10/s, інтерполяція на клієнті залишається на стороні Unity (потрібно визначити формат даних)
3) Збереження та прогрес
- PostgreSQL схема: users, sessions, progression (мінімально), match_results
- JWT авторизація (access token) та серверна перевірка на вході до кімнати
- Запис результатів матчу та оновлення MMR
4) Античит мінімального рівня
- Rate limiting на команди
- Серверні перевірки неможливих станів (teleport, speedhack, rapid fire)
- Система порушень: N підозрілих подій за матч - позначка в match_results та кік з кімнати
5) Інфраструктура та якість
- Docker Compose: game-server, redis, postgres, nginx
- Healthchecks, structured logging (pino чи аналог), базові метрики (Prometheus endpoint чи прості counters в /metrics)
- GitHub Actions: лінт, тести (мінімум unit на валідацію команд), складання Docker образу

Обмеження
- Не можна використовувати managed-сервіси, все має працювати на одній машині в Docker Compose
- Без покупки платних античит-рішень та без kernel-драйверів
- Клієнт Unity міняти можна мінімально – допускається додавання тонкого шару адаптера для нового протоколу та інтерполяції, але без переписування всієї гри
- Зовнішні залежності мають бути поширеними та активно підтримуваними

Вимірні критерії приймання
- Піднімається однією командою docker compose up, після чого доступні: /health, /metrics, створення матчів та підключення клієнтів
- Під навантаженням 8 гравців в одній кімнаті сервер тримає 20 tick/s без деградації більше 10% на машині 4 vCPU 8GB (перевірка простим скриптом-ботом або вбудованим load-сценарієм)
- Сервер відхиляє як мінімум 5 типів чит-команд: перевищення швидкості, прискорена атака, спроба завдати шкоди без влучення за серверною моделлю, підбір лута поза радіусом, спам команд понад ліміт
- Результати матчу пишуться у PostgreSQL, MMR оновлюється, повторний вхід користувача зберігає прогрес
- У репозиторії є README з кроками запуску, змінними оточення та описом протоколу повідомлень

Доступні матеріали – поточний Unity проект (репозиторій), опис ігрових механік, список повідомлень/подій у поточному прототипі. Очікується підсумковий PR/репозиторій із сервером, конфігами, міграціями БД та мінімальними правками клієнта, необхідними для підключення до нового сервера.