Comme vous l’aurez compris j’ai ajouté un coffre au trésor dans le set d’objet actuellement disponible. Mais pourquoi ?
- Nous n’avons rien qui teste le système d’animation depuis qu’il a été créé, et le « target » en vague bleue était l’animation principale.
- Rien n’a été mis en place pour le changement d’animation.
- Un problème de boucle se soulève en imaginant l’ouverture du coffre, actuellement toutes les animations sont bouclées.
Mais d’abord il faut le dessiner, dans les 4 directions, l’animer, ce qui est une autre sinécure et enfin en faire des Sprites NESW. Là il n’y a pas d’outils actuellement dans mes mains, rien de facile, gratuit pour les POC. Cependant j’ai trouvé un script (Layer2SpriteSheet) un peu bancale mais qui m’a bien aidé. C’est pour Adobe Photoshop et ça utilise vos calques pour générer votre Sprite final.
Et voilà un coffre que je vous anime ci-dessus. Ça c’était la partie facile, même si ça m’a déjà pris quelques heures de chipotages. Maintenant il faut l’intégrer au POC HeroQuest/TARS. Donc comme d’habitude on manipule la bibliothèque en précisant les images NESW, les 4 animations disponibles et les dimensions des images, on édite la liste des Elements disponibles, on ajoute une DTD (définition) pour ce qu’est un « Treasure », donc la coordonnée d’interaction, les interactions disponible comme pour la porte et pas de référence de Sprite spécifique, celui par défaut convient très bien.
Jusque là c’est nickel, j’ai juste dû corriger quelques typos dans mes modifications et ça roule, mais comme on a un objet avec lequel on peut interagir et même si c’est IsoPlayer qui fait la réaction des interactions pour le moment, il va nous falloir un objet spécifique : TreasureElement. En gros c’est la copie d’une porte pour la partie interaction et on retire la gestion multi-sprite au profit de l’usage du sprite par défaut.
Pour rappel, le Sprite par défaut, est l’image ou la somme d’image composant l’ensemble des possibilités d’animations de l’objet. Avoir plusieurs Sprites au sein d’un élément est une construction dynamique, une volonté spécifique pour obtenir un résultat dynamique qu’un Sprite ne peut offrir.
Nous voilà donc avec notre classe TreasureElement à laquelle on va déplacer la gestion des interactions en son sein au lieu de IsoPlayer, c’est quand même IsoPlayer qui l’appelle, mais la partie spécifique est du côté spécifique, meilleure séparation et clarté du code. Nous avons donc une méthode « doInteraction », comme dans IsoPlayer, avec les mêmes paramètres etc. qui va nous permettre de faire les tests de cas en fonction du verbe reçu.
C’est bien joli, mais l’animation dans tout ça ? On y arrive enfin, on a 4 animations : ouvert, fermé, s’ouvre, se ferme; et voici le schéma qu’on aimerait mettre en place :
- Le coffre s’initialise avec l’état fermé et l’animation « fermé ».
- Je clique pour interagir avec le coffre et choisi de l’ouvrir : on lance l’animation « s’ouvre » et on aimerait qu’après ça passe en « ouvert » et que ça reste ainsi.
- Je clique pour interagir avec le coffre et choisi de le fermer : on lance l’animation « se ferme » et on aimerait qu’après ça passe en « fermé » et que ça reste ainsi.
Je ne revient pas sur le fonctionnement de l’interaction, il vous suffit de lire l’article précédent. Donc nous en sommes à recevoir l’action « ouvrir » et on souhaite changer l’animation courante. BIIIIP faux départ ! Cette fonction n’existe pas.
Premier problème rencontré, rien n’a été prévu pour changer l’animation. Je vous passe toutes les réflexions, j’ai ajouté dans Element une fonction setAnimation dont le but est de manipuler la collection des animations et mettre les paramètres dans les bonnes conditions (nom de l’animation, timing, frame courante).
J’ajoute directement ici qu’après réflexions sur les améliorations utiles, le fait de pouvoir attendre la fin d’une animation est très intéressante. Que ce soit d’être prévenu tout simplement par un événement auquel on peut s’accrocher, mais également en interne, initier le changement d’animation en attendant la fin de la précédente, on crée alors en interne l’attente de l’événement et on change alors les mêmes paramètres comme dit avant.
Maintenant que la possibilité existe on peut demander notre changement d’animation suite à l’interaction. Il nous reste à utiliser également l’événement de fin d’animation pour appliquer le changement d’animation vers les « animations » fixes « ouvert » ou « fermé ».
À cela, j’ajouterai que j’ai prévu un paramètre d’animation « loop » qu’il me reste à implémenter pour définir qu’une animation ne boucle pas forcément. On arrêterait ainsi l’animation avec un « flag » (drapeau d’état) et ainsi ne pas boucler sur la dernière image et envoyer X alertes d’événement de fin.
Pour simplifier, parmi les 4 animations citées, nous pourrions supprimer « ouvert » et modifier l’animation « s’ouvre » avec le « flag » « loop » à « false » (non), elle resterait ainsi sur sa dernière image, sans chercher à poursuivre et nous n’aurions qu’une seule fois l’alerte de fin d’animation. Ceci nous économise une définition d’animation et plus de facilités pour l’avenir.
Petite anecdote, j’avais défini tous mes changements d’animation en demandant d’attendre que l’animation courante se termine avant de changer, mais du coup mon coffre s’ouvrait ou se fermait 2 fois avant de rester dans son état ouvert ou fermé. Mais pourquoi ? En fait, en faisant ça, au moment où l’animation se termine, l’événement nous alerte et on lui demande de changer d’animation quand elle sera finie, mais l’événement vient de passer, du coup il relance l’animation une seconde fois. Vu que nous sommes déjà dans l’état de fin, il ne fallait donc pas utiliser « l’attente de fin » encore une fois. Ça vous évitera beaucoup de recherches inutiles.
Tout ceci commença une dizaine d’heures plus tôt en dessinant un personnage pour remplacer notre ami le caddie dans le même objectif de manipuler les animations. Ce que je vais faire suite à ceci ainsi que coder le paramètre « loop ».