Catégorie : HeroQuest

Comme vous l’aurez compris j’ai ajouté un coffre au trésor dans le set d’objet actuellement disponible. Mais pourquoi ?

1. 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.
2. Rien n’a été mis en place pour le changement d’animation.
3. 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 :

1. Le coffre s’initialise avec l’état fermé et l’animation « fermé ».
2. 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.
3. 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 ».

C’est l’histoire d’un clic, qui n’avait rien de particulier, mais était destiné à de grandes choses. Il ne le savait pas encore, mais il allait bientôt vivre un grand moment et constater les conséquences de ses actes.

C’est l’histoire d’un clic, droit comme un pique, sur une porte, droite elle aussi, qui pouvait en un même instant faire bouger un caddie, un peu bancale lui, et demander une interaction qui elle allait dans tous les sens.

Cette histoire chers amis, c’est une conclusion, en terme de preuve de concept (POC), qui dure maintenant depuis plusieurs semaines. On y est enfin, la boucle est bouclée et voici l’explication finale.

Pour vous donner cette explication je vais procéder de manière chronologique en séquences. Ceci dit, je ne vais pas me priver de quelques détails. À cela j’ajoute que j’ai opté pour la solution HTML du menu et que ça nous a réservé quelques surprises.

Tout commence par un clic droit, notre isoPlayer (de type isoScene) reçoit l’événement, on détecte le bouton droit et on tente de déterminer sur quoi on a cliqué (le fameux Raycasting). On trouve un Element (ou rien et ça s’arrête là), on lui demande ses coordonnées (oulala…), on dit au Hero que c’est en fonction de cet Element qu’il va s’orienter, puis on attaque la partie déplacement en fonction des coordonnées reçues. On termine par préparer une surveillance de quand il arrivera à destination.

Excepté si le Hero est déjà sur place, nous patientons un instant et on nous rappelleras quand il y sera. La fonction de surveillance sera appelée et dedans, tout simplement, on informe les intéressés, qu’un événement de menu d’interactions a été déclenché, en lui passant les informations recueillies de notre Element cible : coordonnées du bloc à l’écran et la liste des interactions disponibles.

Nous venons de parler des intéressés, c’est à dire ceux qui se sont abonnés à l’événement du menu d’interactions. Petite modification dans notre composant Player (celui qui englobe le rendu et le point de départ de Game), nous avons créé et ajouté un composant InteractionsMenu, dont le but est d’afficher une liste de verbes et de prévenir quand on a cliqué dessus. Notre composant Player s’est abonné et va donc recevoir l’événement dont on a parlé fin du paragraphe précédent.

Du coup que se passe-t-il ensuite ? IsoPlayer est prévenu et peut à son tour préparer une variable à destination du composant InteractionsMenu, qui à son tour va pouvoir s’afficher selon les coordonnées écrans avec la liste données. Jusque là, tout est comme annoncé.

Petit commentaire sur la liste des verbes, bien sur il y a 2 verbes pour une porte, « open » et « close » (actuellement dans notre POC), mais selon l’état actuel de la porte le menu n’affiche que ce qui est disponible.

Vient ensuite le choix du menu, ici il n’y en a plus qu’un vu le filtre cité juste avant. Le composant InteractionsMenu a une sortie sous forme d’événement à son tour. Vous cliquez, il informe ses abonnés, dans le cas présent : le composant Player, qui à son tour, quand déclenché, masquera le menu et demandera à IsoPlayer de gérer l’action.

Pour ce POC, et vu que nous n’avons qu’une porte, la gestion se fait au cas par cas et selon l’état. Donc, de quel type est l’Element ciblé, et en fonction du verbe reçus on contacte la bonne méthode pour lui demander de changer d’état. En interne, c’est à lui de se gérer et mettre sa liste d’interactions à jour.

Nous voilà donc avec un boucle bouclée, un clic est à l’origine du ciblage et nous affiche un menu d’interactions disponibles, on choisi et c’est reparti, on remonte la chaîne pour agir sur l’Element.

Ceci est bien sûr un premier jet, fonctionnel certes, du côté implémentation de TARS (usage de la librairie), mais on peut se poser quelques questions et y voir déjà des choses à régler ou à faire évoluer. Enfin, ceci sera surtout vu au cas par cas tout au long de notre chemin pour nous rapprocher du projet HeroQuest.

