Brevet FR2922463A1 — publié le 20090424

F4_3.FRD.doc Système de jeu informatique en ligne avec gestion de la latence. L'invention concerne les systèmes de jeu électronique. Les jeux dits "jeux en ligne", dans lesquels des joueurs peuvent interagir chacun sur leur ordinateur sans être regroupés dans un même endroit sont devenus extrêmement populaires avec l'avènement d'Internet. Parmi ces jeux, on connaît ceux du type dit "jeu massivement multi-joueurs en ligne". Ils opèrent souvent en temps réel. En pareil cas, le module de jeu interagit avec une ou des plateformes centrales de jeu, dans le cadre d'un réseau étendu, tel qu'Internet. Une partie substantielle des fonctions de jeu est gérée dans la plateforme centrale. De son côté, le système hôte du joueur comporte localement une pluralité de fonctions internes de jeu, susceptible d'être lancées par une action utilisateur, sur clavier, souris ou d'une autre manière. Le traitement d'une interaction entre deux joueurs, de même que d'autres traitements, peut passer par un échange d'informations sur le réseau, en particulier Internet. Les délais de transmission d'informations posent alors problème, d'autant plus que le jeu entend s'approcher du temps réel, a fortiori pour un jeu sportif rapide. Ces délais de transmission ont en outre une composante variable que l'on peut qualifier d'aléatoire, au moins partiellement. Les problèmes qui en découlent rendent la réalisation de certains jeux très délicate, du moins si l'on souhaite un réalisme satisfaisant. La présente invention vient améliorer la situation. Elle vise un système de jeu électronique dans lequel plusieurs ordinateurs de jeu sont connectés en réseau avec un système serveur central ainsi qu'un serveur de temps réseau. Chaque ordinateur de jeu exécute une instance client locale d'un programme de jeu sur la base d'une part de paramètres de jeu distants provenant d'autres ordinateurs de jeu via le système serveur central, et d'autre part d'événements suscités par un utilisateur (joueur) sur cet ordinateur, ou plus généralement de paramètres de jeu locaux. Selon un aspect de l'invention, l'instance client locale comprend une correspondance, telle qu'une table, qui associe des événements à des temps. En présence d'un événement utilisateur local traité dans la table, l'ordinateur de jeu émet un appel vers le serveur. Cet appel comprend (au moins) un identifiant de l'événement, et une heure tirée du temps présent, augmenté d'un délai défini par la donnée de temps qui correspond à l'événement dans la table. L'ordinateur de jeu exécute localement l'action correspondant à l'événement concerné à l'heure prévue. Un ordinateur distant pourra effectuer sa propre action à la même heure prévue, tant que le délai de propagation lié au réseau n'excède pas la valeur de ladite donnée de temps. Dans des modes de réalisation particuliers le système présente les caractéristiques suivantes : * l'action associée à un événement comportant une préparation, l'ordinateur local réalise sa préparation pendant le délai défini par la donnée de temps, tandis que l'ordinateur distant réalise une préparation raccourcie pour que son action soit sensiblement synchrone de celle dudit ordinateur local compte tenu du délai de propagation réseau ; * en cas de dépassement de l'heure ou du délai au niveau de l'ordinateur distant, celui-ci réalise une opération de réconciliation tendant à retrouver la même situation d'écran que sur l'ordinateur local ; * certains au moins des ordinateurs de jeu comportent un moteur de mouvements qui comprend un moteur d'affichage, un moteur de détection de collision, et un moteur de résolution de collision ; * la résolution de collision est traitée avec un maillage plus grossier que celui de la détection de collision, qui est elle-même traitée avec un maillage plus grossier que la 25 résolution d'affichage ; et * le moteur de détection de collision est utilisé en commun par une partie au moins des fonctions sur événements du jeu. D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la 30 description détaillée ci-après, faite en référence aux dessins annexés, sur lesquels : - La figure 1 est le schéma de principe d'un système de jeu massivement connecté, La figure 2 est un diagramme de flux illustrant un mode de réalisation de l'invention, La figure 3 est le schéma de principe d'un système de jeu massivement connecté, selon l'invention, et La figure 4 est un diagramme de flux illustrant un traitement de collision selon un mode de réalisation de l'invention. Les dessins et la description ci-après contiennent, pour l'essentiel, des éléments de caractère certain. Ils pourront donc non seulement servir à mieux faire comprendre la 10 présente invention, mais aussi contribuer à sa définition, le cas échéant. Sur la figure 1, des joueurs Pl, P2, P3, ... Pn sont interconnectés par un réseau étendu NET à un serveur central de jeu CGS. 15 Chaque joueur possède dans son appareil une instance locale de jeu, avec des "fonctions locales" de jeu, et des "fonctions distantes" qui font appel à des communications avec le serveur central CGS, sur lequel se trouve une instance distante de jeu pour le même joueur, et d'autres instances distantes pour d'autres joueurs en interaction avec lui. 20 Pour se trouver interconnecté avec de nombreux autres joueurs, un joueur donné, par exemple P1, doit d'abord s'inscrire sur le serveur central, en fournissant un mot de passe. Une instance distante du jeu est alors créée pour lui. Elle le représente parmi les instances distantes de jeu respectives de nombreux autres joueurs. 25 Les interactions entre les joueurs, ainsi qu'avec leur environnement dans le jeu, sont déterminés par le serveur central. Ces interactions entre les joueurs sont modifiées par une action d'un joueur, ou des actions respectives de plusieurs joueurs : action à la souris, au clavier, sur manette de 30 jeu, ou sur tout autre périphérique d'entrée/sortie de l'utilisateur. Dans la terminologie informatique, c'est ce que l'on appelle un événement. En ce sens, même l'entrée ou la réentrée d'un joueur dans le jeu est un événement. Le serveur central CGS détermine les interactions entre joueurs au niveau des instances distantes de jeu qu'il contient (ou gère) pour tous les joueurs (ou tout du moins pour tous ceux qui sont concernés au moment de l'action). Ce même serveur central CGS fait évoluer les interactions entre joueurs à l'aide d'échanges d'informations avec ceux-ci sur le réseau. Le plus souvent, les ordinateurs de joueurs n'échangent pas d'information directement entre eux. En général, les échanges sur le réseau peuvent être de deux classes : -action A11 du joueur Pl -> serveur (calcul de l'effet de l'action sur Pl et les autres joueurs) ; - information du serveur aux autres joueurs sur leurs états respectifs après l'action Al 1. Ce traitement des interactions fait partie des "fonctions distantes" du jeu pour chacun des joueurs. Tout cela doit fonctionner en temps réel, en présence du retard ou "latence" (en anglais "lag") inhérent à un réseau étendu comme Internet. En fait, cette latence tient au temps de réponse du serveur lui-même, ainsi qu'au temps d'aller et au temps de retour sur Internet. Il présente une composante aléatoire. Il faut comprendre ici que le temps de latence est à apprécier en regard du temps critique d'interaction entre les joueurs. La latence est en général appréciée comme le temps de latence moyen sur la base du retard moyen observé par les joueurs à un instant donné. La composante variable de la latence peut ainsi venir déséquilibrer une latence qui était auparavant acceptable au vu du temps critique d'interaction entre les joueurs. Par ailleurs, les jeux en question nécessitent bien entendu des liaisons Internet rapides. Quelle que soit leur rapidité, celles-ci sont sujettes à des variations aléatoires. Actuellement, les jeux connectés gèrent peu ou pas la présence de la latence, la 30 variation de la latence et ses conséquences sur le synchronisme du jeu. Si par exemple un guerrier fait une manoeuvre rapide de tournoiement, celle-ci est gérée de façon locale dans la machine du joueur, et de même pour un autre guerrier dans la machine d'un autre joueur. Pour déclencher cela, il suffit de transmettre sur Internet un ordre du type "mouvement rapide du guerrier". Le résultat de l'affrontement des deux guerriers peut dépendre directement de la réaction du deuxième joueur à cette manoeuvre. En présence d'une latence excessive, le deuxième joueur va être confronté à l'action effectuée par le premier joueur, sans avoir eu le temps de réagir. Dans le cas des guerriers ci-dessus, cela signifie que le deuxième joueur ne verra pas toute l'animation du "mouvement rapide du guerrier", et qu'il sera confronté à la nouvelle position et/ou conséquence de l'action du premier joueur lorsque la nouvelle position de celui-ci lui parviendra. Les jeux actuels rattrapent ainsi brutalement la latence au moment où la réponse du serveur intervient, par des saccades. Dans certains cas, l'action du premier joueur est précédée d'un artifice visuel qui décale l'exécution d'une action, comme un curseur qui tournoie ou tout autre animation de ce type. Cependant, cela ne change en rien l'absence de gestion de la latence : si elle est trop importante, le deuxième joueur perçoit une saccade importante et subit la perte de temps correspondante. Cela est particulièrement gênant dans les jeux du type courses de véhicules, match de tennis, de football, de basket-ball ou autre, dans lesquels le temps critique d'interaction est faible, ce qui les rend particulièrement sensibles à la latence. En fait, les jeux connectés en ligne actuels et plus particulièrement les jeux massivement multi-joueurs actuels ne sont pas capables de gérer de manière efficace en termes d'interaction des éléments se déplaçant à grande vitesse et/ou subissant des collisions. Sur un autre plan, ils utilisent un moteur unique pour gérer la détection des collisions d'une part, et la résolution des collisions d'autre part. La Demanderesse s'est proposé d'offrir des jeux rapides en mode connecté, par exemple courses de véhicules, match de tennis, de football, de basket-ball ou autre. Il est alors nécessaire d'adapter la technique actuelle à la nécessité de gérer la latence sans altérer le réalisme du jeu. Ainsi, la présente invention a pour premier but de permettre la mise en oeuvre de jeux 10 rapides en mode connecté, et plus particulièrement en mode massivement connecté et multi-joueurs. Elle permet d'obtenir un degré de réalisme élevé, même en passant par des serveurs de centralisation de jeu (qui ajoutent à la latence). L'invention trouve une application 15 particulièrement avantageuse dans son application à un serveur comme celui décrit dans la Demande de Brevet français n°07/07239. Elle reste également applicable dans le cas de jeux connectés faisant appel à des connexions entre joueurs du type pair à pair. Le schéma général de la figure 3 correspond à un mode de réalisation de l'invention. Il 20 est généralement semblable à celui de la figure 1. Il fait apparaître un serveur de temps commun COMM.TIME_SRVR. Le système serveur central interagit avec les différents postes de joueurs, de sorte que chacun de ces postes possède une référence temporelle alignée sur le temps de référence, fourni par le serveur de temps commun. 25 L'un des aspects techniques de l'invention sera maintenant décrit en référence à la Figure 2. Le bloc d'entrée 200 indique que le joueur P1, sur son poste avec son instance client Clil, a déclenché une action EVENT, par exemple à la souris ou sur manette de jeu. A 30 l'opération 202, il s'ensuit le calcul d'un instant ou temps d'action Tact, établi à partir du temps présent augmenté d'un retard qui peut être fonction de la nature de l'action dont il s'agit. Ceci est représenté par une fonction Ltime(event, delay). Ainsi chaque instance client d'un jeu particulier peut comporter une correspondance entre certains au moins des événements traités par cette instance du jeu, et des données de temps correspondantes. Cette correspondance est stockée par exemple sous forme d'une table. On peut prévoir la même donnée de temps pour tous les événements d'un groupe, défini par une règle ou par une liste. Ensuite, l'opération 204 envoie au serveur les données sur l'action EVENT, et la valeur Tact. Puis l'opération 208 attend l'instant Tact, avant d'effectuer pour le joueur local P1, sur son poste Cli1, l'action EVENT. Ceci est représenté par une fonction Do(event, l 0 chi), à l'opération 210. On revient à l'opération 204, qui est représentée par une fonction Cali Serv(Event, Tact, Cli 1). Le passage de Cli 1 comme paramètre indique que le client Cli 1 est l'émetteur. Le serveur reçoit l'appel de la fonction Call_Serv() en 220, et récupère les paramètres d'action ainsi que la liste des autres joueurs concernés par l'action EVENT du joueur P1. On suppose ici qu'il s'agit d'un joueur ayant un poste avec son instance client Cli2. 20 Dans une opération 222 optionnelle, le serveur détecte qu'il doit réaliser un calcul local ou exécuter une fonction particulière avant de transmettre l'action EVENT, puis dans une opération 224, il transmet l'action par une fonction Call_Cli(Event, Tact, Clil) qui transmet les paramètres d'action aux clients déterminés dans l'opération 220. 25 En 230, le poste Cli2 reçoit du serveur un message indiquant l'action EVENT et le temps Tact. Cette réception intervient à l'instant T_rec. En 232 est calculé l'écart T prep entre Tact et T_rec. Si cet écart est positif en 234, l'opération 236 attend pendant le délai T prep (ou, ce qui revient au même, jusqu'à Tact, avant l'opération 238, qui est l'exécution de la fonction Do(event, Cli1) sur le client Cli2, de manière 30 homologue à la fonction Do(event, Clil) de l'opération 210, au sens des interactions dans le jeu. 15 En général, ces fonctions déclenchent une animation ayant une certaine durée, notée ici DuratAnim. Si l'écart est négatif en 234, on teste en 240 la valeur T_prep + DuratAnim. Si elle est positive, l'opération 242 fait la même chose que l'opération 238, sauf que l'animation est accélérée, de sorte que sa durée soit raccourcie de la valeur absolue de T_prep. Si la valeur T_prep + DuratAnim reste négative, alors on saute l'animation, et on met en place en 244 une opération de réconciliation pour rejoindre l'état que l'on doit avoir, à un instant choisi, après Tact. S'agissant par exemple d'un jeu de tennis à deux joueurs P1 et P2, et en admettant que le joueur P 1 commande une frappe de balle par sa raquette RP1 : - l'exécution locale de la frappe sur le poste Cli1 de P1, c'est-à-dire le début du mouvement de raquette, est décalée de par exemple 100 millisecondes. - si l'information arrive au poste Cli2 de P2 dans les 100 millisecondes, le mouvement de la raquette de P1 sur le poste Cli2 est le même que sur le poste Clil. - si l'information arrive au poste Cli2 de P2 après les 100 millisecondes, mais avant la fin du mouvement de la raquette de P1, alors ce mouvement est produit sur le poste Cli2, mais accéléré. Ce mouvement peut être accéléré pour se terminer en même temps que sur le poste Cli 1. Des considérations de réalisme peuvent conduire à une accélération un peu moindre, suivie d'un complément de rattrapage de temps sur le mouvement de la balle après la fin du mouvement de la raquette (une extrapolation lissée"). - si l'information arrive au poste Cli2 de P2 après les 100 millisecondes, et après la fin du mouvement de la raquette de Pl, le poste Cli2 passe directement au mouvement de la balle, extrapolé par l'opération de réconciliation pour rattraper le temps, et éventuellement précédé d'un saut brusque de raquette ou autre symbolisation de la frappe de la balle. L'opération de réconciliation a pour rôle principal de gérer les cas dans lesquels l'écart de synchronisation entre les joueurs est trop conséquent, et peut pénaliser un ou plusieurs d'entre eux. Dans le mode de réalisation décrit ici, l'opération de réconciliation est réalisée de la manière suivante : - les clients s'envoient régulièrement des messages simples de synchronisation, qui leur permettent d'appréhender la magnitude de la latence, ces envois étant réalisés 5 parallèlement à l'exécution du jeu, - lorsqu'un client récepteur, par exemple le client Cli2 dans l'exemple de la figure 2, détecte qu'il a reçu un message trop tard, il effectue une distorsion locale de l'échelle de temps, par exemple en ralentissant le mouvement du client émetteur, c'est-à-dire Cli i dans l'exemple de la figure 2, 10 - parallèlement, le client récepteur (Cli2) envoie un message au client émetteur (Cli 1) pour lui indiquer qu'il a distordu son échelle locale de temps, - le client émetteur (Clil) distord de manière homologue son échelle locale de temps pour conserver le synchronisme avec le client récepteur (Cli2), - lorsqu'il a fini son action de rattrapage, le client récepteur (Cli2) émet un message 15 correspondant au client émetteur (Clil), et - le client émetteur (Clil) met fin à son opération de distorsion à la réception de ce message. Sur la figure 3, on voit également, dans une des stations des joueurs (P1), trois moteurs 20 (informatiques) distincts, à savoir : - un moteur de détection de collision (301), - un moteur de résolution de collision (302) et, - un moteur d'affichage (303). 25 Cette structure de moteurs est présente dans toutes les stations représentées sur la figure 3, bien qu'elle soit optionnelle d'une manière générale. Cette structure est inhabituelle, compte tenu notamment de la rapidité requise pour les traitements graphiques et physiques dans les jeux dont il s'agit. En effet, classiquement, 30 on utilise un moteur unique pour la détection de collision et la résolution de collision, puis l'affichage. Le schéma de principe correspondant est donné sur la figure 4. De façon générale, les mouvements des objets dans la scène sont régis par des équations de mouvement, comme indiqué par le bloc 400. Le mot objet s'entend au sens large et inclut des personnages (ou "avatars") ou des véhicules. Il désigne un objet informatique (ensemble de valeurs et/ou de fonctions), propre à permettre la représentation à l'écran d'un objet physique virtuel qui lui correspond. La référence à des objets informatiques - n'implique pas nécessairement une programmation par objets. Le bloc 402 détecte les éventuelles collisions entre deux objets X et Y. En cas de collision, le bloc 404 "résout" ces collisions, c'est-à-dire traite des changements temporaires aux équations de mouvement qui sont dus à la collision, quant aux objets X et Y. En l'absence de collision, les positions des objets X et Y (406) sont converties en paramètres d'affichage (408), qui sont utilisés pour l'affichage (410). En présence d'une collision, les positions obtenues pour X et Y après sa résolution sont directement appliquées au bloc 408 pour en tirer des paramètres d'affichage. La séparation du moteur physique en trois moteurs 301, 302, 303 indépendants permet que chaque moteur soit réglé et optimisé indépendamment des deux autres. Selon le mode de réalisation actuellement préféré, la résolution de collision (303) est traitée avec une maillage plus grossier que celui de la détection de collision (302), qui est elle-même traitée avec un maillage plus grossier que la résolution d'affichage. Ainsi, on peut anticiper sur la détection de collision, et/ou rendre le traitement de collision plus simple, voire très simple. Dans un exemple simplifié où les collisions sont définissables avec 2 dimensions, on peut ainsi prendre une intersection entre 2 lignes droites, par exemple extrapolant la trajectoire en cours. Cette détection de collision peut être standard. Par contre, la résolution de collision dépend des caractéristiques du jeu concerné.30 Revendications 1. Système de jeu électronique dans lequel plusieurs ordinateurs de jeu (P1..Pn) sont connectés en réseau avec un système serveur central (CGS) ainsi qu'un serveur de temps réseau (COMM. TIME SRVR), chaque ordinateur étant apte à exécuter une instance client d'un programme de jeu sur la base en partie de paramètres de jeu d'autres ordinateurs de jeu connectés au serveur, et d'événements suscités par un utilisateur sur cet ordinateur, caractérisé en ce que l'instance client comprend une correspondance entre des événements et des données de temps, en ce qu'en présence d'un événement utilisateur muni d'une telle correspondance, l'ordinateur de jeu est apte à émettre un appel vers le serveur (204), cet appel comprenant, au moins, un identifiant de l'événement, et une heure tirée du temps présent augmenté d'un délai défini par la donnée de temps correspondante, et à est apte exécuter localement l'action correspondant à l'événement à l'heure prévue (210), tandis qu'un ordinateur distant pourra effectuer sa propre action à la même heure prévue (238), tant que le délai de propagation réseau n'excède pas la valeur de la donnée de temps. 2. Système de jeu électronique selon la revendication 1, caractérisé en ce que, l'action associée à un événement comportant une préparation, l'ordinateur local est apte à réaliser sa préparation pendant le délai défini par la donnée de temps (208), tandis que l'ordinateur distant est apte à réaliser une préparation raccourcie (242) pour que son action soit sensiblement synchrone de celle dudit ordinateur local compte tenu du délai de propagation réseau. 3. Système de jeu électronique selon l'une des revendications 1 et 2, caractérisé en ce que, en cas de dépassement de l'heure ou du délai au niveau de l'ordinateur distant, celui-ci est apte à réaliser une opération de réconciliation (244) tendant à retrouver la même situation d'écran que sur l'ordinateur local. 4. Système de jeu électronique selon l'une des revendications précédentes, dans lequel certains au moins des ordinateurs de jeu comportent un moteur de mouvements, 11caractérisé en ce que le moteur de mouvement comprend un moteur d'affichage (301), un moteur de détection de collision (302), et un moteur de résolution de collision (303). 5. Système de jeu électronique selon la revendication 4, caractérisé en ce que la résolution de collision (303) est apte à être traitée avec un maillage plus grossier que celui de la détection de collision (302), qui est elle-même apte à être traitée avec un maillage plus grossier que la résolution d'affichage.