Document sous licence Creative Commons PaternitNonCommercialNoDerivs 2'5 License'

1
Architecture générique pour des jeux multi
joueurs au tour par tour

• Jean-Etienne GOUBARD
• 19/06/2006

2
Optique

• Définir une architecture adaptée aux critères
  suivant
• Unique
• Supporte à la fois jeu solo et multi joueur
• Modulaire le remplacement dun module ne doit
  pas impacter les autres modules, si les
  spécifications dinterfaces sont respectées.
• Doit permettre de visualiser rapidement la
  répartition des tâches, et la délimitation des
  travaux.
• Doit permettre dagréger la vision des différents
  intervenants.
• Simple elle ne fait apparaître quune vision
  très haut niveau du logiciel

3
Décision 1 architecture générale

• Le jeu pouvant être joué à distance, il convient
  donc de choisir une architecture de type
  client/serveur.

4
Schéma darchitecture client / serveur
Flèche bleue le service bleu boucle sur
lui-même, et interroge chaque client un par un.
(1 tour 1 boucle)
Wargame Service
Flèche verte Pour chaque changement du monde,
notification à tous les clients.
Flèche rouge Requête dordre réponse associée,
pour le client dont cest le tour
Wargame Client 1
Wargame Client 2
Wargame Client 3
IA Client 1
IA Client 2
Tour 1
Tour 2
etc
5
Décision 2 framework

• Afin dhomogénéiser les interfaçages de
  développement, chaque module composant le
  logiciel répondra à une interface unique, capable
  de communiquer avec un bus logique. (voir schéma
  suivant)
• Les données transitant sur le bus logique sont
  des messages très simples encapsulant des données
  propres aux modules.

6
Schéma darchitecture bus
Trait rouge Interface unique pour branchement
sur bus
Flèche verte Messages transitant par le bus.
Client
Service
Module 1
Module 2
Module 3
Module 1
Module 2
Bus logique de communication
Adresse _at_ip client ou service id du
module
Structure du message
Adresse Destination Adresse Source Body Données
de sécurité Total de contrôle
7
Décision 3 interactions utilisateur

• Le moteur de présentation à lutilisateur
  (affichage son) est indissociable du moteur de
  saisie (clavier/souris), car par exemple les
  coordonnées souris sont relatives à la résolution
  daffichage, donc une sélection ne peut se faire
  quavec connaissance du contexte daffichage.
• Laffichage est lié au son, pour quun seul
  module soit à même, entre autre, de gérer les
  synchro son image dans les séquences dintro et
  inter-parties.

8
Wargame Service
Wargame Client
Stockage  Temps réel 
Stockage Media
Changements du monde
World manager
Display manager
Ressources
Ressources
Contraintes Règles
Media
Données
Données
Contextes
Contextes
Données
Données
Comptes utilisateurs
Notification des modifications
Display Context
Modification
Notification des modifications
consulte
Interaction utilisateur (affichage saisies)
Notification des modifications
Algorithmes de base
Ordonnanceur
Découverte de chemin
Modif des Attributs
Évenements IHM
Consulte
Ordres
communicates
Ordres
communicateur Service
Gestionnaire Service
Communicateur Client
Gestionnaire Client
communicates
IA Client
Communicateur Client
IA
9
Wargame service (WS)

• cur principal du jeu Cest le module dans
  lequel seffectueront les calculs du jeu en
  lui-même.
• Non-visuel Il sagit dun module pouvant
  communiquer avec des interfaces graphiques, mais
  pas lié à une interface graphique particulière,
  en ce sens on ne peut interagir avec lui, quen
  communiquant via son protocole.
• Peut-être implémenté comme un web service
• Prend les décisions Cest ce module qui
  décidera quelles sont les différents états des
  unités, en fonction des résultats des différents
  calculs, ce module a toujours raison, par rapport
  aux états des clients qui y sont connectés.

10
WS Stockage temps réel