Mais du coup, maintenant que ce grand challenge a été relevé, c’est quoi le suivant ? Bonne question, mais je pense que l’éditeur reste la suite logique. C’est à dire, l’édition de la carte, une gestion différente de la souris et de la caméra, un menu interactif pour la gestion du catalogue et interagir avec un Element sélectionné. Il me reste à découper ça en phase et à trouver par où attaquer ^^.

Tel un tube disco et des déhanchés sur le « dance floor », c’est l’euphorie du clic à présent ! La séparation clic gauche pour le déplacement et le droit pour l’interaction (avec déplacement si besoin et possible) est fait, et ce n’était pas une sinécure !

Dis comme ça, vu qu’on avait déjà les 2 fonctionnalités, rien de neuf sous le soleil mais cela a soulevé des questions, qui ont soulevées la mousse des rochers du début de projet et créé un vrai bordel et remises en question.

Nous en revenons au Raycasting (détecter un objet quand on clique dessus), car désormais nous avons un GridBlock à gérer et ses 7 zones. Nous ne parlerons pas du besoin de séparer le côté spécifique des 7 zones avec un GridBlock générique et dont les IsoScene devront prendre la gestion à l’usage, c’est connu et ça attendra une prochaine version une fois que la poussière du champs de bataille sera retombée.

Le cycle est le suivant :

• Cliquez (quel bouton ?) droit sur un arbre ou un mur.
• L’IsoPlayer prend l’événement, détecte le clic droit et demande quel est l’élément « Raycasté » (on dira ça ainsi, ou touché par le lancé du rayon sacré venant de la sainte souris…).
• Celui-ci demande alors au service Iso de s’en occuper et plus vite que ça !
• Le service parcours le subsetMap, et demande à chaque GridBlock de faire de même pour les Elements.
• Du coup le GridBlock demande à ses zones de consulter chaque Element et de voir s’il y a contact.
• Oui / Non : l’histoire nous le dira !

Première remarque, la manière dont on parcours le subsetMap, on partait de la coordonnées du joueurs et on recalculait ses dimensions pour faire une boucle, je simplifie, mais pas bien du tout ! Après 2 efforts, et surtout l’idée que la grille n’est pas carrée mais un losange, on retiendra que pour chaque colonne et ligne de cette grille on cherche le minimum et maximum afin de la parcourir efficacement et sans artifice inutile.

Notez également qu’un tableau ne peut avoir d’index négatif, ceux-ci seront considérés comme des propriétés (‘-‘ étant un caractère au final) et du coup un forEach, length, etc. ne sont d’aucune aide, privilégiez le « for … in » alors. Ceci dit, nous avons décidé de ne pas les gérer, ce qui permettra une forme d’optimisation.

Ensuite, nous avons le niveau de GridBlock qui doit orchestrer le parcours des zones dans le sens inverse de l’ordre de dessins pour tester le Raycasting. Encore une fois, il faut faire attention à ne pas se répéter inutilement et surtout mettre le bon code au bon endroit, GridBlock ne doit que gérer ses zones. Ainsi, après un petit « refactoring » (refonte), on a une fonction de calcul de hauteur d’une zone (car le Raycasting travaille à l’envers du dessin), une fonction de détection par zone (en demandant à chaque Element si ça touche :p) et la fonction d’orchestration principale pour gérer l’ordre des zones et l’ensemble de l’opération. C’est ce qui m’a pris du temps à rendre joli.

Un code laid n’est pas un bon code

À cet instant, chaque zone est bien ordonnée, testée et aucun code n’est dupliqué. C’est élégant, fonctionnel (surtout) et avec cette refonte, un horizon de généricité se dessine.

La méthode a été reportée sur la fonction de dessin qui souffrait des mêmes manques. On peut donc imaginer avec plus de facilité sa prochaine version, son évolution, comme dit en début d’article.

Après une, deux, semaines, nous revoilà au début de notre schéma pour obtenir l’interaction, point 1) le clic sur l’objet concerné.

Notre but reste un clic sur la porte, faire apparaître un menu quelconque et modifier son état ouvert/fermé. À partir de là on ouvre beaucoup de possibilités à explorer et en découvrir les limites, à repousser toujours plus loin.

