Rebord, N. & Rodrigues, I. (2017). Le métro du jeu. Genève : AUPTIC.education. Retrieved from https://auptic.education/12com/

comment transformer une todolist en quête de jeu vidéo

https://www.reddit.com/r/SimulationTheory/comments/1lnne2e/gravitational_time_dilation_vs_simulation_tick/

Cette question a-t-elle déjà été abordée ?

Il est bien connu que le temps est plus lent à proximité de la gravité (masse importante) que loin de la gravité (masse faible).

https://en.m.wikipedia.org/wiki/Gravitational_time_dilation

Il est également bien connu que toutes les simulations nécessitent beaucoup plus de calculs lorsque de nombreux objets sont proches les uns des autres que lorsqu'ils sont éloignés les uns des autres.

Certaines simulations dilatent même délibérément le temps (c'est-à-dire la vitesse de la simulation) pour tenir compte de ce phénomène :

https://www.eveonline.com/news/view/introducing-time-dilation-tidi

Donc le temps est plus lent près des planètes parce que la simulation met plus de temps à traiter l'interaction de la matière ? 🤔

On dit souvent que la guerre du lag ne peut pas être gagnée parce que nos joueurs peuvent toujours apporter un vaisseau de plus. C'est fondamentalement vrai, et il est important d'accepter cette vérité dans le cadre du travail que nous effectuons ici, au sein de la Team Gridlock. En plus du travail d'optimisation que nous effectuons, nous nous attaquons également aux problèmes de dégradation, de sorte que lorsque le serveur est surchargé, la situation est gérée de manière raisonnable. C'est le sujet de ce blog aujourd'hui. Mais pour comprendre où nous allons, il faut d'abord savoir où nous sommes. Actuellement, lorsqu'un serveur est surchargé, il n'existe pas de mécanisme explicite pour gérer la situation. Les mêmes mécanismes que ceux qui régissent les opérations normales continuent de fonctionner à leur manière. Il en résulte des comportements intéressants, mais je dois définir certains termes avant d'aller plus loin.

Des Tasklets, des Schedulers et du Yielding

Les serveurs d'EVE Online existent fondamentalement pour exécuter un ensemble de tâches - qu'il s'agisse de répondre à un paquet entrant d'un client ou d'une tâche qui maintient l'état des modules ou, bien, presque tout. Ces tâches sont appelées tasklets pour des raisons que vous n'avez pas besoin de connaître aujourd'hui. Mais comme il s'agit ici d'un ordinateur, une seule tasklet peut être en cours d'exécution à un moment donné et un logiciel doit exister pour décider de quelle tasklet il s'agit. C'est ce qu'on appelle un planificateur.

Il existe de nombreux styles et saveurs d'ordonnanceurs. Celui qui fait fonctionner les tasklets d'EVE Online est assez simple : il s'agit d'un planificateur round-robin, multitâche coopératif. Le fait qu'il s'agisse d'un round-robin signifie simplement que chaque tasklet aura une chance de s'exécuter avant qu'une autre tasklet n'ait deux chances. Il n'y a pas de priorité ou de traitement spécial ici - c'est très équitable dans ce sens ; tout le monde a son tour. Le multitâche coopératif signifie qu'aucune tasklet ne sera interrompue de l'extérieur pendant son exécution. Une tasklet s'exécutera jusqu'à ce qu'elle soit terminée ou jusqu'à ce qu'elle exécute une routine spéciale qui signale au planificateur qu'elle aimerait laisser son tour à tous les autres. C'est ce qu'on appelle le "yielding".

Résumé de la vidéo sur les secrets techniques du multijoueur en jeu vidéo

1. La prouesse technique du multijoueur

• Les jeux vidéo multijoueurs, bien qu’ils paraissent aujourd’hui ordinaires, sont une véritable prouesse technique à cause de la difficulté majeure : la latence.
• Faire cohabiter plusieurs joueurs dans une même partie nécessite des astuces et contournements côté développement afin de minimiser la perception des problèmes.

2. De l’hébergement local aux serveurs dédiés

• À l’origine, les jeux utilisaient le système de “host” : un joueur hébergeait la partie sur son ordinateur, et tous les autres s’y connectaient (comme Minecraft ou les LAN parties d’avant).
• Ce système posait des problèmes d’équité et de triche : l’hôte avait zéro latence et pouvait modifier son jeu ; si l’hôte quittait, la partie s’arrêtait.
• Les studios ont donc basculé vers les serveurs dédiés : un serveur officiel gère la logique du jeu, garantissant que tous les calculs essentiels (dégâts, déplacement, etc.) sont faits côté serveur et non côté joueurs, limitant la triche.

3. Latence : un problème insoluble ou presque

• Malgré les serveurs, la latence reste présente et affecte le ressenti : un tir réussi côté joueur peut ne pas l’être côté serveur si la cible s’est déplacée entre-temps, entraînant “l’oreg” (absence de reconnaissance de tir).
• Les jeux doivent choisir qui avantager : souvent, pour minimiser la frustration, ils privilégient le tireur plutôt que la cible, sauf dans certains contextes (ex. zone d’effet où on protège la victime).

4. Astuces pour masquer la latence

• Les développeurs utilisent des techniques comme :
  • Rembobiner le temps côté serveur lors d’une action, pour simuler la vision du joueur au moment réel où il a déclenché l’action.
  • Simulation côté client : le jeu accepte immédiatement l’action du joueur (ex : lancer un sort), puis le serveur vérifie et, si nécessaire, annule a posteriori l’action (ce qui peut entraîner des corrections visuelles et de gameplay).
• Ce sont des “tricheries” volontaires pour rendre l’expérience fluide : annulation douce des incohérences, ajustements des positions, etc.

5. Les limites et la gestion de la triche

• La distinction entre triche et problème réseau est parfois floue, nécessitant des analyses statistiques pour détecter des comportements abusifs.
• Les cheats type “wall hack” (voir à travers les murs) sont parfois techniquement impossibles à éradiquer sans dégrader l’expérience des joueurs à cause de la latence (affichage instantané des ennemis visibles).

6. Exemples de cas complexes

• Les jeux comme Overwatch construisent leur propre moteur réseau et doivent gérer des situations complexes où le temps, la position et les interactions varient d’un joueur à l’autre.
• Chaque type d’interaction (tir, déplacement, zone d’effet) nécessite une adaptation spécifique du code réseau, ce qui explique la charge de travail immense pour rendre un jeu multijoueur compétitif.

7. Pourquoi les petits studios ne font pas de gros jeux multi compétitifs

• Le “netcode” (la gestion du réseau) représente environ 40 % du travail total pour un jeu multijoueur compétitif : beaucoup d’aspects sont à coder à la main, contrairement à des jeux plus simples où des briques toute faites suffisent.
• Cela explique pourquoi il faut de grandes équipes sur plusieurs années, contrairement à Minecraft développé seul.

8. Message additionnel

• La vidéo contient aussi une annonce pour rechercher un monteur vidéo pour la chaîne.

En synthèse :
Le multijoueur est un domaine d’astuces techniques sophistiquées, requérant des arbitrages constants entre expérience utilisateur et justice compétitive, avec une part importante du développement dédiée à masquer la latence et à limiter la triche. Les grandes équipes derrière les gros jeux sont nécessaires à cause de cette complexité invisible pour le joueur.