Sorry for the delay !

Thanks to Vero for the translation, I felt really laid-back this time.
Thanks again to Mathieu, Valérie, Laurent and Stephane for their support!

La grande nouveauté, c’est l’apparition de triggers éditables, qui permettent d’associer la case d’une map à une action prédéfinie à l’intérieur du moteur. Je trouvais plus intéressant à long terme de privilégier un système d’actions qui soit totalement indépendant des tiles (graphismes). La position des triggers est placée dans une matrice séparée qui est interrogée à chaque fois qu’un personnage fait halte sur une case. L’intérêt c’est de pouvoir trigger par exemple une action asseoir à partir de n’importe quel modèle de tile (graphisme), que cela soit une chaise, un fauteuil, un canapé, une table … Deuxième avantage et non des moindres, les tiles ne sont pas des objets customs mais se contentent juste d’être de vulgaires symboles destinés à l’affichage. Ce n’est donc pas l’objet que l’on interroge pour pouvoir déclencher une action mais une matrice dédiée qui broadcastera (si une action lui a été assignée aux coordonnées x,y) un message aux éventuels intéressés. Pas besoin de switch pour identifier l’action à appeler, ce serait une perte de process, j’utilise simplement des nombres (identifiants) qui sont concaténés au moment du broadcast à la chaîne Trigger.

Pour l’instant seulement quatre triggers sont disponibles : Trigger1, Trigger2, Trigger3 et Trigger4 qui permettent de sortir d’une map pour aller sur une autre. La classe MapFactory sait que si le Trigger1 est appelé, elle devra charger la map qui se trouve au Nord de celle en cours d’affichage, si c’est le Trigger2 celle à l’Est , le 3 celle au Sud… Et ainsi de suite … Elle calculera dés lors dynamiquement le nom de la prochaine map. Je vous passe outre la nomenclature que j’utilise pour les identifier. Une fois le document XML chargé et parsé elle recherchera un Trigger correspondant pour déposer le personnage en se remémorant la direction d’où il venait. Si le personnage allait au Nord, il sera placé à la sortie Sud de la map suivante dos à celle-ci.

Deuxième nouveauté, le système d’export des données, je n’exporte plus que les cases occupées avec un système de compression en base32, et celles qui sont libres et interdites avec une conversion binaire sur 5 bits passée elle aussi dans la moulinette base32. J’obtiens du coup en sortie un format hyper léger qui brutalise beaucoup moins la bande passante et le processeur pendant les temps de chargement. (C’est fou d’ailleurs comme l’objet XML est gourmand en process au moment du parsing !). Ma classe XmlToObject me sert d’interface pour reconstruire de façon intuitive l’objet map une fois loadé.

Pour résumer, j’ai choisi au niveau de mon moteur un système avec trois matrices par map. Une matrice pour les objets graphiques, une autre pour les triggers et une dernière constituée uniquement de booléens pour accélérer le pathfinding. J’utilise le pathfinder de Grant Skinner que j’ai converti en AS2.0 pour avoir les temps de calculs les plus courts et ne pas surcharger le système ou freezer l’affichage.

Dernier point, chaque objet graphique existe dans deux orientations différentes, les deux dernières sont générées dynamiquement en passant la propriété _xscale en négatif pour un gain de poids évident.

C’est marrant, mais plus le temps passe et plus je m’aperçois que le développement d’Atomic Boarder ressemble au développement d’un vrai jeu à petite échelle, avec ses outils, son moteur, ses retards au niveau des délais qu’on s’était fixé, ses bugs, ses différentes versions, orientations et évolutions … J’ai aussi développé récemment un player pour accompagner l’éditeur. Il permet de tester en deux temps trois mouvements une map à l’aide d’un personnage de son choix. Pour le graphiste qui design les maps, c’est assez pratique.

On devrait ouvrir demain avec une version alpha du moteur d’affichage et quatre maps disponibles. La première version multi-joueurs ne devrait pas tarder non plus, un bon mois (maxi) devrait suffire si je ne m’attarde pas trop à fignoler et enrichir le moteur isométrique de nouvelles features.

De nouvelles perspectives graphiques sont envisagées pour plus tard, on projette de faire une version avec des personnages 3D exportés en bitmap. On a déjà commencé à faire des tests et ça rend plutôt bien.

Je vous tiens au courant…

Je viens de finaliser et finir d’optimiser le moteur graphique, et je dois avouer que je suis assez content même si pour l’instant ne figurent pas encore toutes les fonctionnalités que j’avais prévu au départ comme la gravité ou le séquenceur d’animation pour de futurs bots.

On peut dés aujourd’hui choisir son personnage parmi cinq modéles pour les mecs et trois pour les filles.

Pour ceux que ça intéresse vous pouvez tester l’engin ici en créant un compte (si ce n’est pas déja fait) et en allant dans customize your avatar.

Sous peu, seront disponibles quatre maps dans lesquelles on pourra se promener tout en sifflotant. J’ai terminé l’éditeur la semaine dernière avec un système de compression et serialisation des données qui marche au poil.

Suite au prochain épisode !

Je vous propose de partager aujourd’hui la solution que j’utilise. Elle vous permettra de gérer les profondeurs sans bug d’affichage dans un moteur 3d isométrique animé.

