Avant de commencer le développement, il convient d'aborder les principales différences entre les deux versions du framework boardifier.
Pour la partie modèle, les classes sont identiques à l'exception de la méthode update() de GameElement dont les paramètres changent : update(double width, double height, GridGeometry gridGeometry). La valeur de ces paramètres est directement fournit par le contrôleur général, lorsque le modèle est mis à jour à chaque frame. Ces 3 paramètres correspondent à la taille en pixel de l'élément, et un objet donnant la géométrie visuelle de la grille (taille des cellules en pixel notamment) si l'élément est dans une grille. Normalement, en MVC le modèle n'a pas accès aux informations relatives au visuel mais il y a des exceptions. Par exemple, s'il faut déplacer un élément dans l'espace, il est parfois nécessaire de connaître sa forme et/ou la forme de la grille dans laquelle il se trouve pour savoir si le déplacement est possible. Dans "The Hole", ce genre de cas n'existe pas, mais comme boardifier est fait pour être général, ces exceptions sont prévues.
Pour la partie vue, presque toutes les classes sont différentes puisque c'est Javafx qui est utilisé pour faire le rendu visuel. En revanche, les principes généraux de création du visuel ne changent pas beaucoup par rapport à boardifier-console :
- La vue générale est représentée par la classe View, que l'on va instancier dans la classe principale (celle de main() ), en fournissant le modèle en paramètre. On peut cependant créer une sous-classe, afin de définir une barre de menu spécifique pour le jeu à implémenter.
- Le "panneau" principal de dessin, sur lequel vont être placés les éléments visuels (les looks) est représenté par la classe RootPane, qui hérite de la classe Javafx Pane. Le contenu par défaut du RootPane est un fond gris et un texte basique, qui peuvent servir de panneau d'introduction, avant de lancer une partie. Si l'on veut changer ce contenu par défaut, on crée une sous-classe et on redéfinit la méthode createDefaultGroup() (cf. ci-dessous).
- Les looks sont définis grâce aux sous-classes existants de ElementLook, ou bien en en héritant. La différence est que les looks sont créés grâce aux classes Javafx telles que Rectangle, Circle, Text, ...
- Pour chaque stage du jeu, on crée une sous-classes de GameStageView, afin de créer et stocker les éléments visuels (les looks) du stage. La différence est qu'il faut créer des looks avec des tailles en pixels au lieu de caractères.
Pour la partie contrôle, il y a également des différences notables avec le mode console, notamment afin de gérer les mouvements des éléments graphiques et les interactions utilisateur grâce au clavier/souris. De ce fait, on a :
- un contrôleur de l'animation : c'est lui qui va contrôler le temps qui passe et qui va régulièrement demander au contrôleur global de "mettre à jour" le jeu. Ce contrôleur n'a jamais besoin d'être redéfini.
- un contrôleur du clavier : par défaut il ne fait rien, mais on peut créer une sous-classe pour détecter l'appui sur certaines touches.
- un contrôleur de souris : par défaut il ne fait rien, mais on peut créer une sous-classe pour faire des actions en fonction de clic ou déplacement souris.
- un contrôleur des actions : par défaut il ne fait rien, mais on peut créer une sous-classe pour faire des actions lorsqu'un élément graphique de javafx (bouton, case à cocher, menu, ...) est cliqué.
- un contrôleur global : il contient presque tout ce qui est nécessaire pour mettre à jour le jeu, mais il faut obligatoirement créer une sous-classe pour pouvoir instancier les sous-contrôleurs énoncés ci-dessus, et définir ce qui se passe quand un joueur a fini son tour, ou bien quand un stage est terminé.
La dernière différence concerne les animations et la classe ActionPlayer. Elle est différente du mode console, puisqu'elle ajoute la possibilité de "jouer" des animations à l'écran, pour représenter une action de jeu.
La super classe (dans le modèle) représentant les animations est Animation mais ce sont ses sous-classes qui sont réellement utilisables.
|
ATTENTION : Animation et ses sous-classes ne contiennent aucune instruction permettant de modifier directement la vue. Ces classes servent uniquement à stocker des informations sous la forme d'objets AnimationStep, qui seront utilisés pour modifier l'état d'un élément, par exemple sa position dans l'espace. Comme dit auparavant, la modification de l'état de l'élément entraînera une mise à jour automatique de son visuel, ce qui produira un effet visuel d'animation, par exemple de mouvement. |
Animation ne contient que ce qui est nécessaire à toutes les animations, c.a.d des attributs représentant la durée de l'animation, une liste d'objets AnimationStep contenant les "pas" de l'animation, et un callback qui sera appelé à la fin de l'animation (par défaut ne fait rien).
AnimationStep est une simple "enveloppe" pour une liste de nombres à virgule. Les valeurs que l'on met dans cette liste dépend entièrement de ce dont on a besoin comme information pour représenter l'animation. Par exemple, pour une animation du type mouvement, cette liste va contenir les coordonnées x,y de l’élément à déplacer à un pas donné le l'animation. Si on veut faire changer l'apparence d'un élément, la liste va plutôt contenir l'indice d'une des apparences possible de l'élément (cf. DiceElement).
A l'heure actuelle, gamifier ne propose qu'un nombre limité d'animation, basées sur un changement soit de position, soit d'apparence. Il y a ainsi :
- MoveAnimation : prend en paramètre des coordonnées de départ et d'arrivée dans l'espace. La liste d'AnimationStep ne contiendra que 2 pas, avec ces coordonnées. Cela provoque une animation de type téléportation.
- LinearMoveAnimation : idem que MoveAnimation mais en spécifiant un vitesse ou un temps de déplacement. La liste d'AnimationStep est remplie avec autant de pas que nécessaire pour respecter le temps ou la vitesse. Chaque pas contient des coordonnées dans l'espace, qui sont sur la ligne reliant le point d'arrivée et de départ.
- FaceAnimation : prend en paramètre la liste des indices d'apparence que doit prendre l'élément., ainsi que le temps en ms entre chaque changement d'indice.
- CyclicFaceAnimation : idem que FaceAnimation mais en faisant une boucle dont la longueur est donnée en paramètre.
| ATTENTION : on ne crée généralement pas directement une instance de ces classes. On utilise plutôt un objet Action qui va contenir une Animation représentant l'action. Ce sera ActionPlayer qui lancera automatiquement l'animation. Par exemple, lorsqu'un pion doit se déplacer d'une case à une autre, on peut associer à une action de jeu instance de MoveAction une animation de type mouvement linéaire LinearMoveAnimation. |