Brevet FR2922119A1 — publié le 20090417

F4_1.FRD.doc Jeu informatique intégrant un navigateur. L'invention concerne les dispositifs de jeu électronique. Ces dispositifs se présentent aujourd'hui de diverses manières, qui vont de l'ordinateur fixe ou portable au téléphone mobile évolué, en passant par la console de jeu. On peut considérer que, génériquement, le coeur du dispositif de jeu est un système hôte, avec un périphérique d'entrée utilisateur (ou son contrôleur), un contrôleur d'écran et un module de jeu, l'écran lui-même étant ou non séparé. Dans les dispositifs connus, le module de jeu est agencé pour interagir avec le contrôleur d'écran afin de gérer une fenêtre d'affichage dédiée au jeu sur l'écran. Parmi les jeux les plus populaires, on connaît ceux du type dit "jeu massivement multijoueurs 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. Pour mettre en oeuvre le jeu, le système hôte de l'utilisateur charge un programme exécutable comprenant les fonctions internes de jeu, ainsi que des fonctions de communication avec la plateforme centrale, pour fournir les fonctions distantes. Ainsi se trouve défini un univers pour le jeu, entre les différents joueurs interconnectés. Cet univers est "fermé", en ce sens qu'il est entièrement défini par le programme de jeu. Cette limitation peut être considérée comme indésirable, au moins dans certains cas. La présente invention vient améliorer la situation. La Demanderesse a observé que la situation s'améliore si l'on prévoit des fonctions réseaux supplémentaires, en particulier des fonctions de navigation, incorporées au programme exécutable que contient le module de jeu. Cela rend possible des fonctions de jeu "externes", qui font appel au navigateur à différentes fins, dont par exemple celle de faire évoluer des objets dans le jeu, comme les vêtements d'un personnage. Ainsi, selon un aspect de l'invention, le module de jeu est capable, en réponse au lancement d'au moins une fonction de jeu externe, de gérer une sous-fenêtre dans la fenêtre générale de jeu. La gestion de cette sous-fenêtre comporte un accès au réseau. Et il est prévu au moins une structure de données spécifique, propre à l'échange de données entre des opérations réseau et une ou des fonctions de jeu. Selon un autre aspect de l'invention, le module de jeu comprend, pour la gestion de la sous-fenêtre, un sous-module capable d'effectuer des opérations réseau à la manière d'un navigateur réseau, et coopérant par exemple avec un gestionnaire d'affichage de la sous-fenêtre. 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 illustre la structure générale d'un système hôte de jeu connu, La figure 2 illustre la structure d'un dispositif ici proposé, La figure 3 est un diagramme de flux illustrant une partie du fonctionnement du 20 dispositif proposé, et La figure 4 est un diagramme de flux illustrant une autre partie du fonctionnement du dispositif proposé. Les dessins et la description ci-après contiennent, pour l'essentiel, des éléments de 25 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. Le dispositif représenté sur la figure 1 comporte une unité centrale 10, associée à un contrôleur graphique 11, et comportant une mémoire 20 susceptible de comprendre un 30 ou des programme(s) et notamment un module de jeu. L'unité centrale 10 est interconnectée à une interface physique de réseau 12, qui donne accès un réseau étendu 90, tel que le réseau Internet. Le contrôleur graphique 11 est prévu pour coopérer avec un système d'écran 30, du genre moniteur à tube cathodique, écran plan, ou analogue. Ce dispositif peut servir de système hôte d'un jeu, côté joueur. Dans un jeu informatique classique, le programme de jeu contenu dans la mémoire 20 coopère avec l'unité centrale de sorte que le contrôleur graphique affiche sur l'écran 30 une image ou une vidéo, à destination de l'utilisateur, en l'occurrence le joueur. L'unité centrale 10 est associée à des périphériques d'entrée ou d'entrée/sortie 15, tels qu'un clavier, une souris, des manettes de jeu ou autres. Ils permettent au joueur d'interagir avec le système hôte (informatiquement), en donnant l'impression d'une interaction avec les images affichées sur l'écran 30. Ces images peuvent être considérées comme au moins partiellement virtuelles : ce sont par exemple des images virtuelles où se déplacent un/ou des personnages virtuels, ou bien des images réelles (d'archive) incorporées au jeu, et dans lesquelles se déplacent le ou les personnages virtuels. Dans les jeux en réseau massivement multi-joueurs, le logiciel de jeu n'est pas uniquement logé sur le système hôte local 1 de la figure 1. Une partie du jeu est logée à distance sur une plateforme centrale 99 (un groupe de serveurs centraux), avec laquelle interagissent également d'autres joueurs. Le système hôte local peut se trouver confiné à la partie qui intéresse directement le joueur local, notamment : afficher avec un graphisme de qualité une image correspondant à la zone du jeu où se trouve le joueur local, ou qui l'intéresse, afficher le cas échéant l'avatar (personnage) qui représente le joueur lui-même, définir les actions du joueur selon ses commandes sur les périphériques d'entrée, en transmettant ces actions au serveur de jeu distant, et en reflétant ces actions dans l'image locale, si nécessaire, afficher une interface d'accès à certains services du jeu, comme le classement des joueurs, ou l'inventaire des objets possédés par un joueur. C'est ainsi que, de façon générale, on construit un jeu en réseau massivement multijoueurs. Une description plus détaillée de la structure générale et de la réalisation de tels jeux peut être trouvée dans différents ouvrages, par exemple "Massive Multiplayer Game Development", produit par Thor Alexander, Charles River Media Inc., volume 1 (ISBN 1-58450-243-6) et volume 2 (ISBN 1-58450-390-4). La figure 2 reprend les éléments de la figure 1, sauf l'unité centrale 10, l'interface réseau 5 physique 12, et le ou les périphériques d'entrée ou d'entrée/sortie 15, qui restent présents, mais ne sont pas représentés pour alléger le dessin. Le module de jeu peut être décrit généralement comme possédant une procédure principale 210, qui interagit avec des fonctions de jeu 212 et 214. Pour des raisons que 10 l'on comprendra plus loin, on distinguera ici des fonctions de jeu internes 212 et une ou des fonctions de jeu externes 214. De façon générale, les fonctions de jeu interagissent directement ou indirectement avec un gestionnaire d'une fenêtre de jeu 231. A travers le contrôleur graphique 11, le 15 gestionnaire d'une fenêtre de jeu 231 produit une fenêtre d'affichage 31 dédiée au jeu proprement dit, sur l'écran 30. Cette fenêtre d'affichage du jeu est parfois définie informatiquement comme une sous-fenêtre incluse dans une fenêtre générale, gérée par le module de jeu 20. 20 Classiquement, une interface de réseau "dans le jeu" 209 (une interface logicielle interne au module de jeu 20) travaille avec la procédure principale 210 et/ou les fonctions de jeu 212, pour permettre l'interaction avec le serveur distant, aux fins que les fonctionnalités du jeu soient complètes, et que se manifeste l'interaction entre de multiples joueurs distants les uns des autres. 25 Dans le cadre de l'exemple décrit ici, l'interface 209 encapsule des communications émises par la procédure principale 210 et/ou les fonctions de jeu 212 selon le protocole Internet, et les envoie à la plateforme 99 sur un port de destination déterminé à l'avance. 30 Afin d'assurer la protection de ces communications, le port de communication est choisi pour ne pas interférer avec d'autres communications bien connues, comme les ports dédiés aux communications SMTP, FTP ou autres, ainsi que des ports de certains réseaux pair à pair, qui sont notoirement bloqués par les fournisseurs d'accès. D'autre part, les données dans les communications encapsulées sont sérialisées et le 5 traitement d'erreur dans les paquets de données est classique des jeux massivement multi-joueurs en ligne. Ici, le module de jeu 20 comprend de manière interne un organe de traitement de fonctions réseau 290, tel qu'un navigateur Internet simplifié. Le navigateur 290 est 10 interconnecté avec l'interface de réseau 209. Il est également prévu un second gestionnaire de fenêtre 232. A travers le contrôleur graphique 11, le second gestionnaire de fenêtre 232 anime une seconde sous-fenêtre 32 à l'intérieur de la fenêtre principale 30, ou si l'on préfère de l'écran 30. (Le gestionnaire 15 de fenêtre 232 est vu ici comme séparé du premier gestionnaire 231 pour la clarté de l'exposé ; mais ces deux gestionnaires peuvent être réunis en un seul sous-module, et/ou posséder des fonctions communes, en tout ou en partie). La Demanderesse a observé que l'interface interne de réseau 209 peut être aménagée 20 pour travailler aussi pour le navigateur 290. Cela est rendu possible en paramétrant l'interface interne de réseau 209 pour traiter les ports d'émission du navigateur 290. Dans l'exemple décrit ici, le navigateur 290 émet et reçoit sur le port 80. Ce navigateur Internet 290 est prévu pour établir, à certains moments du déroulement de 25 la navigation, un objet informatique conforme à une structure de données spécifique 221, qui est ici en rapport avec les fonctions du jeu. Et les fonctions "externes" de jeu 214 sont munies de procédures ou sous-procédures susceptibles d'appeler le navigateur 290, au besoin avec un ou des paramètre(s), tout en 30 attendant en retour une structure de données 219 qui comprend tout ou partie de la structure de données spécifique 221. Pour assurer la transition entre la structure de données 219 et 221, on peut prévoir un convertisseur 220. Dans un exemple particulier, la structure de données spécifique est montrée avec 5 l'exemple de code informatique de l'Annexe A. L'Annexe A se place dans l'exemple d'une fonction dans le jeu qui incrémente un compteur et qui communique avec une fenêtre d'affichage de page Web pour afficher ce compteur. Pour permettre l'interaction avec le module de jeu, la page Web affichée comporte un script en JavaScript qui est référencé Al dans l'Annexe A. D'une manière générale, ce script : 15 - s'initialise (Ail) et récupère des variables d'initialisation (Al2, A13) ; - teste si la page Web peut correctement interagir avec le module de jeu (A14, A15) ; - le cas échéant appelle une fonction GetToto qui incrémente un compteur, et affiche ce compteur (A16) ; et - se termine (A17). 20 Ce script interagit avec une portion de code en langage de script LUA du module de jeu qui est référencé A2 dans l'Annexe A. Cette portion de code effectue les opérations suivantes : 25 - elle initialise le compteur comme variable globale (A21) ; - elle définit la fonction GetToto( (A22), qui incrémente l'indice i (A23) et retourne la chaîne de caractère "toto" i (A24) et se termine (A25) ; et - elle définit la fonction function(sender) (A26) qui détermine l'élément émetteur (A27), la fenêtre associée à cet élément (A28), et le navigateur associé (A29) pour lui indiquer 30 l'URL à charger (A30) avant de se terminer (A31). 10 Comme on le voit avec l'exemple qui précède, la structure de données partagées repose sur des variables qui peuvent être accédées par des fonctions lancées par des actions détectées au sein de la page Web affichée, par exemple au moyen d'un script JavaScript. Le navigateur 290 n'a pas besoin d'être un navigateur complet. Il peut être limité aux fonctions suivantes d'un navigateur : - Accès Internet, -Traitement HTML, - Support de commandes dans un langage de script, tel que JavaScript, ou FLASH. 10 Dans un mode de réalisation particulier, les appels des fonctions externes 214 sont restreints à des sites désignés prédéfinis, qui peuvent alors répondre directement, d'une manière conforme à la structure de données spécifique 221. 15 Ces appels au navigateur peuvent être induits par une entrée utilisateur, ou bien directement inclus dans des fonctions du jeu. La figure 3 représente un diagramme de flux qui illustre l'appel d'une fonction externe et le traitement de cet appel par le dispositif de la figure 2. Lorsque le joueur joue au jeu, il est amené à faire appel à une fonction externe (opération 300). Cela est par exemple le cas dans un jeu massivement multi-joueurs en ligne lorsque le joueur souhaite consulter son inventaire. 25 Dans l'exemple décrit ici, l'appel de la fonction externe entraîne le lancement du navigateur 290 avec une URL (adresse Internet) qui est associée à cette fonction (opération 302). Typiquement, dans le cas décrit plus haut, le lancement de la fonction "inventaire" 30 appelle le navigateur 290 avec une URL qui correspond à une adresse Internet gérée par la plateforme 99, et contient également un identifiant du joueur. 20 Sur la plateforme 99, cette URL est reliée à une fonction de la plateforme 99 qui est propre à récupérer les données d'inventaire d'un joueur donné, et elle réalise cette opération avec l'identifiant qui a été fourni. En retour, la plateforme 99 renvoie au navigateur 290 une page Web associée à l'URL consultée, et le navigateur 290 coopère avec le gestionnaire de fenêtre 232 pour afficher une fenêtre 32 qui affiche le contenue de la page Web reçue. Dans le cadre de l'exemple décrit plus haut, le navigateur 290 reçoit une page Web qui contient une description de l'inventaire du joueur. Le navigateur 290 appelle alors des fonctions du gestionnaire 232 qui convertissent les données HTML de la page Web en instructions permettant l'affichage de la fenêtre 32 dans la fenêtre 30. La situation n'évolue pas tant qu'aucune action n'est réalisée dans la fenêtre 32, c'est-à-15 dire que l'affichage de celle-ci n'évolue pas (opération 306). Lorsque le joueur effectue une action de navigation (car elle est en rapport avec la fenêtre 32 dépendant du navigateur 290), le navigateur 290 appelle le convertisseur 220 (opération 308). Le convertisseur 220 a pour fonction de transformer d'action de navigation depuis le format de la page Web, c'est-à-dire selon la structure 221, vers le format de la procédure principale 210, c'est-à-dire selon la structure 219. 25 Une fois les données transformées, la fonction externe collabore avec le gestionnaire 231 pour modifier la fenêtre 31 de manière à refléter l'action indiquée par les données transformées (308). Dans l'exemple décrit plus haut, il est possible que la page Web reçue contienne par exemple du code JavaScript, qui permet une interaction locale dans le navigateur, par 30 exemple pour changer les vêtements de l'avatar qui sont affichés dans la fenêtre d'inventaire. 20 Dans ce cas, un clic sur ces vêtements crée un appel du convertisseur 220 pour transférer les données de JavaScript vers le langage de la procédure principale 210, ce qui a pour conséquence : - l'affichage dans la fenêtre 31 du changement de vêtement de l'avatar, et - l'envoi à la plateforme 99 d'un message indiquant le changement de vêtement par la fonction externe liée à l'inventaire. De nombreuses autres possibilités apparaîtront directement à l'homme du métier au-delà de cet exemple simple. L'opération 308 et 310 sont répétées pour chaque action de navigation tant que la fonction externe n'est pas terminée (opération 312). Une fois la fonction terminée, les objets créés localement pour la fonction externe sont supprimés, comme par exemple la fenêtre 32 (opération 314). 15 La figure 4 montre un autre exemple dans lequel une fonction interne va interagir avec une fenêtre liée à une fonction externe. Lorsque le joueur exécute certaines actions dans la fenêtre 31, celles-ci peuvent 20 entraîner l'appel d'une fonction interne (opération 400). Sur appel de la fonction interne, la procédure principale 210 appelle l'interface 209 pour communiquer avec la plateforme 90 et exécuter une fonction voulue (opération 402). 25 Si l'on continue l'exemple commencé avec la figure 3, une telle action peut par exemple être l'abandon d'un objet d'inventaire donné, ou son acquisition. Dès lors, une fonction interne est appelée pour signifier à la plateforme 90 que l'inventaire du joueur a été modifié. 30 Une fois que la plateforme 90 a traité la requête de la fonction interne, elle renvoie au joueur une réponse reflétant ce traitement, et la fonction interne collabore avec le10 gestionnaire 231 pour refléter la modification correspondante dans la fenêtre 31 (opération 404). Cependant, il est possible que la modification qui a eu lieu impacte également une autre 5 fenêtre affichée dans la fenêtre 30 (opération 406). Pour tenir compte de ce changement, la fonction interne appelle alors une procédure pour rafraîchir la fenêtre 32 impactée (opération 408). 10 La fenêtre 32 est affichée avec une page Web rafraîchie (opération 410), c'est-à-dire affichant des données tenant compte des modifications susmentionnées. Une fois la fonction terminée, les objets créés localement pour la fonction externe sont supprimés (opération 414). 15 Les opérations 408 et 410 peuvent être réalisées de plusieurs manières : - la fonction interne peut appeler directement le navigateur 290 qui peut rafraîchir la fenêtre 32 en rappelant l'URL associée ; - la fonction interne peut appeler la fonction externe reliée à la fenêtre 32 impactée, et la fonction externe peut à son tour appeler le navigateur 290 qui peut rafraîchir la 20 fenêtre 32 en rappelant l'URL associée ; - la fonction interne peut collaborer directement avec le gestionnaire 232 pour modifier la fenêtre 32 ; et - la fonction interne peut appeler la fonction externe pour collaborer avec le gestionnaire 232 pour modifier la fenêtre 32. 25 La description qui précède a pour but de décrire un mode de réalisation particulier de l'invention. Elle ne saurait être considérée comme limitant ou décrivant celle-ci de manière limitative, et couvre notamment l'ensemble des combinaisons entre elles des caractéristiques des variantes décrites. Par ailleurs, bien que l'invention ait été décrite de manière particulière en rapport avec un jeu massivement multi-joueurs en ligne, elle s'étend aux jeux en ligne en général. 30 L'invention couvre également, en tant que produits, les éléments logiciels décrits, mis à disposition sous tout "medium" (support) lisible par ordinateur. L'expression "medium lisible par ordinateur" comprend les supports de stockage de données, magnétiques, optiques et/ou électroniques, aussi bien qu'un support ou véhicule de transmission, comme un signal analogique ou numérique. ANNEXE A Al A 11 Al2 var embed = document.getElementByld('IWP'); A13 var initDiv = document.getElementByld('init'); A14 if( embed.exec) { initDiv.innerHTML = 'IWP OK'} A15 else { initDiv.innerHTML = 'IWP flot OK'} A16 if( embed.exec) { var toto = embed.exec( "GetToto" ) var totoDiv = document.getElementByld( "toto" ) totoDiv.innerHTML = toto} A 17 �/script> A2 A21 local i = 0 A22 function GetToto() A23 i = i + 1 A24 Ireturn "toto " .. i A25 {end A26 ireturn function( sender ) A27 (local root = sender.Root A28 local container = root:FindParent( "BrowserContainer", sender ) A29 local browser = root:Find( "Browser", container ) A30 lbrowser:SetUrl( "Tests/Extended/IWP.html" ) A31 end Revendications 1. Appareil de jeu électronique comportant un système hôte (10, 12), avec un contrôleur (11) d'écran et un module de jeu (20), le module de jeu (20) étant agencé pour interagir avec le contrôleur d'écran (11) afin de gérer une fenêtre générale de jeu (30) sur l'écran, avec un affichage (31) pour le jeu, le module de jeu comprenant une pluralité de fonctions internes de jeu (212), susceptible d'être lancées par une action utilisateur, caractérisé en ce que le module de jeu (20) est capable, en réponse au lancement d'au moins une fonction externe (214), de gérer une sous-fenêtre (32) dans ladite fenêtre générale de jeu (30), cette gestion comportant un accès au réseau (290), tandis qu'il est prévu au moins une structure de données (219 ; 221) propre à l'échange de données entre des opérations réseau (290) et une ou des fonctions de jeu (214). 2. Appareil selon la revendication 1, caractérisé en ce que le module de jeu (20) comprend un sous-module (290) capable d'effectuer des opérations réseau à la manière d'un navigateur réseau, et coopérant avec un gestionnaire (232) de la sous-fenêtre (32). 3. Appareil selon la revendication 2, caractérisé en ce que le sous-module (290) opère pour fournir des données issues de la navigation selon une structure de données générique. 25 4. Appareil selon la revendication 3, caractérisé en ce qu'il est prévu une fonction réseau-vers-jeu, capable de transformer la structure de données générique en un retour de données au format voulu par la fonction de jeu appelante (214). 5. Appareil selon l'une des revendications précédentes, caractérisé en ce qu'une 30 zone activable peut être associée à la fenêtre générale ou à une ou plusieurs des sous-fenêtres d'affichage.20 6. Appareil selon l'une des revendications précédentes, caractérisé en ce que le module de jeu est prévu comme un seul fichier exécutable. 7. Appareil selon la revendication 6, caractérisé en ce que des fonctions 5 internes du jeu comportent également un accès au réseau, en particulier pour l'interaction avec d'autres joueurs. 8. Appareil selon la revendication 7, caractérisé en ce qu'il est appliqué à un jeu massivement multi-joueurs en ligne.