Le concept récurrent pour gérer la profondeur d’un objet dans un tileworld isométrique est d’assigner un z-sorting incrémenté de gauche à droite sur l’axe des x, puis de bas en haut sur l’axe des y comme indiqué sur le schéma ci-dessous :

Ce système fonctionne à merveille tant que l’on se contente du fait que chaque objet se trouvant à une position (x,y) se déplacera sur une case voisine d’un seul jet, sans interpolation de mouvement, autrement dit sans se trouver à un instant t à cheval entre deux cases.
Pourquoi me direz vous ?

Considérons l’exemple ci-dessous :

Un personnage se trouvant à la position 1,1 et voulant se rendre à la position 1,0 va devoir choisir son camp. S’il garde 4 comme profondeur le temps de l’animation pour se rendre sur la case destination, il va passer devant l’objet qui se trouve en 2,0.

S’il choisit de prendre directement sa profondeur d’arrivée (1), il sera le temps de son trajet affiché derrière l’objet se trouvant en 2,0.

On est confronté au même probléme dans le sens inverse comme vous pouvez le remarquer :

La plupart des moteurs utilisant ce système réussissent à tricher en jouant sur la taille des objets à l’intérieur des cases et sur l’instant ou la valeur z-sorting de l’objet en mouvement est modifiée. Mais ces solutions au bout du compte ne sont vraiment pas satisfaisantes pour gérer l’affichage de façon propre et logique.

D’où l’idée d’opter pour une organisation comme celle-ci, avec un z-sorting incrémenté en diagonales :

Cette fois-ci les animations sur l’axe des y peuvent-être gérées sans bug d’affichage :

Mais les esprits judicieux auront remarqué que le probléme est maintenant répercuté sur l’axe des x :

Sans plus attendre, voici la solution finale, le même tableau mais avec des intervalles en dizaine :

Hum … Quoi de mieux me direz-vous ?
L’idée est d’incrémenter de 15 la profondeur d’un personnage voulant se déplacer vers la droite sur l’axe des x (50 dans l’exemple devient 65) et de lui donner à la fin de son parcours la profondeur de la case d’arrivée (80 dans l’exemple ci-dessous) :

Même chose dans l’autre sens, on enléve 15 à la profondeur d’un personnage voulant se déplacer vers la gauche sur l’axe des x (50 devenant 35 dans le cas précis) et on lui attribue à la fin de son trajet la profondeur de la case destination (il passe donc de 35 à 20 en profondeur une fois arrivé) :

Dernier point, quelle méthode utiliser pour calculer la profondeur d’un objet en connaissant la largeur et la hauteur de la grille ainsi que sa position x et y ?
C’était le sujet d’un précédent thread, et je remercie Didier d’avoir trouvé une solution très élégante et rapide pour gérer cette problématique.
Voici le code que j’utilise :

 private function _sum(n:Number) : Number {

         return (n * (n + 1) / 2);
    }
 
   public function calculDepth(x:Number, y:Number) {

         var r:Number = _sum(x + y) + x + 1;
         r = ((x + y) > (grid.x-1)) ? r -= _sum(x + y - (grid.x-1)) : r;
         r = ((x + y) > grid.y) ? r -= _sum(x + y - grid.y) : r;
         return (r*10);
    }

Voila, j’espère que le concept que j’ai développé et utilise couramment pourra contribuer à remplir un peu le vide auquel je me suis confronté lors de mes investigations sur le sujet.

Je tiens à remercier tout particulièrement Joan pour ses idées et Didier pour son algorithme de calcul remarquable ainsi que Jean-Louis pour la conversion en AS.
Comme d’habitude, vos questions, commentaires ou critiques sont les bienvenue.

Je ne peux résister à l’envie de vous faire partager une petite preview contenant sept skins au total.

Utilisez les numeric steppers pour modifier les différentes parties du corps, la barre d’espace pour alterner les animations marche et arrêt, et enfin les fléches Gauche et Droite pour faire tourner le personnage.

[kml_flashembed movie="http://www.tweenpix.net/files/avatareditor.swf" width="350" height="250"/]

Le modéle aini que l’affichage sont entièrement dynamiques et vont nous permettre d’ajouter animations et skins à volonté.

J’ai adopté le pattern design : adapter. Les adapters sont utilisés pour permettre aux objets de communiquer avec différentes interfaces.
Dans mon cas précis, l’écouteur clavier (à chaque touche pressée par le joueur) envoit les infos à l’adapter. Suivant la configuration l’adapter s’occuper de formatter différemment les données avant de les envoyer à la méthode move() de mon personnage.

J’ai ajouté un écouteur sur la barre d’espace permettant de switcher entre l’ancienne et la nouvelle configuration de touches.

J’espère que ces modifications permettront de rendre le jeu plus agréable pour tous ceux qui avaient des difficultés avec l’orientation du personnage.

Je suis responsable du développement AS et PHP sur ce projet. Un premier jeu est disponible : Atomic Sokoban. C’est un remake isométrique de l’incontournable jeu de réflexion avec quelques fonctions bonus comme la sauvegarde et gestion des replays.

N’hésitez pas à me laisser vos commentaires ou me signaler d’éventuels bugs qui se seraient glissés entre les mailles du filet.

Pour les plus curieux, screenshots et artworks sont disponibles dans la section pictures du portail.