FR 2922120 A1 20090417 FR 0707239 A 20071016 F4_2.FRD.doc Système serveur de jeux informatiques en ligne. L'invention concerne les systèmes de jeu électronique. 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 serveur de jeu, dans le cadre d'un réseau étendu, tel qu'Internet. La plateforme centrale de serveur de jeu sera par la suite appelée système central de serveur. Le bon fonctionnement de ce système central est manifestement primordial. Toute répétition d'incidents imputables à ce système central peut se traduire par un rapide désintérêt du jeu, qui s'amplifie très vite, du fait que l'attrait du jeu est largement lié au grand nombre de joueurs qui y sont actifs. Ce système central de serveurs de jeux doit donc satisfaire des contraintes informatiques sévères, notamment en termes de niveau de charge des différents matériels du système. Dans les réalisations actuelles, le monde (en principe l'univers virtuel du jeu) est 20 découpé en secteurs géographiques découplés les uns des autres, avec chacun leur système serveur de jeu. Et, dans un système serveur de jeu donné, chaque machine est dédiée à un jeu donné. En présence d'un nouveau joueur entrant dans un jeu ("impétrant"), les paramètres de la décision sont : un système selon le secteur géographique ; dans celui-ci, la machine parmi celles qui sont dédiées au jeu demandé ; 25 et un identifiant d'une instance de jeu créée pour cet impétrant, sur cette machine. Les mécanismes de décision pour affecter un impétrant à une machine sont donc relativement simples. En revanche, si l'on considère globalement l'ensemble des machines des différents serveurs géographiques, l'équilibrage de charge entre ces 30 machines est généralement imparfait, voire médiocre. La présente invention vient améliorer la situation.15 Elle part d'un système serveur de jeu électronique, du type comportant, sur un site, une unité de connexion à un réseau ouvert, et une pluralité d'ordinateurs agencés pour exécuter des instances de jeu sur demande de joueurs, à travers l'unité de connexion. Selon un aspect de l'invention, certains au moins des ordinateurs de ladite pluralité sont des machines de calcul dénuées de toute application au repos. Le système comporte en outre un stockage d'au moins une image de programme de jeu exécutable sur au moins une des machines. L'unité de connexion comprend un serveur principal de jeu, capable, en réponse à une demande d'accès à un jeu : d'y affecter l'une des machines de calcul sur la base d'une évaluation de la charge des machines de calcul, de créer pour le nouvel accédant une instance du jeu sur la machine affectée ; et de gérer l'interaction réseau entre la machine affectée et le nouvel accédant. Dans des modes de réalisation particuliers le système présente les caractéristiques suivantes : * lorsque la machine affectée ne contient pas une image du jeu, le serveur principal appelle le stockage pour implanter sur la machine affectée une image de jeu exécutable convenant pour cette machine affectée, puis crée une nouvelle instance du jeu sur cette machine ; * lorsque la machine affectée contient une image du jeu, le serveur principal y crée directement une nouvelle instance du jeu ; * l'affectation d'une machine de calcul est en outre basée sur des paramètres liés au joueur émettant la demande d'accès au jeu ; et * le système est appliqué à un jeu massivement multi-joueurs en ligne. L'invention concerne également un procédé de gestion d'informatique distante, dans un site comprenant une unité de connexion à un réseau ouvert, et une pluralité de machines de calcul dénuées de toute application au repos et agencées pour exécuter des instances de jeu à travers l'unité de connexion sur demande de joueurs, ainsi qu'un stockage d'au moins une image de programme de jeu exécutable sur au moins une des machines. Ce procédé comprend les étapes suivantes : a. la réception demande d'accès à un jeu par un joueur, b. la création d'une instance de jeu, avec b1. affecter une des machines de calcul à l'instance associée à la demande 5 d'accès, sur la base d'une évaluation de la charge des machines de calcul, et b2. créer une instance de jeu sur la machine affectée, c. la gestion de la connexion entre le joueur et l'instance de jeu. Dans des modes de réalisation particuliers le procédé présente les caractéristiques 10 suivantes : * l'étape b2. comprend, lorsque la machine affectée ne contient pas une image du jeu, l'appel du stockage pour implanter sur la machine affectée une image de jeu exécutable convenant pour cette machine affectée, et la création de l'instance de jeu sur la base de cette image ; 15 * l'étape b2. comprend, lorsque la machine affectée contient une image du jeu, la création directe d'une nouvelle instance du jeu ; * l'évaluation de l'étape bl. est en outre basée sur des paramètres liés au joueur émettant la demande d'accès au jeu ; *le procédé est appliqué à un jeu massivement multi-joueurs en ligne. 20 D'autres caractéristiques et avantages de l'invention apparaîtront mieux à 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 le principe général d'un jeu massivement connecté, La figure 2 illustre la structure général d'un serveur de jeu selon la présente 25 invention, La figure 3 est le schéma-bloc d'une architecture informatique de serveurs actuellement préférée pour la mise en oeuvre de l'invention, La figure 4 est un schéma-bloc simplifié, illustrant le fonctionnement des serveurs jeu pour un joueur déjà connecté, 30 La figure 5 est un schéma-bloc simplifié, illustrant les étapes de communication entre un joueur et le système central dans le cadre de la figure 4, La figure 6 est un schéma-bloc simplifié, illustrant les étapes de création d'une instance de jeu sur requête d'un joueur, et La figure 7 est un schéma-bloc détaillant une étape de la figure 6. 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 10 NET à un serveur central de jeu CGS. Chaque joueur possède dans son appareil les "fonctions locales" de jeu, et des fonctions de communication propres au jeu. 15 Pour se trouver interconnecté avec de nombreux autres joueurs, il doit d'abord s'inscrire sur le serveur central, en fournissant un identifiant et un mot de passe. Une instance du jeu est alors créée pour lui. Elle le représente parmi les instances de jeu respectives de nombreux autres joueurs. 20 Les interactions entre les joueurs, ainsi qu'avec leur environnement dans le jeu, sont déterminées par des échanges d'informations entre les joueurs et le serveur central, lequel se charge également de mettre en oeuvre les "fonctions distantes" du jeu qui sont relatives à ces interactions. 25 Tout cela doit fonctionner en temps réel. Et il est à exclure que le jeu ne se bloque pour l'une quelconque des causes qui peuvent entraîner la saturation des machines : trop de tâches à effectuer simultanément pour les joueurs connectés, trop de joueurs pour pouvoir en admettre de nouveaux, panne de machines, etc. 30 Comme déjà indiqué, dans les réalisations actuelles, le monde (en principe l'univers virtuel du jeu) est découpé en secteurs géographiques découplés les uns des autres, avec chacun leur serveur de jeu. Autrement dit, on alloue a priori les zones géographiques de l'univers du jeu et les utilisateurs à des serveurs centraux distincts. Par serveur central distinct, on entend une plateforme centrale qui peut comporter une ou plusieurs machines jouant le rôle de serveur. Plus techniquement, si un joueur est dans une "zone géographique de l'univers du jeu", cela signifie : que ce joueur n'a besoin que d'un sous ensemble restreint de l'ensemble des fonctions distantes du jeu ; qu'il n'interagit qu'avec le sous-ensemble des joueurs qui sont dans la même 10 situation. Il en résulte différents inconvénients. Un serveur central ne traite qu'un sous-ensemble des fonctions distantes du jeu. Il n'y a 15 aucune raison que ce découpage par zones géographiques soit équilibré, en termes de charge, c'est-à-dire de services à rendre aux joueurs. Autrement dit, il faut prévoir chaque serveur central de jeu pour la charge maximale. Il y a donc toutes chances que, globalement l'ensemble des serveurs centraux de jeu soit mal utilisé, certains étant en sous-charge, et d'autres très chargés. 20 De plus, pour éviter que trop de joueurs soient dans un espace trop restreint, il peut être nécessaire de créer plusieurs instances d'un même monde, ces instances étant indépendantes les unes des autres. 25 Dès lors, les joueurs qui sont affectés à une instance d'un monde ne "voient" pas les joueurs affectés à une autre instance de r ,e monde, et vice versa. Ce découpage introduit une restriction handicapante quant à l'universalité du jeu, puisque des joueurs sont ainsi amenés à ne jamais se rencontrer. 30 La demanderesse s'est attachée à trouver une meilleure solution. On en décrira maintenant le principe général en référence à la Figure 2. Cette figure fait apparaître n joueurs P1, ... Pi, ... Pn. Comme le sait l'homme du métier, l'interaction des joueurs avec un serveur central, qui se produit via Internet (par exemple), peut être représentée sous la forme d'une commutation SW. L'invention prévoit un serveur central comprenant des machines (ordinateurs) de calcul indifférenciées Ml, ..., Mj ... Mp. Une ou des machines de synchronisation MS, sont munies de mécanismes de décision qui permettent d'affecter un utilisateur à une machine indifférenciée particulière. Chaque machine Mj peut mettre en oeuvre l'un des programmes de jeu (G1, G2), hébergés sur une machine serveur de programmes de jeu GPS, en fonction des besoins définis et indiqués par la ou les machines de synchronisation. Les machines Mj sont reliées à un ensemble DPPC qui est utilisé pour stocker les données persistantes des joueurs. Cet ensemble peut être réalisé de diverses manières, dont une est décrite avec la figure 3. La Figure 3 illustre l'architecture actuellement préférée pour un système serveur central selon l'invention. Elle se lira de haut en bas. A l'entrée du serveur, la commutation d'entrée SW1 se répartit sur un ou plusieurs pare- 20 feux SW1_1, ... SW1_q. Un joueur, par exemple Pi, se trouve ici pris en charge par le pare-feu SW1_q. Les pare-feux sont des éléments bien connus de l'homme du métier qui permettent de contrôler le trafic entrant et sortant d'un réseau. Des fonctions d'équilibrage de charge sont prévues en LB_1, LB_2, L13_3. De 25 préférence ces fonctions sont prévues sur les machines de synchronisation MS. L'équilibrage de charge, sur lequel on reviendra, comprend ici la répartition du trafic de jeu entre les pare-feux SW1 et des commutateurs ("switch" en anglais) SW2, tels que SW2_1 et SW2_2. 30 Les machines de calcul indifférenciées sont ici agencées en quatre grappes ("clusters") de machines interconnectées. Ces grappes sont avec redondance et/ou haute disponibilité.15 Une première grappe comprend des machines ou noeuds tels que N11 à N14, avec un commutateur amont SW3 1, et un commutateur aval SW4_1. Les commutateurs SW2 permettent d'acheminer le trafic vers et depuis la première grappe par le biais du commutateur amont SW3_1. Le commutateur aval SW4_1 interagit avec l'ensemble de machines DPPC, chargées de gérer la persistance des données et leur traitement, en fonction des programmes de jeu. Ces machines peuvent également être agencées en grappe avec redondance et/ou haute disponibilité. Il en est de même pour d'autres grappes, comme N21 à N24, avec SW3_2 et SW4_2, ainsi que N31 à N34, avec SW3_3 et SW43, et encore comme N41 à N44, avec SW3 4 et SW4 4. 15 En dehors des machines DPPC et des joueurs (et du réseau Internet lui-même), les éléments de la figure 3 forment une grappe (ou super grappe) de calculs en temps réel, qui n'est a priori dédiée à aucune tâche particulière. Ceci est reflété par le cadre en trait tireté RTCC. 20 Ces machines ou noeuds peuvent être des ordinateurs tournant sous un noyau Linux�, réduit aux fonctions de calcul, de réseau et de jeu. Elles peuvent être donc bien optimisées. De manière connue, les grappes sont agencées pour que le remplacement d'un noeud 25 défaillant puisse s'effectuer rapidement à chaud, notamment grâce à l'attribution automatique d'adresse par le protocole DHCP. L'augmentation de la capacité de traitement peut s'effectuer par l'ajout de noeuds supplémentaires, le cas échéant de commutateurs supplémentaires et/ou d'équilibreurs 30 de charge supplémentaires. 10 On suppose maintenant qu'un joueur Pl est déjà connecté au jeu. Les figures 4 et 5 permettront de décrire l'interaction de ce joueur avec le système central. Sur la figure 4, les échanges entre le joueur Pl et par exemple l'équilibreur de charge 5 LBC 1 se font à travers le commutateur d'entrée S W 1. Conformément au mode de réalisation actuellement préféré, il est admis que les machines M1 à Mp sont les noeuds ND1 à ND9, qui peuvent être organisés conformément au schéma détaillé de la figure 3, celui-ci n'étant pas repris sur la figure 4 10 pour éviter de compliquer inutilement le dessin. Ainsi, le cadre en trait tireté 400 correspond à l'un (LBC 1) des équilibreurs de charge. Il en existera plusieurs autres, comme LBC2, en 410. 15 L'équilibreur 400 comprend un répartiteur ou "dispatcher" 402, ainsi qu'un annuaire de services de jeu 404. Il peut comprendre d'autres fonctions utiles au jeu, non représentées ici. Le répartiteur 402 a deux fonctions principales : 20 - lors d'une requête de création d'une nouvelle instance de jeu pour un joueur P1, choisir un noeud sur lequel créer cette nouvelle instance, - lors d'une communication entre le joueur P1 et une instance de jeu donnée, acheminer le trafic entre le joueur et cette instance. 25 Pour réaliser la première de ces fonctions, le répartiteur 402 stocke des paramètres de calcul de charge qui seront détaillés avec la figure 6, ainsi que les paramètres de charge des noeuds qui sont régulièrement mis à jour. L'annuaire de service de jeu 404 assiste le répartiteur 402 en répertoriant les services de 30 jeu, c'est-à-dire les instances de jeu brutes non initialisées avec les paramètres d'un joueur. L'annuaire 404 stocke également l'ensemble des instances de jeu déjà créées, ainsi que la liste des joueurs qui sont connectés mais qui n'ont pas encore initialisé d'instance de jeu. Bien que le répartiteur 402 et l'annuaire 404 sont décrits comme des éléments distincts, 5 ils pourraient être réalisés de manière unitaire. De plus, certaines données stockées par le répartiteur 402 pourraient être stockées par l'annuaire 404, et inversement. Considérant maintenant la figure 5, une action du joueur P1 (opération 500) d'un joueur connecté à un jeu se traduit par une requête IP vers le système serveur central (opération 10 502). Cette requête contient la requête de jeu proprement dite, qui est émise sous une forme encapsulée dans une requête conforme au protocole Internet. Le trait pointillé sur le diagramme de flux de la figure 5 indique que la liaison se fait par le réseau étendu, ici 15 Internet. A l'opération 510, la requête IP est reçue par le répartiteur 402, qui ?Al tire notamment l'identifiant du joueur, noté ici Pl id. 20 Il en tire également, notamment par désencapsulation, la requête relative à une fonction de jeu dirigée vers l'instance du jeu auquel le joueur participe, assortie de ses paramètres, que contenait la requête encapsulée, comme l'indique l'opération 512. Cette requête de fonction de jeu assortie de ses paramètres est alors adressée à l'annuaire 25 de services de jeu 404 (opération 514). Celui-ci transmet la requête à la fonction de jeu obtenue à l'opération 512 à la fonction GamFnc dans le noeud qui contient l'instance de jeu associée au joueur P1. Dans l'exemple représenté sur la figure 4, cette instance est ici supposée placée sur le noeud ND1 (opération 516). 30 Après réception de la requête relative au jeu, le noeud concerné exécute la fonction de jeu, met à jour l'instance de jeu du joueur P1 (opération 520), et élabore une réponse relative à la fonction de jeu en correspondance de l'identifiant Pl id du joueur Pl (opération 522). La réponse ainsi élaborée est ensuite adressée au répartiteur 402, en 524. Cette réponse 5 est transformée par encapsulation en une réponse au protocole Internet, qui rejoint finalement le joueur Pl (opération 530). En parallèle, ont été mises à jour des instances d'autres joueurs comme indiqué à l'opération 560. Ces mises à jour seront utilisées sur des requêtes de ces autres joueurs, 10 comme indiqué en 590. Les opérations 520 et 560 consistent notamment en la mise à jour des données persistantes relatives aux différents joueurs. Ces données sont stockées dans le serveur DPPC (figure 3). Il est maintenant fait référence aux figures 6 et 7, pour décrire l'entrée d'un joueur dans un jeu, au niveau des données échangées. La figure 6 illustre comment s'effectue l'admission d'un joueur, compte tenu de 20 l'utilisation de machines indifférenciées de calcul, notées Nj sur la figure 2, et qui, dans le mode de réalisation actuellement préféré, sont les noeuds N11 à N14... N41 à N44 de la figure 3. Il s'agit donc d'admettre le joueur P1 dans le jeu G1 (opération 600). 25 L'opération 602 rappelle que des préliminaires sont effectués avant d'admettre le joueur PI dans le jeu G1. Ces préliminaires sont, pour l'essentiel, la vérification d'identifiants de connexion du joueur, du type identifiant/mot de passe, ainsi que la récupération de données persistantes liées au joueur, telle que la liste des sessions passées, sa liste 30 d'amis, ses avatars, etc. On suppose que l'admission du joueur a été autorisée. 15 Un mécanisme de décision, sur lequel on reviendra plus bas, va permettre de décider d'affecter le joueur P1 à la machine Mj (opération 700). Le test 606 détermine s'il existe un programme exécutable ("Runtime") du jeu G1 dans la machine Mj. Ceci peut être effectué soit par interrogation de la machine Mj, soit de préférence par mémorisation du chargement d'un tel exécutable dans la machine Mj, sous forme de données persistantes, par exemple dans une table ("look-up table"). Si un tel exécutable n'a pas été chargé, l'opération 610 va consister à rechercher dans le serveur de programme de jeu GPS (figure 2) un tel exécutable du jeu. Il est supposé ici que les machines Mj sont toutes identiques. Dans l'hypothèse contraire, il conviendrait de rechercher un exécutable correspondant au jeu GI et au type de la machine Mj considéré. Une fois trouvé, l'exécutable adéquat est chargé dans la machine Mj (opération 612). Ces exécutables sont du type "image de programme exécutable", c'est-à-dire qu'ils ont été a priori compilés ou adaptés au maximum au type de la machine Mj, de manière à diminuer autant que possible l'empreinte mémoire et à accélérer le temps de traitement. En sortie de l'opération 612, ou sur la sortie affirmative du test 606, on crée une instance du jeu G1 pour l'identifiant de joueur Pid dans la machine Mj, à l'opération 620. C'est alors la fin 630 de l'admission du joueur. La création de l'instance du jeu est réalisée en collaboration avec l'annuaire de services de jeu 404, qui stocke la relation entre le joueur P1 et la machine Mj qui exécute l'instance de jeu associée à P1. Cette correspondance est particulièrement utile pour les communications suivantes, comme cela a été décrit avec les figures 4 et 5. On décrira maintenant le mécanisme qui permet d'affecter le joueur P1 à l'une Mj des 30 machines indifférenciées. Cela commence à l'opération 700 de la figure 7. Le choix pour l'attribution d'un joueur à une machine donnée est ici réalisé en attribuant un score à chaque machine et en sélectionnant la machine ayant le score le plus élevé. Pour cela, un indice i est initialisé à 0 (opération 702) pour initialiser une boucle de 5 calcul des scores pour chacune des machines Mj. Le score C(i) de la machine i est calculé (opération 704) par une fonction Calc_Score(). La fonction Calc_Score() prend pour paramètres l'identifiant Pl id du joueur P1, et l'identifiant de la machine Mi. Dans un mode de réalisation préféré de l'invention, la 10 fonction Calc_Score() établit le score C(i) sur la base des critères suivants : - présence sur la machine Mi d'autres joueurs liés par un groupe au joueur P1 dans le jeu auquel celui-ci souhaite participer, - présence sur la machine Mi d'autres joueurs appartenant à la liste d'amis du joueur Pi dans le jeu auquel celui-ci souhaite participer, 15 - présence sur la machine Mi d'autres joueurs avec lesquels le joueur Pl a déjà précédemment communiqué dans le jeu auquel celui-ci souhaite participer, - occupation de la machine Mi en termes d'occupation processeur et mémoire. D'un point de vue technique, la fonction Calc_Score() utilise un ensemble de paramètres 20 liés d'une part au joueur et à son environnement dans le jeu, et d'autre part des paramètres liés à l'état de fonctionnement de la machine sur laquelle on souhaite l'affecter pour déterminer le score d'affectation. Ces critères sont chacun affectés de poids choisis, et le score CO) est la somme de toutes 25 ces valeurs. Les valeurs peuvent être positives ou négatives. D'autres fonctions que l'addition et d'autres paramètres que ceux précités peuvent être utilisés en variante. Lorsque le calcul de score CO) est réalisé, l'indice i est augmenté (opération 706), et s'il reste des machines, le score suivant est calculé. Sinon, la machine Mj à laquelle le 30 joueur P1 doit être affectée est désignée en choisissant l'élément du tableau C qui a le score le plus élevé (opération 708). Enfin, cette fonction se termine en 910 avec le renvoi de l'identifiant de la machine choisie. Cette méthode est particulièrement intéressante, car elle ouvre des possibilités jusqu'à présent ignorées dans la technique. En effet, dans la technique antérieure, les joueurs étaient affectés, dès la création de leur personnage, à une instance de jeu donnée. Cette instance était entièrement indépendante des autres instances du jeu, c'est-à-dire que les joueurs affectés à deux instances ignoraient leurs existences et actions respectives, comme si ces instances implémentaient des "mondes parallèles". Ainsi, un joueur était lié au monde auquel il avait été attribué a priori, et, il ne pouvait communiquer et jouer avec d'autres joueurs affectés à d'autres mondes. Un des avantages de l'invention est de rendre cela possible. Par ailleurs, l'invention permet également une affectation personnalisée, et non plus automatique. D'autre part, les mondes des jeux sont souvent découpés en zones géographiques, comme cela a été décrit plus haut. Dans l'architecture classique, chaque "monde parallèle" est découpé en "zones géographiques de monde parallèle" qui sont également indépendantes les unes des autres. Chaque zone de ce type étant limitée dans le nombre de joueurs qu'elle peut recevoir, le déplacement de groupes de joueurs entre zones était donc particulièrement difficile à implémenter. L'invention vient donc nettement améliorer la situation car il est possible d'affecter un groupe de joueurs donné à la machine qui implémente la zone géographique de destination de ce groupe la plus appropriée, au lieu d'être limité à la zone qui est associée au monde de départ. D'autre part, bien que l'invention ait été décrite avec référence aux jeux massivement multi-joueurs en ligne à composante ludique classique, elle peut également s'appliquer de manière similaire aux jeux à composante sociale ou aux divertissements non ou peu ludiques dits "mondes virtuels". Pour simplifier, les nombres de machines, commutateurs et autres éléments illustrés sur les dessins et/ou mentionnés dans la description ont été réduits par rapport à la réalité. 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. 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. Revendications 1. Système serveur de jeu électronique, du type comportant, sur un site, une unité de connexion à un réseau ouvert, et une pluralité d'ordinateurs agencés pour exécuter des 5 instances de jeu sur demande de joueurs, à travers l'unité de connexion, caractérisé en ce que certains au moins des ordinateurs de ladite pluralité sont des machines de calcul (Ml..Mp) dénuées de toute application au repos, en ce que le système comporte en outre un stockage (GPS) d'au moins une image de programme de jeu exécutable sur au moins une des machines (M1..Mp), et 10 en ce que l'unité de connexion comprend un serveur principal de jeu (MS), capable, en réponse à une demande d'accès à un jeu, d'y affecter l'une des machines de calcul sur la base d'une évaluation de la charge des machines de calcul, de créer pour le nouvel accédant une instance du jeu sur la machine affectée ; et 15 de gérer l'interaction réseau entre la machine affectée et le nouvel accédant. 2. Système selon la revendication 1, caractérisé en ce que, lorsque la machine affectée ne contient pas une image du jeu, le serveur principal (MS) appelle le stockage (GPS) pour implanter sur la machine affectée (M1..Mp) une image de jeu exécutable 20 convenant pour cette machine affectée (Ml..Mp), puis crée une nouvelle instance du jeu sur cette machine (Ml..Mp). 3. Système selon la revendication 1 ou 2, caractérisé en ce que, lorsque la machine affectée (Ml..Mp) contient une image du jeu, le serveur principal (MS) y crée 25 directement une nouvelle instance du jeu. 4. Système selon l'une des revendications 1 à 3, caractérisé en ce que l'affectation d'une machine de calcul est en outre basée sur des paramètres liés au joueur (P1..Pn) émettant la demande d'accès au jeu. 5. Système selon l'une des revendications précédentes, caractérisé en ce qu'il est appliqué à un jeu massivement multi-joueurs en ligne. 15 30 6. Procédé de gestion d'informatique distante, dans un site comprenant une unité de connexion à un réseau ouvert, et une pluralité de machines de calcul (Ml..Mp) dénuées de toute application au repos et agencées pour exécuter des instances de jeu à travers l'unité de connexion sur demande de joueurs, ainsi qu'un stockage (GPS) d'au moins une image de programme de jeu exécutable sur au moins une des machines (Ml..Mp), comprenant les étapes suivantes : a. la réception demande d'accès à un jeu par un joueur (Pi..Pn), b. la création d'une instance de jeu, et c. la gestion de la connexion entre le joueur (P1..Pn) et l'instance de jeu, caractérisé en ce que l'étape b. comprend les étapes suivantes : b1. affecter une des machines de calcul (Ml..Mp) à l'instance associée à la demande d'accès, sur la base d'une évaluation de la charge des machines de calcul, et b2. créer une instance de jeu sur la machine affectée (M1..Mp). 7. Procédé selon la revendication 6, caractérisé en ce que l'étape b2. comprend, lorsque la machine affectée (M1..Mp) ne contient pas une image du jeu, l'appel du stockage (GPS) pour implanter sur la machine affectée (Ml..Mp) une image de jeu exécutable convenant pour cette machine affectée (Ml..Mp), et la création de l'instance de jeu sur la base de cette image. 8. Procédé selon la revendication 6 ou 7, caractérisé en ce que l'étape b2. comprend, lorsque la machine affectée contient une image du jeu, la création directe d'une nouvelle instance du jeu. 9. Procédé selon l'une des revendications 6 à 8, caractérisé en ce que l'évaluation de l'étape b1. est en outre basée sur des paramètres liés au joueur (P 1..Pn) émettant la demande d'accès au jeu. 10. Procédé selon l'une des revendications 6 à 9, caractérisé en ce qu'il est appliqué à un 30 jeu massivement multi-joueurs en ligne.