WO2009087294A2 - Système de jeu informatique en ligne avec gestion de la latence. - Google Patents

Système de jeu informatique en ligne avec gestion de la latence. Download PDF

Info

Publication number
WO2009087294A2
WO2009087294A2 PCT/FR2008/001433 FR2008001433W WO2009087294A2 WO 2009087294 A2 WO2009087294 A2 WO 2009087294A2 FR 2008001433 W FR2008001433 W FR 2008001433W WO 2009087294 A2 WO2009087294 A2 WO 2009087294A2
Authority
WO
WIPO (PCT)
Prior art keywords
time
game
event
computer
server
Prior art date
Application number
PCT/FR2008/001433
Other languages
English (en)
Other versions
WO2009087294A3 (fr
Inventor
Hugues De Saint Germain
Stanislas De Crevoisier
Original Assignee
F4
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by F4 filed Critical F4
Publication of WO2009087294A2 publication Critical patent/WO2009087294A2/fr
Publication of WO2009087294A3 publication Critical patent/WO2009087294A3/fr

Links

Classifications

    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/55—Controlling game characters or game objects based on the game progress
    • A63F13/56—Computing the motion of game characters with respect to other game characters, game objects or elements of the game scene, e.g. for simulating the behaviour of a group of virtual soldiers or for path finding
    • A63F13/12—
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/55—Controlling game characters or game objects based on the game progress
    • A63F13/57—Simulating properties, behaviour or motion of objects in the game world, e.g. computing tyre load in a car race game
    • A63F13/577—Simulating properties, behaviour or motion of objects in the game world, e.g. computing tyre load in a car race game using determination of contact between game characters or objects, e.g. to avoid collision between virtual racing cars
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/60—Methods for processing data by generating or executing the game program
    • A63F2300/64—Methods for processing data by generating or executing the game program for computing dynamical parameters of game objects, e.g. motion determination or computation of frictional forces for a virtual car
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/60—Methods for processing data by generating or executing the game program
    • A63F2300/64—Methods for processing data by generating or executing the game program for computing dynamical parameters of game objects, e.g. motion determination or computation of frictional forces for a virtual car
    • A63F2300/643—Methods for processing data by generating or executing the game program for computing dynamical parameters of game objects, e.g. motion determination or computation of frictional forces for a virtual car by determining the impact between objects, e.g. collision detection

Definitions

  • the invention relates to electronic game systems.
  • the game module interacts with one or more central game platforms, as part of a wide area network, such as the Internet. A substantial portion of the game functions is handled in the central platform.
  • the player's host system locally comprises a plurality of internal game functions, which can be launched by a user action, keyboard, mouse or in another way.
  • the treatment of an interaction between two players, as well as other treatments, may go through an exchange of information on the network, especially the Internet.
  • the delays of transmission of information pose then problem, especially as the game intends to approach the real time, a fortiori for a fast sports game.
  • These transmission delays also have a variable component that can be described as random, at least partially.
  • the problems that ensue make the realization of some games very delicate, at least if one wishes a satisfactory realism.
  • the present invention improves the situation.
  • the local client instance includes a match, such as a table, that associates events with times.
  • the game computer issues a call to the server.
  • This call comprises (at least) an identifier of the event, and an hour drawn from the present time, plus a delay defined by the time data corresponding to the event in the table.
  • the game computer locally executes the action corresponding to the event concerned at the scheduled time.
  • a remote computer may perform its own action at the same scheduled time, as long as the propagation delay related to the network does not exceed the value of said time data.
  • the system has the following characteristics:
  • the local computer carries out its preparation during the delay defined by the time data, while the remote computer makes a shortened preparation so that its action is substantially synchronous with that of said computer local due to network delay;
  • the remote computer If the time or time is exceeded at the remote computer, it performs a reconciliation operation tending to find the same screen situation as on the local computer; at least some of the gaming computers include a motion engine that includes a display engine, a collision detection engine, and a collision resolution engine;
  • collision resolution is treated with a rougher mesh than that of collision detection, which is itself treated with a mesh coarser than the display resolution;
  • the collision detection engine is used in common by at least some of the game's event functions.
  • FIG. 1 is the block diagram of a massively connected gaming system
  • FIG. 2 is a flow diagram illustrating an embodiment of the invention
  • FIG. 3 is the block diagram of a massively connected gaming system, according to the invention
  • FIG. 4 is a flow diagram illustrating a collision processing according to one embodiment of the invention.
  • players P1, P2, P3,... Pn are interconnected by a NET extended network to a central CGS game server.
  • Each player has in their device a local game instance, with "local” game functions, and “remote functions” that call for communications with the central CGS server, on which a remote game instance is located for the game. same player, and other remote instances for other players interacting with him.
  • a given player for example Pl, must first register on the central server, providing a password.
  • a remote instance of the game is then created for him. It represents it among the distant game instances of many other players.
  • the interactions between the players, as well as their environment in the game, are determined by the central server.
  • the central server CGS determines the interactions between players at the level of remote game instances it contains (or manages) for all players (or at least for all those who are concerned at the time of the action).
  • This same central server CGS changes the interactions between players by exchanging information with them on the network. Most often, player computers do not exchange information directly between themselves.
  • the exchanges on the network can be of two classes: - action AI l of the player Pl -> server (calculation of the effect of the action on Pl and the other players); - information of the server to the other players on their respective states after the action AI l.
  • Latency time is to be appreciated with regard to the critical time of interaction between the players. Latency is generally assessed as the average latency based on the average delay observed by players at a given time. The variable latency component can unbalance a latency that was previously acceptable in view of the critical time of interaction between players.
  • the second player In the presence of excessive latency, the second player will be confronted with the action performed by the first player, without having time to react. In the case of the warriors above, this means that the second player will not see all the animation of the "fast movement of the warrior", and that he will be confronted with the new position and / or consequence of the action of the first player when his new position reaches him.
  • the action of the first player is preceded by a visual artifice that shifts the execution of an action, such as a spinning cursor or any other animation of this type.
  • a visual artifice that shifts the execution of an action, such as a spinning cursor or any other animation of this type.
  • this does not change the lack of management of latency: if it is too important, the second player perceives a significant saccade and suffers the corresponding loss of time.
  • the current online connected games and more particularly the current massively multiplayer games are not able to efficiently manage in terms of interaction elements moving at high speed and / or undergoing collisions.
  • the Applicant has offered to offer fast games in connected mode, such as racing vehicles, tennis, football, basketball or other. It is then necessary to adapt the current technique to the need to manage the latency without altering the realism of the game.
  • the present invention has the primary purpose of enabling the implementation of fast games in connected mode, especially in massively connected and multi-player mode.
  • the invention finds a particularly advantageous application in its application to a server such as that described in French Patent Application No. 07/07239. It also remains applicable in the case of connected games involving connections between peer-to-peer players.
  • Figure 3 corresponds to an embodiment of the invention. It is generally similar to Figure 1. It shows a COMM.TIME SRVR common time server.
  • the central server system interacts with the different player stations, so that each of these stations has a time reference aligned with the reference time provided by the common time server.
  • the input block 200 indicates that the player P1, at his station with his client instance CIi 1, has triggered an EVENT action, for example with the mouse or on the joystick.
  • T act a moment or time of action
  • T act a delay which can be a function of the nature of the action in question. This is represented by a Ltime function (event, delay).
  • each client instance of a particular game may include a correspondence between at least some of the events processed by this instance of the game, and corresponding time data. This correspondence is stored for example in the form of a table. The same time data can be provided for all events in a group defined by a rule or list.
  • operation 204 sends the data on the EVENT action to the server, and the value T act. Then the operation 208 awaits the moment T act, before performing for the local player Pl, on his station CIi 1, the action EVENT. This is represented by a function Do (event, CIi 1), at operation 210.
  • the server receives the call from the Call_Serv () function in 220, and retrieves the action parameters as well as the list of the other players concerned by the EVENT action of the player Pl. It is assumed here that it is about a player with a post with his Cli2 client instance.
  • the server detects that it must perform a local calculation or execute a particular function before transmitting the EVENT action, then in an operation 224, it transmits the action by a function Call_Cli (Event, T_act, CHl) which transmits the action parameters to the clients determined in the operation 220.
  • Call_Cli Event, T_act, CHl
  • the station CH2 receives from the server a message indicating the EVENT action and the time T act. This reception occurs at the instant T rec.
  • T_prep the difference between T act and Tjrec. If this difference is positive at 234, the operation 236 waits during the delay T_prep (or, which amounts to the same, until T act, before the operation 238, which is the execution of the function Do (event, CIi 1) on the client Cli2, in a manner homologous to the function Do (event, CIi 1) of the operation 210, in the sense of the interactions in the game.
  • these functions trigger an animation with a certain duration, noted here DuratAnim.
  • T_prep + DuratAnim If the difference is negative in 234, one tests at 240 the value T_prep + DuratAnim. If it is positive, the operation 242 does the same thing as the operation 238, except that the animation is accelerated, so that its duration is shortened by the absolute value of T_prep.
  • T_prep + DuratAnim If the value T_prep + DuratAnim remains negative, then we skip the animation, and we set up in 244 a reconciliation operation to reach the state that we must have, at a chosen moment, after T act.
  • station Cli2 passes directly to the movement of the ball, extrapolated by the operation of reconciliation to make up time , and possibly preceded by a sudden jump of racket or other symbolization of the striking of the ball.
  • the main role of the reconciliation operation is to manage cases in which the synchronization gap between the players is too great, and can penalize one or more of them.
  • the reconciliation operation is performed as follows:
  • a receiving client for example the client CH2 in the example of FIG. 2
  • detects that it has received a message too late it performs a local distortion of the time scale, for example by slowing down the movement of the sending client, that is to say CIi 1 in the example of Figure 2, - in parallel
  • the receiving client (Cli2) sends a message to the sending client (CHl) to indicate that it has distorted its scale local time
  • the sending client (CIi 1) is homologously distorting its local time scale in order to maintain synchronism with the client client (Cli2),
  • the receiving client (Cli2) sends a message corresponding to the sending client (CIi 1), and
  • the sending client terminates its distortion operation upon receipt of this message.
  • FIG. 3 also shows, in one of the player stations (P1), three distinct (computer) engines, namely:
  • This engine structure is present in all the stations shown in Figure 3, although it is optional in general.
  • the movements of objects in the scene are governed by movement equations, as indicated by block 400.
  • the word object is understood in a broad sense and includes characters (or "avatars") or vehicles. It designates a computer object (set of values and / or functions), capable of allowing the representation on the screen of a corresponding virtual physical object.
  • the reference to computer objects does not necessarily imply programming by objects.
  • Block 402 detects possible collisions between two objects X and Y.
  • block 404 "solves" these collisions, that is to say deals with temporary changes to the equations of motion that are due to the collision, as for objects X and Y.
  • the positions of the X and Y objects (406) are converted into display parameters (408), which are used for the display (410).
  • the positions obtained for X and Y after its resolution are directly applied to block 408 to derive display parameters.
  • the collision resolution (303) is processed with a rougher mesh than that of the collision detection (302), which itself is processed with a mesh coarser than the display resolution. .
  • This collision detection can be standard.
  • the collision resolution depends on the characteristics of the game concerned.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Theoretical Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Processing Or Creating Images (AREA)

Abstract

Un système de jeu électronique comprend plusieurs ordinateurs de jeu connectés en réseau avec un système serveur central, ainsi qu'un serveur de temps réseau. Chaque ordinateur exécute 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, et l'instance client comprend une correspondance entre des événements et des données de temps. En présence d'un événement utilisateur muni d'une telle correspondance, l'ordinateur de jeu émet 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 exécute 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.

Description

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 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 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 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.
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.
Pour se trouver interconnecté avec de nombreux autres joueurs, un joueur donné, par exemple Pl, 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.
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 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 AI l 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 AI l.
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.
II 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 variation de la latence et ses conséquences sur le synchronisme du jeu. Si par exemple un guerrier fait une manœuvre 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 manœuvre.
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 œuvre de jeux 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 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 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.
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 Pl, sur son poste avec son instance client CIi 1, a déclenché une action EVENT, par exemple à la souris ou sur manette de jeu. A l'opération 202, il s'ensuit le calcul d'un instant ou temps d'action T act, é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 T act. Puis l'opération 208 attend l'instant T act, avant d'effectuer pour le joueur local Pl, sur son poste CIi 1, l'action EVENT. Ceci est représenté par une fonction Do(event, CIi 1), à l'opération 210.
On revient à l'opération 204, qui est représentée par une fonction Call_Serv(Event, T act, CIi 1). Le passage de CIi 1 comme paramètre indique que le client CIi 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 Pl. On suppose ici qu'il s'agit d'un joueur ayant un poste avec son instance client Cli2.
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, T_act, CHl) qui transmet les paramètres d'action aux clients déterminés dans l'opération 220.
En 230, le poste CH2 reçoit du serveur un message indiquant l'action EVENT et le temps T act. Cette réception intervient à l'instant T rec. En 232 est calculé l'écart T_prep entre T act et Tjrec. 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'à T act, avant l'opération 238, qui est l'exécution de la fonction Do(event, CIi 1) sur le client Cli2, de manière homologue à la fonction Do(event, CIi 1) de l'opération 210, au sens des interactions dans le jeu. 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 T act.
S'agissant par exemple d'un jeu de tennis à deux joueurs Pl et P2, et en admettant que le joueur Pl commande une frappe de balle par sa raquette RPl :
- l'exécution locale de la frappe sur le poste CHl de Pl, 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 CH2 de P2 dans les 100 millisecondes, le mouvement de la raquette de Pl sur le poste CH2 est le même que sur le poste CIi 1.
- si l'information arrive au poste CH2 de P2 après les 100 millisecondes, mais avant la fin du mouvement de la raquette de Pl, alors ce mouvement est produit sur le poste CH2, mais accéléré. Ce mouvement peut être accéléré pour se terminer en même temps que sur le poste CIi 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 CH2 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 parallèlement à l'exécution du jeu,
- lorsqu'un client récepteur, par exemple le client CH2 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 CIi 1 dans l'exemple de la figure 2, - parallèlement, le client récepteur (Cli2) envoie un message au client émetteur (CHl) pour lui indiquer qu'il a distordu son échelle locale de temps,
- le client émetteur (CIi 1) 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 correspondant au client émetteur (CIi 1 ), et
- le client émetteur (CIi 1) 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 (Pl), trois moteurs (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).
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, 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é.

Claims

Revendications
1. Système de jeu électronique dans lequel plusieurs ordinateurs de jeu (P 1..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 exécutant 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 émet 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 exécute 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 réalise sa préparation pendant le délai défini par la donnée de temps (208), tandis que l'ordinateur distant réalise 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 réalise 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, caracté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 traitée avec un 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.
6. Système de jeu électronique selon l'une des revendications 4 et 5, caractérisé en ce que le moteur de détection de collision est utilisé en commun par une partie au moins des fonctions sur événements du jeu.
PCT/FR2008/001433 2007-10-19 2008-10-13 Système de jeu informatique en ligne avec gestion de la latence. WO2009087294A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0707344A FR2922463B1 (fr) 2007-10-19 2007-10-19 Systeme de jeu informatique en ligne avec gestion de la latence
FR0707344 2007-10-19

Publications (2)

Publication Number Publication Date
WO2009087294A2 true WO2009087294A2 (fr) 2009-07-16
WO2009087294A3 WO2009087294A3 (fr) 2009-09-03

Family

ID=39387659

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2008/001433 WO2009087294A2 (fr) 2007-10-19 2008-10-13 Système de jeu informatique en ligne avec gestion de la latence.

Country Status (2)

Country Link
FR (1) FR2922463B1 (fr)
WO (1) WO2009087294A2 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111135580A (zh) * 2019-12-26 2020-05-12 珠海金山网络游戏科技有限公司 一种游戏角色待机动画生成方法及装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1996025989A2 (fr) * 1995-02-24 1996-08-29 Velocity, Inc. Procede et appareil permettant de reduire au minimum l'impact des retards sur les reseaux informatiques
WO1998014886A1 (fr) * 1996-09-30 1998-04-09 Sandcastle, Inc. Synchronisation d'evenements survenant sur un reseau en presence de temps de latence
US20060149516A1 (en) * 2004-12-03 2006-07-06 Andrew Bond Physics simulation apparatus and method

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1996025989A2 (fr) * 1995-02-24 1996-08-29 Velocity, Inc. Procede et appareil permettant de reduire au minimum l'impact des retards sur les reseaux informatiques
WO1998014886A1 (fr) * 1996-09-30 1998-04-09 Sandcastle, Inc. Synchronisation d'evenements survenant sur un reseau en presence de temps de latence
US20060149516A1 (en) * 2004-12-03 2006-07-06 Andrew Bond Physics simulation apparatus and method

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111135580A (zh) * 2019-12-26 2020-05-12 珠海金山网络游戏科技有限公司 一种游戏角色待机动画生成方法及装置
CN111135580B (zh) * 2019-12-26 2024-03-19 珠海金山数字网络科技有限公司 一种游戏角色待机动画生成方法及装置

Also Published As

Publication number Publication date
WO2009087294A3 (fr) 2009-09-03
FR2922463A1 (fr) 2009-04-24
FR2922463B1 (fr) 2010-03-26

Similar Documents

Publication Publication Date Title
US10967276B2 (en) Collaborative online gaming system and method
CA2459694C (fr) Partage de donnees coherentes
US8069258B1 (en) Local frame processing to apparently reduce network lag of multiplayer deterministic simulations
US6050898A (en) Initiating and scaling massive concurrent data transaction
Bettner et al. 1500 archers on a 28.8: Network programming in Age of Empires and beyond
US9238174B2 (en) Method and apparatus for virtual location-based services
US6641481B1 (en) Simplified matchmaking
JP4411125B2 (ja) ユーザにゲームを提供する方法
US20070063999A1 (en) Systems and methods for providing an online lobby
US20030177187A1 (en) Computing grid for massively multi-player online games and other multi-user immersive persistent-state and session-based applications
CN113262481B (zh) 游戏中的互动方法、装置、设备及存储介质
US9032022B1 (en) Sending and receiving configurable buckets of communications
WO2004102885A1 (fr) Procede de representation d'une image virtuelle sur un dispositif de messagerie instantanee
WO2009087294A2 (fr) Système de jeu informatique en ligne avec gestion de la latence.
US20180353853A1 (en) Systems and methods for mass user multi input control of a common display
CN106953933B (zh) 一种消息推送方法及装置、电子设备
JP2002153677A (ja) 情報端末、情報提供サーバ、オンラインゲーム方法および記録媒体
Claypool Network characteristics for server selection in online games
Bangun et al. Modelling multi-player games traffic
KR20020059280A (ko) 멀티 플레이용 경품 게임 서비스 방법
Powers et al. DEE: An architecture for distributed virtual environment gaming
WO2001031476A1 (fr) Procede et systeme de realisation d'un jeu qui se pratique a tour de role
JP2002210254A (ja) ビデオゲームプログラム、敵キャラクタダメージ量算出方法、ゲームシステム及びゲームサーバ
Trinta et al. Evaluating a middleware for crossmedia games
US20020062386A1 (en) Method and apparatus for improving real time and/or interactive animation over a computer network

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08869298

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08869298

Country of ref document: EP

Kind code of ref document: A2