6.6 Un exemple simple
6.6.5 Les ordonnançables, côté serveur
Maintenant que nous avons présenté les états et les briques de base né- cessaires, nous pouvons dé nir les ordonnançables qui décrivent le compor- tement de l'application.
On dé nit cinq ordonnançables pour la description des comportements et les réplications des états du serveur. Pour chaque ordonnançable, nous donnerons le nom de la classe qu'il instancie, a n que le lecteur curieux puisse se référer au code Java de cette classe, en annexe.
Le modèle de réplication forwardReplication : c'est une instance de la classe StateChangedReplication de la bibliothèque des blocs de base.
Il est attaché à chaque état duplicata représentant un client. Il a comme état observé l'état duplicata auquel il est attaché. Il ne dé nit aucun état utile.
Sa condition de réalisation (temporalité) renvoie toujours true. Il ne dé nit aucun ré exe.
6.6. UN EXEMPLE SIMPLE 185 Ses propriétés de communication sont udpProtocol.
Ce modèle sera donc déclenché lors du changement de chaque état duplicata correspondant à un client de l'application, pour propager ce changement aux autres hôtes clients. Il permettra notamment de propager les déplacement des avatars.
Le modèle de réplication hostCreatedReplication : c'est une instance de la classe HostCreatedReplicationq de la bibliothèque des blocs de base.
Il est attaché à chaque état duplicata représentant un client. Il a comme état observé l'état lastHostConnected.
Il a comme état utile l'état lastHostConnected.
Sa condition de réalisation (temporalité) renvoie toujours true. Il ne dé nit aucun ré exe.
Sa portée est hostCreatedScope.
Ses propriétés de communication sont tcpProtocol.
Ce modèle de réplication sera déclenché à chaque mise à jour de l'état lastHostConnected, et utilisera la valeur de cet état pour propager à l'hôte correspondant les états duplicata représentant les autres hôtes de l'applica- tion. Il permettra de provoquer la création de l'état correspondant au dernier client connecté aux autres clients de l'application.
L'ordonnançable sans réplication newMessageBehavior : c'est une instance de la classe StateUpdateBehavior.
Il est attaché à l'état gameState.
Il a comme état observé l'état lastMessage.
Il a comme états utiles les états lastMessage et newMessage. Sa condition de réalisation (temporalité) renvoie toujours true.
Son ré exe copie le contenu de l'état lastMessage dans l'état newMessage. Cet ordonnançable sera déclenché chaque fois que l'état lastMessage est modi é, et modi era l'état newMessage.
Le modèle de réplication chatMessage : c'est une instance de la classe ChatMessageReplication.
Il est attaché à l'état newMessage.
Il a comme état observé l'état newMessage. Il a comme état utile l'état newMessage.
Sa condition de réalisation (temporalité) renvoie true si et seule- ment si le texte contenu dans newMessage ne commence pas par la commande murmure.
Il ne dé nit aucun ré exe. Sa portée est allScope.
Ses propriétés de communication sont tcpProtocol.
Ce modèle de réplication sera déclenché chaque fois que newMessage sera modi é et que la chaîne de caractères qu'il contient ne commencera pas par la commande de murmure. Il répliquera alors l'état newMessage vers tous les clients de l'application.
Le modèle de réplication murmureMessage : c'est une instance de la classe MurmureMessageReplication.
Il est attaché à l'état newMessage.
Il a comme état observé l'état newMessage.
Il a comme état utile l'état newMessage et l'état murmureDistance. Sa condition de réalisation (temporalité) renvoie true si et seule-
ment si le texte contenu dans newMessage commence par la commande murmure.
Il ne dé nit aucun ré exe. Sa portée est murmureScope.
Ses propriétés de communication sont tcpProtocol.
Ce modèle de réplication sera déclenché chaque fois que newMessage sera modi é et que la chaîne de caractères qu'il contient commencera par la com- mande de murmure. Il répliquera alors l'état newMessage vers tous les clients à portée du murmure en utilisant l'état murmureDistance pour sélectionner les hôtes correspondant.
Le lecteur curieux ou insatisfait peut trouver en annexe le code correspon- dant à la description de ces ordonnançables et leurs fabriques, ainsi que les textes de con guration qui dé nissent chacun de ces modèles de réplication.
6.6.6 Synthèse
Bien que cet exemple soit très simple, et n'illustre pas l'utilisation des instructions ash et cooperate dans la dé nition des ré exes utilisateur, il
6.6. UN EXEMPLE SIMPLE 187 su t à montrer comment nous avons rempli les objectifs que nous nous étions xés.
La gestion des données représentant l'état de l'application, organisées en une hiérarchie d'états, est totalement découplée de la manière dont ces données sont synchronisées sur les diérents hôtes, dé nie à l'aide des modèles de réplication. Ce découplage facilite la mise au point des interactions, car il rend leur dé nition indépendante de la modélisation de l'application en terme d'objets du monde virtuel.
Ce découplage entre les données et leurs traitements nous permet de mo- di er simplement les propriétés de réplication d'un état, sans avoir à toucher à l'organisation des données déjà dé nie : par exemple, si on veut augmenter la distance de murmure, il su t de modi er la valeur de l'état distanceMur- mure. On peut même ajouter un ordonnançable qui modi e cette distance en fonction, par exemple, du nombre de clients connectés. De même, il est aisé de remplacer une propriété de communication ou une portée par une autre dans la dé nition d'un modèle de réplication. Il est également aisé d'ajouter un modèle de réplication à un état : par exemple, si on décide de vouloir enregistrer la position de chaque joueur lorsqu'il se déconnecte, on peut dé- nir un nouveau modèle de réplication pour communiquer les positions des avatars de manière able. Ces modi cations n'auront aucun impact sur la dé nition de l'état répliqué, seul son texte de con guration sera à modi er légèrement.
Cette approche, couplée avec une méthode de développement basée sur le ra nement de prototypes et des tests systématiques (en utilisant des outils de simulation de réseau par exemple), permet de construire une application autour de la dé nition et de la mise au point des interactions, en les adaptant très précisément au game-play désiré.
Cet exemple montre également comment utiliser le framework et la bi- bliothèque des blocs de base pour mettre en place une architecture donnée. Il peut être vu comme un cas d'école, à utiliser comme modèle pour réaliser d'autres architectures de distribution.
Nous sommes toutefois conscients que pour l'instant, il est délicat d'uti- liser notre solution, tant qu'il n'existe pas d'outil permettant de générer le code lourd et répétitif décrivant états et ordonnançable.
Chapitre 7
Perspectives
7.1 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 appro- priées, basées sur une démarche de prototypage et de ra nement, 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 compor- tement 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 189
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.