Conception détaillée

Réponses aux exigences non-fonctionnelles

Description des attendus des principales caractéristiques du jeu :
Comme le jeu de société dans la réalité, un joueur possède un nom et une couleur. Il possède ou non des cartes progrès, des cartes chevalier, des cartes Point de Victoire, des cartes ressources et des pions (routes/colonies/villes) sur le plateau. Nous avons séparé les ports des infrastructures que le joueur peut poser, de toutes façons, si une colonie/ville a un port, ce sera visible.

Un plateau est composé de tuiles terrains/mers. Chaque terrain produit une ressource (exception faite du désert et de la mer). Chaque terrain possède un numéro permettant de générer la ressource pour les joueurs au lancé de dés. Le plateau est composé de 19 tuiles terrains et 6 mers, donc 25 tuiles en tout. Les ports sont au nombre de 9 et il y en a certains qui sont spécialisés dans le marchandage d’un certain matériau.

Il y a trois types de carte développement. Les Chevaliers, les cartes Progrès et les Points de Victoire.

Une infrastructure, un pion, peut être une route/colonie/ville. Elle se situe sur le plateau, à l’intersection de 2 ou 3 tuiles.

La partie doit indiquer le nombre de points de victoire pour que celle-ci se termine. Elle connait évidemment tous les joueurs et dispose normalement d’un plateau.

Diagramme de classe du jeu

diagram

L’attribut score d’un Joueur est calculé à partir d’autres attributs de la classe qui sont :

  • nbKnights

  • hasLongestRoad

  • hasGreatestArmy

  • listVictoryPointCards

  • infrastructuresGameBoard

Concurrence

Les joueurs dans la partie doivent pouvoir jouer simultanément seulement lors d’un cas précis : Le commerce entre eux. Sinon, c’est un mode de jeu tour par tour.

Performance

La rapidité de la partie ne doit être limitée que par les animations du jeu, s’il y en a, et par la rapidité de jeu des joueurs. (exemple d’animation possible : le placement d’une construction arrive par le haut du plateau et vient se poser à l’endroit indiqué par le joueur)

Les animations ne devront pas dépasser 2 à 3 secondes.

Portabilité

Le diagramme de classe se voudrait indépendant du quelque langage que ce soit mais il nous a semblé préférable d’utiliser une approche orientée objet, tel que le langage Java, pour implémenter ce jeu.

Le jeu en ligne se veut jouable sur ordinateur. Une version téléphone ou tablette reste possible.

Sécurité

Un utilisateur ne peut pas modifier les données des autres utilisateurs à son bon vouloir. Seulement les méthodes permettant de communiquer avec la partie seront acceptées. On ne laissera pas se connecter un utilisateur avec un pseudo invalide. Quand une partie sera commencée, aucun autre utilisateur extérieur ne pourra y accéder.

Exigence de sécurité

Notre système doit être sécurisé, même si nous ne manipulons pas des données sensibles. Pour cela nous devons vérifier l’identité de l’utilisateur.
N’ayant pas à nous occuper de l’authentification de l’utilisateur, nous admettons que le système s’occupant de cela est correct et lui-même sécurisé. Nous admettons également que, quelle que soit la plateforme utilisée (web, logiciel, application) le service d’authentification sera le même pour tous.

Maintenabilité

L’utilisation d’interface pour les différentes classes est primordiale afin de garantir une maintenabilité plus simple. Le détail de ces interfaces est dans interface.adoc dans la rubrique Spécification des composants. Le diagramme où les interfaces interagissent avec le système se situe dans la même rubrique, dans le diagramme de Fonctionnement du jeu.

Utiliser une classe représentant le dé permettra de changer facilement le fonctionnement du lancé dans le futur.

Les classes Build et Trade sont des classes intermédiaires permettant de réduire le coupling et de favoriser des changements faciles des fonctionnalités de construction et d’échange dans le futur, si besoin est.

Interface utilisateur

L’utilisateur doit voir le plateau au milieu de son écran. Il verra les ressources en sa possession en bas à gauche de son écran. En bas à droite, il y aura ses cartes développement. En haut à gauche, il y aura les autres joueurs. Leurs noms et leurs couleurs seront affichés, ainsi que le nombre de cartes chevalier en leur possession. Sur la tranche gauche de l’écran, se situeront les boutons pour lancer les dés, commercer, construire, piocher une carte développement ou finir son tour. La valeur du lancer de dés sera affichée à côté du bouton associé.

Interface logicielle

Le client arrive sur l’API. Le logo du jeu est écrit au centre de l’écran et l’utilisateur peut rentrer son nom dans un champ de texte en dessous du titre prévu à cet effet. Si le pseudo est valide, le serveur attribuera automatiquement une partie en cours d’attente de joueurs ou en créera une (par soucis de simplicité).

Interface ou protocoles de communication

Comme précisé dans le diagramme de composants ci-dessous :

diagram

Le client communique via le format TypeScript à une interface que propose le composant "Client Middleware" afin de convertir le format précédemment cité en WebSocket. Ce composant pourra alors communiquer avec un autre composant intermédiaire qui transcrira les données de WebSocket à Java ou un autre langage afin que le serveur traite correctement les données. On satisfait ainsi l’un des principes SOLID, le Dependency inversion.

Dans l’ordre, si on utilise Java pour le langage de la Partie :
Server Java IGame Java Game
Server Java Connexion Server Java Server Middleware
Server Middleware WebSocket Connexion Middleware WebSocket Client Middleware
Client Middleware TypeScript Connexion Client TypeScript Client

Patrons logiciels utilisés

Patron de conception "Façade pour Game"

Le design pattern Façade est fortement conseillé pour l’interface que fournit Game, c’est-à-dire IGame. Cela va permettre au serveur d’avoir accès à seulement une interface pour échanger avec la partie et la maintenabilité sera plus aisée.

Choix techniques - Distribution des processus

Pour cela nous allons donc vous présenter l’environnement général de développement puis énoncer les 4 contraintes que nous avons déterminées de notre logiciel.

Nous avons fait le choix d’utiliser comme environnement de travail l’IDE IntelliJ. Pour la raison que nous connaissons tous très bien cet environnement, ce qui nous permet d’avoir le même environnement de développement pour tous.

Également, cet IDE permet la gestion d’un projet maven ce qui nous sera parfaitement adapté et une interaction avec GitLab facile.

Voici les 4 contraintes que nous avons déterminées :

  1. L’interface graphique.

  2. La communication vers la base de données.

  3. La communication entre les machines.

  4. La sécurité.