• Un module de match making, qui se charge de garder une trace des invitations des joueurs entre eux pour former des équipes. A invite B et C pour joueur une partie en 2 équipes de 3, ils acceptent tous et forment donc l'équipe 1. D a invité E et F mais F a refusé, puis G a invité H et I qui ont accepté, formant donc l'équipe 2. Le système lance donc une partie qui oppose les équpes 1 et 2).
  
• Un module de scoring/ranking, qui se charge de faire des stats sur les équipes pour maintenir un tableau de scores ;
  
• Un module d'achievements, qui se charge de suivre les "succès/médailles/hauts faits" effectués par les joueurs ;
  
• Un module de gestion des parties, qui se charge de la résolution des tours de jeux, des déplacements des unités, etc ;
  

• Une application Web (Nginx + Ruby on Rails + Backbone) qui sert les pages Web et qui dispatch les requêtes aux autres modules ;
  
• Un serveur de base de données (MongoDB) ;
  
• Un serveur de messaging (RabbitMQ), qui permet aux différents modules de parler entre eux ;
  
• Un serveur de communication (Faye + Sengrind), qui se charge d'envoyer les messages aux joueurs (en push ou par mail, selon les messages et selon que le joueur est connecté ou non) ;
  

• Le joueur A se connecte sur le site de Seelies (l'application Web riche en Javascript, propulsée par Ruby on Rails), il se connecte à son compte (stocké dans la base MongoDB), il arrive sur la page qui liste les parties dans lesquelles il joue (toujours en requêtant la base MongoDB) ;
  
• Il veut jouer avec ses amis B et C dans une petite partie (au format 2 équipes de 3 joueurs), il leur envoie donc une invitation. L'application Web envoie un message dans RabbitMQ sur la queue match_maker.new_invitation avec un peu de données encodées en JSON, disons { sender: 'A', other_players: [ 'B', 'C' ], format: { teams: 2, players_per_team: 3 } } ;
  
• Le module de match making reçoit ces messages : il va chercher les informations sur les joueurs dans la base MongoDB pour savoir s'ils ont bien le droit d'être invités par ce joueur (par exemple si un joueur en a "bloqué" un autre, c'est là qu'on coupe l'interaction). Il enregistre dans MongoDB la demande d'invitation et envoie des messages dans RabbitMQ pour notifier au joueur A que ses invitations ont bien été traitées et aux joueurs B et C qu'ils sont invités à jouer ;
  
• Le serveur de communication reçoit ces messages : il sait que A doit être notifié que ses invitations ont bien été envoyées, on lui envoie un push (en push Websocket via Faye) pour lui répondre. Il doit aussi notifier à B et C qu'ils sont invités par A ; comme B est en ligne, il lui envoie aussi sous forme de push pour que le navigateur affiche une popup pour qu'il accepte ou décline l'invitation (ce qui engendrera l'envoi et le traitement de nouveaux messages). C est hors ligne, donc on lui notifie l'invitation via un mail : il y répondra en répondant au mail ou en se connectant au site.
  
• etc.
  

(26-04-2013, 09:39 PM)Sephi-Chan a écrit : Rien n'empêche au module de scoring/ranking d'utiliser des informations crées par le module d'achievements : rien ne l'empêche d'accéder à la base de données MongoDB.

(26-04-2013, 09:39 PM)Sephi-Chan a écrit : Bien sûr, le découpage que j'expose ne convient pas forcément pour tout (et il n'est probablement pas parfait). On peut tout à fait séparer un module en plusieurs dans le futur, ou au contraire en rassembler plusieurs.

(26-04-2013, 09:39 PM)Sephi-Chan a écrit : Enfin, il ne faut pas hésiter à se frotter à des choses nouvelles : on progresse en sortant de notre zone de confort.