Page 6 sur 13
D'après l'analyse, il faut créer au moins 4 classes spécifiques au jeu :
- pour représenter un pion
- pour représenter le plateau de 3x3 cases
- pour représenter le pool de pions de chaque joueur.
- pour représenter l'état du jeu loirs d'une partie.
Utiliser boardifier-console ne change rien à ce constat, excepté le fait que ces 4 classes vont devoir hériter des classes définies dans boardifier-console, et que d'autres classes vont être nécessaires. Pour comprendre pourquoi et comment faire, il faut connaître la logique utilisée pour la partie modèle de boardifier-console. Pour synthétiser :
- Chaque élément de jeu (les pions, les plateaux, textes, boutons, ...) doit être représenté par une sous-classe de GameElement.
- GameElement contient la plupart des attributs nécessaires à la gestion d'un grand nombre de type d'éléments (position dans l'espace, visible, sélectionnable, ...), ainsi que les méthodes permettant de lire/écrire ces attributs.
- boardifier-console propose déjà plusieurs sous-classes à GameElement, mais aucune qui corresponde à un pion.
- C'est pourquoi on crée la sous-classe Pawn.
- En revanche, boardifier-console propose déjà une sous-classe qui permet de représenter une "zone" multi-cases, où placer des éléments : ContainerElement.
- ContainerElement modélise une grille 2D de cases, dans lesquelles on peut assigner un ou plusieurs éléments du jeu. Cela permet de représenter les zones où l'on va placer des pions/cartes/dés/..., comme par exemple le plateau d'un jeu d'échec. A noter que des cases voisines peuvent être (dé)jointes comme on le ferait dans un tableur.
- Il est bien entendu possible d'utiliser ContainerElement pour créer une zone d'une seul case, ou bien juste une ligne/colonne de cases.
- ContainerElement contient tous les attributs et méthodes permettant de gérer la grille, notamment pour insérer/déplacer/enlever un élément de la grille, pour dire si une case est utilisable ou non lors d'une action de jeu.
- Pour implémenter une zone pour un jeu particulier, on crée généralement une sous-classe de ContainerElement, afin de profiter des fonctionnalités héritées et en lui ajoutant celles qui sont propres au jeu.
- Par exemple, pour "The Hole", on crée :
- une sous-classe HoleBoard représentant la zone de 3x3 cases, avec une méthode computeValidCells() qui permet de calculer et mettre à jour quelles cases sont utilisables pour placer le pion actuellement sélectionné (NB : ce calcul est dépendant du jeu et ne peut donc pas être directement fait dans ContainerElement)
- une sous-classe HolePawnPot pour représenter les zones de 4x1 cases où sont stockés les pions à jouer.
- Pour gérer l'état du jeu, boardifier-console se base sur une classe Model contenant ce qui est commun à tous les jeux et une classe GameStageModel, contenant ce qu'il faut pour gérer un stage dans le jeu.
- La plupart des jeux de plateaux n'ont donc qu'un seul stage.
- GameStageModel contient essentiellement 3 listes et les méthodes associées pour les manipuler :
- celle de tous les GameElement du stage,
- celle de tous les ContainerElement du stage,
- celle des éléments actuellement sélectionnés.
- GameStageModel permet également de spécifier des méthodes dites "callbacks", qui seront appelées automatiquement lorsque la sélection change, ou lorsqu'un élément est inséré/déplacer/supprimé d'un conteneur. Par défaut, ces callbacks ne font rien, mais il est possible d'en définir d'autres, spécifiques au jeu.
- Comme les éléments d'un stage varient d'un jeu à l'autre, il faut obligatoirement créer des sous-classes de GameStageModel et leur ajouter tous les attributs et méthodes nécessaires pour gérer l'état du jeu en fonction des règles, notamment les callbacks mentionnés ci-dessus.
- C'est l'objectif de la sous-classe HoleStageModel.
- ATTENTION : pour pouvoir mettre en place des test unitaires, l'instanciation des GameElement d'un stage et leur insertion dans les listes NE SE FAIT PAS directement dans les sous-classes de GameStageModel.
- Pour effectuer ces instanciations, il faut obligatoirement passer par une sous-classe de StageElementsFactory.
- Cette sous-classe doit définir une méthode setup(), qui va faire les instanciation voulues.
- Pour résumer, il faut donc créer une sous-classe de GameStageModel et une sous-classe de StageElementsFactory pour chaque stage du jeu.
- C'est ce qui est fait avec la sous-classe HoleStageFactory.
Reste à définir les attributs et méthodes de ces classes, ce qui doit normalement se faire AVANT de coder. Mais pour cela, il faudrait connaître un peu mieux boardifier-console. Nous allons donc sortir du cadre conseillé et finir la conception parallèlement au développement.