En parlant de menu, une question se pose, profiter du HTML à notre disposition ou définir une interface dessinée. La première existe déjà et aura ses avantages / inconvénients, la seconde est a créer de toutes pièces et permet donc une maîtrise complète (événements, animation, éléments inexistant en HTML, etc.) mais demandera beaucoup plus de temps à concevoir.

Enfin, avant de penser à ça, nous allons devoir définir ce qu’est une interaction, lesquelles sont possibles, comment les récupérer et les définir. Un beau challenge encore. 🙂

Je suis … Traversable !!! Comme un fantôme ! Ou du moins comme une porte :). Exactement, une porte, ce sujet qui nous tracasse depuis qu’on a des murs.

Mais qu’est-ce qu’une porte ? C’est un Element, qui se situe au niveau d’une zone de mur et à qui le pathfinder doit poser la question si oui ou non on peut passer ce « mur ». Il doit donc demander s’il est Traversable.

Côté technique il y a 2 aspects : étendre Element au travers d’une classe Door et définir une interface Traversable ainsi qu’une astuce typescript, une fonction dédiée instanceOfTraversable (car nativement on ne peut tester si une classe étend ou non une interface).

Ne pas oublier que pour ce faire nous avons également ajouté les images, les définitions dans les fichiers de ressources et modifié le générateur de map pour notre POC comme précédemment, petit rappel.

Pour les codeurs qui chercheraient de l’aide sur le sujet des interfaces voici comment s’y prendre :

export interface Traversable {
  isTraversable(): boolean;
}

export function instanceOfTraversable(object: any): object is Traversable {
  return 'isTraversable' in object;
}

Ainsi notre DoorElement basé sur Element nous permet d’utiliser cette interface et de répondre à la question. Notez que la question n’est pas posée par le pathfinder lui-même mais par la fonction de validation qu’on lui donne. Ceci reste donc côté implémentation comme désiré.

Comme vous pouvez le remarquer on a bien notre porte… enfin 2 !

Mais qu’est-ce qui a bien pu se passer ? Ben en fait c’est tout con, première règle élémentaire de la Robotique de notre moteur TARS, tout est empilé ! Et quand Element reçoit des spritesRefs multiples, il stack naturellement, jusqu’à ce qu’on surcharge sa classe et sa méthode draw() pour changer tout ça :). Et c’était prévu, mais, car il y a un mais, il y avait moyen d’améliorer l’accès à la fonction de dessin individuel.

Dans notre cas nous avons 2 sprites chargé pour un DoorElement, ouvert et fermé (ah ben bravo !). Nous ajoutons un statut à la porte, on en profite pour faire une interface surchargeant SceneElement pour les config et un « enum » pour structurer Open et Closed comme valeur possible du statut de la porte, le tout rendant l’objet porte bien structuré quand on veut en ajouter une.

Enfin, suivant le statut, un seul Sprite sera affiché et grâce à la fonction drawOne() qu’on a ajouté, le tout est rendu plus simple.

Actuellement il n’y a pas encore d’interaction, donc la vidéo ci-dessus est illustrée par 2 compilations distinctes.

Ce qui nous amène à une observation, l’eau ça mouille… et les arbres cachent la case derrière eux (en NE), du coup le raycasting actuellement utilisé au déplacement de la souris, ne permet pas aisément de sélectionner la case visée, il faut aller sur le bord de l’arbre sur 1-2 pixels.

Après réflexion, vu qu’on tend à implémenter les interactions, à revoir cette gestion de la souris. Ceci vous étonnera surement, mais elle a plusieurs boutons, la souris. On pourrait donc en utiliser un pour se déplacer, sans raycasting, juste un survol des cases, et un autre pour tenter d’interagir, si la cible le permet.

Il y aurait également la réflexion sur le curseur qui serait caché, car son rendu se fait au moment de sa case, et si un mur ou un arbre le masque, vous ne savez pas vraiment où il est si vous n’avez pas suivi. On pourrait imaginer un postDraw (un rendu d’après), permettant alors de se redessiner après tout, sous une forme allégée, comme un contour en transparence ou surbrillance. Il faudra également savoir qui a besoin de ce postDraw, pour éviter de parcourir à nouveau l’ensemble du subsetMap. Soit par préenregistrement, au moment de l’init du subset par exemple vu qu’on parcours la map, ou au moment du rendu vu qu’on passe dessus également. C’est peut-être cette dernière piste que je regarderais.