• Stocke chaque changement accrédité par le
  gestionnaire du monde (emplacement des unités,
  propriétés, etc) Cest ce module qui est
  charger de modifier les données en mémoire qui
  représentent le monde la carte du jeu en
  loccurrence. A chaque changement validé par le
  gestionnaire de monde, ce module va le répercuter
  en modifiant les données correspondantes.
• Contient une partie  ressources  (données
  pouvant changer uniquement par intervention
  humaine administrateur / créateur de jeu )
  Mettons que le Stockage temps réel soit par
  exemple un wrapper de SGBD, et que le
  gestionnaire de monde transforme des demandes de
  modification du monde, en langage SGBD, après
  avoir vérifié quelle ne corromprait pas la
  cohérence du monde par exemple il refusera
  lordre de faire descendre une unité si elle est
  déjà au sol)
• Contient une partie  contextes  (données
  modifiées en mode opérationnel (durant le jeu))
  Idem cest dans la base de donnée)

11
WS Gestionnaire du monde

• Suit les règle de contraintes pour valider ou non
  un ordre de modification envoyé par le
  gestionnaire de service Le gestionnaire reçoit
  un ordre, et lenvoie au gestionnaire du monde,
  qui dit non si ca risque dintroduire des
  incohérences dans la base, pour cela il se base
  sur un ensemble de règles)
• Chaque fois que le gestionnaire de monde décide
  (après validation) de modifier la base de donnée,
  il doit notifier le changement (par
  lintermédiaire du communicateur service) à tous
  ses clients, via multidiffusion.
• Peut consulter des algorithmes de base (comme la
  découverte de chemin, ), pour calculer les
  dommages, la prochaine position, etc (A voir si
  cela nest pas redondant avec les règles)

Jean-Etienne GOUBARD Voir si les algorithmes de
base ne peuvent pas englober les règles de
validation
12
WS Ordonnanceur

• Est consulté par le gestionnaire de service pour
  savoir qui joue le tour suivant, et de qui une
  réponse est attendue.
• Garde létat actuel des requêtes.

13
WS Gestionnaire de Service

• Reçoit de requêtes dordre via le Communicateur
  Service.
• Consulte lOrdonnanceur pour savoir quoi faire et
  quand.
• Demande des ordres au client idoine (via le
  communicateur Service)
• Transmet lordre (éventuellement reformulé) au
  gestionnaire de monde.

14
WS Communicateur Service

• Réalise la communication entre le client idoine
  et le service. (via un protocole standardisé).
• Peut réaliser des opérations de test dintégrité
  pour sassurer quune requête ou réponse nest
  pas altérée.

15
WS Algorithmes de base

• Sont utilisés par le gestionnaire de monde pour
  calculer les changements dans le monde.
• Peut être implémenté comme un système de mise à
  jour dynamique basé sur des assemblages. (par
  exemple un système de pluggins via des dlls)

16
Wargame client (WC)

• Affiche la situation provenant du service
  Wargame
• Visuel
• Envoie des requêtes dordres au service Wargame
• Ne peut pas prendre de décisions
• Est implémentée comme une application

17
WC Communicateur Client

• Fait la communication entre le client et le
  service. (via un protocole standardisé).
• Peut réaliser un contrôle dintégrité, de façon à
  sassurer quune requête/réponse na pas été
  altérée
• Reçoit les modification du monde envoyé par le
  service, et les transmet au gestionnaire
  daffichage.

18
WC Gestionnaire daffichage

• Contient des données en mémoire reflétant le
  monde, côté utilisateur.
• Est en interaction constante avec les
  périphérique de sortie (écran / haut parleurs),
  pour notifier les changements côté utilisateur

19
WC Gestionnaire Client

• Interprète les événements dentrée de
  lutilisateur, et les transforme en ordres, qui
  seront envoyés au service, à travers le
  communicateur client.

20
WC Stockage Media

• Contient des ressources Images / Vidéos / Sons,
  quil serait trop lourd de faire transiter via le
  service, et qui aident à notifier les changements
  du monde à lutilisateur.

21
IA Client (IC)

• Contient toutes les données concernant lIA
• Sinterface de la même façon quun client
  humain, et à la même visibilité sur le monde Il
  utilise exactement le même protocole que le
  module client
