REMATCH avait envisagé une première bêta de Netcode 2.0 pour le 13 octobre, à titre provisoire. La refonte prévoit de confier au serveur la décision des contacts et d’introduire un délai fixe de 50 millisecondes avant l’affichage des animations du personnage. Les commandes, elles, continueront d’être envoyées immédiatement.
L’objectif annoncé dans le billet du 9 octobre est de réduire les rollbacks, ces corrections qui surviennent lorsque le serveur rectifie une action déjà affichée à l’écran. Le fonctionnement prévu repose sur un compromis : différer légèrement ce que le joueur voit pour limiter les écarts entre son écran et la décision du serveur.
À retenir
- Première bêta envisagée pour le 13 octobre à titre provisoire, sans horaire confirmé dans l’annonce.
- Les contacts seront prédits et résolus par le serveur.
- La première bêta prévoit un délai d’affichage fixe de 50 ms.
- Un délai réglable est annoncé pour une bêta suivante.
Des contacts décidés avant leur affichage
Le système actuel laisse le client — le jeu exécuté sur la machine du joueur — initier et prédire les contacts, avant leur vérification par le serveur. Netcode 2.0 inverse cette logique : le serveur doit décider du contact avant que son résultat apparaisse à l’écran.
Cette modification concerne notamment les tacles, plongeons, prises de balle et contrôles. Elle touche donc directement les interactions avec le ballon et les autres joueurs. L’objectif est de montrer moins souvent une action que le serveur devra ensuite corriger.
La durée totale des animations restera identique, précise l’équipe. C’est le minutage interne de leur phase préparatoire qui sera ajusté. Il faut distinguer ce changement du délai ajouté avant leur affichage : une animation différée ne signifie pas que sa durée totale augmente.
50 ms à l’écran, sans retarder l’envoi des commandes
Pour la première bêta, les 50 millisecondes seront fixes. Ce délai concerne l’affichage des animations du personnage ; les commandes partiront toujours immédiatement vers le serveur. Il ne s’agit donc pas d’un temps d’attente ajouté avant leur transmission, même si le joueur verra les animations commencer plus tard.
Le réglage du délai est prévu pour une bêta suivante, sans date annoncée dans le billet. La distinction entre ces étapes compte : la première bêta est annoncée avec une valeur imposée, tandis que la possibilité de la modifier viendra ensuite.
Un ping élevé pourra entraîner davantage de corrections visibles
L’équipe attend moins de rollbacks, pas leur disparition. Les pertes de paquets, un ping instable ou très élevé resteront problématiques. Elle prévient aussi que les joueurs à ping élevé pourront voir davantage de corrections sur leur propre écran, particulièrement lors des actions rapides.
Pour les signalements, le studio demande des exemples précis sur Feature Upvote : étapes de reproduction, fréquence du problème et périphérique utilisé. Les vidéos doivent également montrer les commandes. Ces éléments servent à décrire le problème rencontré et les conditions dans lesquelles il apparaît ; ces consignes concernent les retours, pas l’accès à la bêta.
La refonte réseau a aussi mis en attente plusieurs améliorations du gameplay, que l’équipe compte reprendre après Netcode 2.0, sans calendrier annoncé dans le billet. Le bénéfice attendu reste donc assorti d’un compromis : moins de rollbacks selon le studio, avec un affichage différé et des corrections qui pourront rester plus visibles sur les connexions à ping élevé.
Retrouvez également la fiche de REMATCH.
