Fichier de configuration utilisé côté serveur

Fichier de configuration utilisé côté serveur

Synthèse des travaux réalisés

Nous avons proposé dans le cadre de cette thèse une nouvelle approche dédiée à la réalisation de jeux massivement multi-joueurs, permettant de rationaliser et de sécuriser le développement de jeux innovants en ce qui concerne la manière dont le joueur interagit avec le monde virtuel dans lequel le jeu se déroule. Notre proposition consiste à utiliser des méthodes de génie logiciel appropriées, basées sur une démarche de prototypage et de ranement, en utilisant un environnement de développement dédié. Nous avons déni et prototypé un framework ouvert et modulaire pour garantir la généricité de la solution, et montré comment il peut s’intégrer dans un environnement de développement. Ce modèle original est centré sur la dénition des interactions à l’aide d’une description très ne de la manière dont les données de l’application sont répliquées sur les diérents hôtes de l’application distribuée. Il adopte un modèle simple de programmation concurrente pour la description du comportement de l’application, basé sur un ordonnancement coopératif et équitable des tâches en cours d’exécution. Plus général que les modèles orientés objet et orientés agents, il dissocie la manière dont sont organisées les données de leurs comportement. Il permet néanmoins de concevoir une application selon ces paradigmes, en organisant de manière adéquate les données et les traitements. Ce découplage entre les données et leur traitement est complété par une approche transverse, proche des modèles de meta-programmation tels que la programmation par aspects, où diérentes manières d’eectuer un traitement peuvent être considérées lors de la conception de l’application. 

Implémentation réaliste

Nous voulons dans un futur proche réaliser une implantation plus réaliste du modèle, en prenant en compte les autres aspects d’un jeu massivement multi-joueurs, dont les plus importants sont donnés ici. Nous voulons ajouter au prototype un mécanisme permettant aux hôtes de l’application de s’échanger ou de mettre à jour dynamiquement de nouveaux comportements (les ordonnançables). Cette amélioration ne modiera pas le modèle, mais seulement le prototype, puisque nous envisageons alors d’ajouter les comportements à la liste des types de base dénissant les données propres d’un état. Un état pourra ainsi être conçu pour dénir un moyen d’obtenir un mécanisme de code mobile. Nous aimerions également réaliser une implantation plus performante que celle qui existe actuellement, et qui est basée sur l’ordonnancement des threads Java an de réaliser un autre ordonnanceur. L’implantation actuelle utilise un pool de threads Java qui sont tous créés au lancement de l’application : la création d’un thread est très coûteuse en Java et nous devions éviter d’utiliser trop souvent cette opération pour garder un prototype un tant soit peu réaliste. Lorsqu’un réexe est déclenché, son exécution est attribuée à un thread donné du pool. Le nombre de threads à créer au démarrage, ainsi que son augmentation ou diminution dynamique selon les besoins de l’application est un problème complexe. Il existe des patrons de conception répondant à cette famille de problèmes et nous comptons les étudier et expérimenter an de trouver une solution souple et ecace. Nous n’envisageons pas forcément d’abandonner totalement le langage Java, qui peut rester le language d’implantation du reste du framework et de la bibliothèque, mais il est possible  que d’autres langages soient plus adéquats pour la réalisation de l’ordonnanceur lui-même, et nous comptons faire quelques expériences à ce sujet. De même, nous comptons dans un futur très proche étendre la bibliothèque très minimale que nous proposons, notamment en incluant des éléments permettant de dénir des comportements d’objets plus complexes du monde virtuel, comme par exemple des agents autonomes. Cette tâche est un bon test sur le réalisme de notre solution, dont les critères de réussite seront un bon passage à l’échelle et la simplicité des descriptions dans le cadre du framework. Nous aimerions également tester l’adéquation de notre modèle à d’autres familles d’applications distribuées faisant intervenir des éléments hétérogènes et communicants disposant d’autres contraintes matérielles, comme par exemple des applications domotiques ou de robots ludiques [92]. Nous pourrions ainsi étendre de manière pertinente la bibliothèque à de nouveaux protocoles et modèles de communication qui seront peut-être, comme le laisse envisager l’intérêt actuel pour les terminaux de jeux mobiles, les supports des distractions de demain. 7.3 Environnement de développement Nous voudrions dans l’idéal réaliser un environnement de développement complet autour du framework que nous avons déni. Celui-ci permettrait d’assembler les composants de l’application, de générer le code spécique à l’application à partir de cet assemblage, et fournirait des outils de mise au point, comme par exemple rejouer une exécution, à l’aide de scenarii d’événements provenant du réseau ou des interfaces utilisateur. Dans un futur proche, il sera indispensable de fournir un outil permettant de générer une grande partie du code générique, et capable d’automatiser l’écriture des scripts de conguration, ces tâches étant actuellement fastidieuses et répétitives. Nous pensons également intégrer un outil de simulation de mauvaises conditions de réseau du style de NetTool [60]. Nous voulons ultérieurement étudier les possibilités de réaliser des analyses statiques s’appuyant sur la sémantique d’exécution du modèle pour identier et calibrer les caractéristiques de l’application : par exemple, donner une estimation des ressources nécessaires au déploiement de l’application, ce qui permettrait d’éviter le sous-dimensionnement ou le sur-dimensionnement en permettant assez tôt d’avoir une estimation des ressources nécessaires.