• Implémentée comme un composant instancié à la
  demande à chaque fois quon définit une IA en
  tant que joueur quand on crée une partie, un
  nouveau module de type IA client est créé, et
  interfacé automatiquement avec le service
• Non visuel

22
IC Communicateur client

• Même chose que pour le service

23
IC IA

• Essaye de prendre des décisions comme un humain
  le ferait.
• Maintient des contextes sur tout ce qui concerne
  létat dintelligence artificielle des unités.
  (dépend de lalgorithme utilisé).

24
Protocole pour les commandes
Exemple en XML bouger lunité 675 vers la droite

• ltOrderRequestgt
• ltModegtMovelt/Modegt
• ltUnitIdgt675lt/UnitIdgt
• ltDirectiongtEastlt/Directiongt
• lt/OrderRequestgt

ltOrderResponsegt ltResultgtOklt/Resultgt lt/OrderRequest
gt
25
Protocole de notification des changements du monde
Exemple en XML une unité a bougé vers la droite

• ltModificationgt
• ltModegtEraselt/Modegt
• ltPositiongt
• ltxgt25lt/xgt
• ltygt30lt/ygt
• ltzgt0lt/zgt
• lt/Positiongt
• lt/Modificationgt
• ltModificationgt
• ltModegtSetlt/Modegt
• ltPositiongt
• ltxgt26lt/xgt
• ltygt30lt/ygt
• ltzgt0lt/zgt
• lt/Positiongt
• ltUnitIdgt675lt/UnitIdgt
• lt/Modificationgt

26
Décision 4 Simplifications

• Dans le but datteindre plus rapidement un
  prototype opérationnel, le strict nécessaire sera
  développé dans un premier temps (les
  améliorations se feront par raffinement
  successifs, dans les cycles de développement
  futurs)
• La communication entre le client et le serveur
  sera simulée par simple appel de fonction.
• La base de données côté service, sera gérée par
  un système du type SQL-lite, ou directement en
  mémoire.
• Les modèles 3D utilisés seront des formes
  parallélépipédiques sans textures, représentant
  lemplacement des unités. (Il en va de même pour
  les sons)
• Les règles de gestion du monde ne proviendront
  pas dun système de scripts, mais seront
  directement codés dans un assembly.
• Les unités se  téléporteront  à leur
  destination dans le cas dun déplacement. (Pas de
  progression continue de lunité jusquà sa
  nouvelle position)
• Pas dIA, multijoueur uniquement.

27
Décision 5 le maillage

• Le maillage représente la façon dont est
  discrétisé le monde, qui conditionne à la fois
  les déplacements et linteraction avec le joueur.
  Suite à quelques réflexion il a été convenu que
  le maillage répondrait aux critères suivants
• Discrétisé sous forme cubes de base
• Les unités pourront occuper plusieurs cubes, mais
  seront confinées dans des parallélépipèdes.
• La souris déciderait de la position de
  destination X,Y pour le déplacement, tandis que
  la molette permettrait de régler le plan Z.
• Lapproche non discrétisée posait des problèmes
  dans la gestion de collisions (trop fort couplage
  entre affichage et traitement), notamment si le
  système dinterface doit être suffisamment
  générique pour pouvoir être soit en 2D, soit en
  3D.
• Lapproche discrétisée hexagonal posait des
  problèmes, car non éprouvée en full 3D, et posait
  donc certains risques de partir dans une
  direction trop difficile à gérée.

28
Décision 6 langage

• Les langages .Net offrent de bons compromis via
  les points suivants
• Langage moderne (avec toutes les facilités de
  programmation qui en découlent)
• Rapidité dexécution
• Lien robuste avec DirectX
• Possibilité de compiler en .exe  classique 
• Encapsulation aisée des DLL tierces.
• Intègre la gestion des webservices en natif
• Conceptuellement portable (via Mono sous linux)
• Conversion de syntaxe dun langage dans un autre
  (possibilité de visualiser le même code en J,
  C, VB.Net, MC) ? pédagogiquement intéressant.