Serveur de jeu pour l'action coopérative - simulation, matchmaking et anti-triche faisant autorité basés sur Node.js + Colyseus

La situation initiale est qu'il existe un prototype de jeu coopératif dans Unity (Netcode pour GameObjects) pour 2 à 8 joueurs. Des problèmes sont apparus sur le P2P - désynchronisation, pas de compensation de décalage, l'hôte s'arrête - le match s'effondre, les tricheurs modifient les paramètres de dégâts et de vitesse. Vous devez passer à un serveur dédié réputé avec des salles, un matchmaking et un anti-triche minimal, tout en conservant la logique actuelle de bataille et d'inventaire.

Environnement technique - Linux (Ubuntu 22.04), Docker, Node.js 20 LTS, Colyseus 0.15+, Redis (pour les files d'attente et la présence), PostgreSQL (pour les comptes et la progression), Nginx (terminaison TLS), GitHub Actions (CI). Client Unity 2022 LTS, transport WebSocket (pas de WebRTC). Déploiement dans une seule région (pas encore de multi-région).

Ce qui devrait arriver, c'est un backend de serveur fonctionnel avec une simulation faisant autorité des mécanismes clés (déplacement, dégâts subis, mort/réapparition, butin et inventaire) et de l'infrastructure de match. Le résultat doit être déployable de manière reproductible dans Docker Compose et disposer d'un ensemble de base de métriques/journaux pour les diagnostics.

Portée des travaux par étapes
1) Analyse du modèle de réseau actuel : analysez le protocole de message client, mettez en évidence les états qui devraient devenir des états de serveur et proposez un schéma d'événement/instantané. Le résultat devrait être un document d'une à deux pages avec une liste des états faisant autorité, une liste des commandes client et un plan de migration.
2) Implémentation du serveur Colyseus
- Faites correspondre les pièces avec le cycle de vie : attendre - démarrer - jouer - terminer
- Matchmaking par mode et plage MMR (simplifié) avec une file d'attente dans Redis
- Traitement faisant autorité des commandes client : mouvement d'entrée, utilisation d'un objet, attaque, ramassage, drop
- Validation du serveur : vitesse, fréquence d'attaque, rayons de ramassage, temps de recharge
- Tickrate 20/s, state snapshots 10/s, l'interpolation sur le client reste côté Unity (vous devez déterminer le format des données)
3) Sauvegarder et progresser
- Schéma PostgreSQL : utilisateurs, sessions, progression (minimum), match_results
- Autorisation JWT (jeton d'accès) et vérification du serveur à l'entrée de la salle
- Enregistrer les résultats des matchs et mettre à jour le MMR
4) Niveau minimum anti-triche
- Limitation de débit sur les commandes
- Le serveur vérifie les états impossibles (téléportation, speedhack, tir rapide)
- Système de violation : N événements suspects par match - marquez dans match_results et expulsez de la salle
5) Infrastructures et qualité
- Docker Compose : serveur de jeux, redis, postgres, nginx
- Contrôles de santé, journalisation structurée (pino ou similaire), métriques de base (point de terminaison Prometheus ou compteurs simples dans /metrics)
- Actions GitHub : linting, tests (unité minimum pour la validation des commandes), construction d'une image Docker

Restrictions
- Vous ne pouvez pas utiliser de services gérés, tout doit fonctionner sur une seule machine dans Docker Compose
- Sans acheter de solutions anti-triche payantes et sans pilotes noyau
- Le client Unity peut être modifié de manière minime - il est possible d'ajouter une fine couche d'adaptateur pour un nouveau protocole et une nouvelle interpolation, mais sans réécrire tout le jeu
- Les dépendances externes doivent être communes et activement entretenues

Critères d'acceptation mesurables
- Développé avec une commande docker compose up, après quoi les éléments suivants sont disponibles : /health, /metrics, création de correspondances et connexion des clients
- Sous une charge de 8 joueurs dans une salle, le serveur maintient 20 ticks/s sans dégradation de plus de 10% sur une machine 4 vCPU 8Go (vérifié avec un simple script bot ou un script de chargement intégré)
- Le serveur rejette au moins 5 types de commandes de triche : excès de vitesse, attaque accélérée, tentative de causer des dégâts sans toucher le modèle du serveur, ramasser du butin en dehors du rayon, spammer des commandes au-delà de la limite.
- Les résultats des correspondances sont écrits dans PostgreSQL, MMR est mis à jour, la reconnexion de l'utilisateur enregistre la progression
- Le référentiel dispose d'un README avec les étapes de démarrage, les variables d'environnement et une description du protocole de message

Matériel disponible - projet Unity actuel (référentiel), description des mécanismes de jeu, liste des messages/événements dans le prototype actuel. Le PR/dépôt final avec le serveur, les configurations, les migrations de bases de données et les modifications minimales du client requises pour se connecter au nouveau serveur sont attendus.