Isométrie et rapport exotique.

Salut à tous,

Le titre est antinomique, car dérivé du langage populaire qui confond perspective isométrique et perspective dimétrique, sans parler de la perspective trimétrique.

Ceci dit, le langage populaire parle d'une vue pseudo 3D, rarement d'une perspective axonométrique, que doit normalement connaître, un dessinateur industriel.

En réalité sur un écran PC, l'isométrie n'existe pas, puisqu'il est impossible d'avoir trois lignes parfaites (pixel art), à partir de trois angles à 120°.

Manquant cruellement de vocabulaire et de grandiloquence, je vais essayer néanmoins, de partager mon peu d'expérience concernant le déplacement d'un personnage (sprite), sur une carte dite "isométrique".

Le rapport le plus utilisé est le rapport 2:1, cela se traduit graphiquement par une ligne parfaite, soit 2 pixel sur l'axe X et 1 pixel sur l'axe Y.

Un rapport exotique est généré lors de la réalisation de ressources graphiques, souvent via un logiciel 3D.

Le rapport 4:3 s'applique aux ressources graphiques Reiner, Reiner étant le nom de l'auteur des tuiles "isométriques" encore disponibles de nos jours sur la toile.

Gérer ce rapport exotique, passe par le mapping (réalisation de la carte) et le Klik coding (pseudo langage de programmation MMF).

Comment trouver le rapport à partir de la taille de la tuile?
Il suffit de diviser, jusqu'au plus petit nombre premier.

Taille de la tuile de base 64x48 pixels.
64/2=32, 32/2=16, 16/2=8, 8/2=4.
48/2=24, 24/2=12, 12/2=6, 6/2=3.



Le mieux est de mettre au point le moteur de déplacement à partir d'une phase schématique afin de résoudre, toutes les problématiques liées à la réalisation de la map "isométrique".



Un exemple de moteur de déplacement libre, 4 directions pour PJ de 10 lignes avec gestion des plans, à décortiquer.
http://cjoint.com/13dc/CLmxlEJnVJk_sprite_on_axometric_map.zip

Les tuiles Reiner au format mfa.
https://www.dropbox.com/s/zipe8pqlb9iliag/Reiner_mfa.zip

Merci de votre attention.

Cordialement Kloug.

Salut à tous et toutes,

Aujourd'hui, il est temps de se pencher sur le cas du moteur déplacement libre "isométrique", 8 directions pour un personnage joueur, avec gestion des plans.

Vous pouvez galérer longtemps, sur la principale problématique que pose ce moteur, à moins d'avoir la notion touches en attente.

Cette notion rappelle, qu'un programme doit se soumettre au matériel informatique, notamment le clavier.

En gros à moins d'être un virtuose, impossible d'envoyer en même temps, deux signaux différents à un ordinateur, pour lui c'est trop compliqué à décrypter.

Un guitariste peut-il plaquer deux accords sur le manche, en même  temps?
La réponse est non même si on s'appelle Manitas des Platas.

L'astuce consiste à passer par un testeur de clavier, un objet actif "Testeur" avec le mouvement huit directions.

"Testeur" à une vitesse supérieure à zéro, ajouter 1 au compteur "Key wait".

"Key wait" a une valeur supérieure à deux, alors seulement prendre en compte la direction de "Testeur".

Le principe est donc hyper simple, on laisse s'écouler du temps avant de tenir compte de l'activité du joueur, en particulier la direction souhaitée par ce dernier.

L'astuce "Testeur" d'activité du joueur, évite de mettre en place un système de variables ou autre, du genre fastidieux.

Elle permet donc de se lancer rapidement dans une batterie de tests, afin de finaliser au mieux le moteur de déplacement isométrique.

La deuxième problématique concerne la gestion des plans, sur une map tile par tile, il y a l'objet calque, merci Clickteam. Sur une map couche sur couche, évidemment cet objet est à ranger au placard.

La troisième problématique, la vitesse de déplacement du PJ, elle doit être logiquement la même sur les droites (N.S.E.W) et les diagonales (NE, NW, SE, SW).

La vitesse de déplacement ne se règle pas avec le rapport 4:3, rapport qui s'inverse lors d'une montée d'escaliers donc 3:4.

Certains moteurs de déplacement "standard" proposés sur la toile, me font beaucoup rire, pour diverses raisons.

Une vitesse constante, s'obtient avec un mouvement balle qui rebondit, ou le timer par exemple.

Quatrième problématique la gestion des collisions.
Utiliser un actif avec un mouvement statique évite les mauvaises surprises, les bugs inhérents à un mouvement intégré TGF, MMF ou CTF 2.5.

A moins bien sûr, d'aimer rajouter des lignes et des lignes à son programme.

Donc récapitulation, pour un compromis acceptable pour un débutant, un testeur d'activité, un "key wait", une base (où se fixe le PJ) mouvement statique, dont le déplacement est géré par le Timer.

Et voilà pour la synthèse.

Exemple d'un moteur de déplacement libre "isométrique", 8 directions pour un personnage joueur, avec gestion des plans.
Soit 13 lignes à décortiquées.
https://www.dropbox.com/s/4h8eggl28lku1eq/Sprite%20on%20axometric%20map_8D.mfa

Pour le fun le "vieux" moteur de déplacement 8 dir, avec plusieurs vitesses sur une map iso:
"This is a fun example to play around with. You can even change characters. Elaborate. From a more modern tgf file dated March 2010."
http://castles-of-britain.com/isospeed.mfa



Pour le fun, pour le fun, enfin presque parce "la solution" proposée est à reprendre non pour le PJ, mais pour le moteur de Tir.

Un barbare balance une hache, le projectile doit longer les diagonales, donc les "murs" forcément, sinon cela souligne un certain amateurisme, pour ce faire, avec un objet actif, mouvement balle qui rebondit, rectification du déplacement sur les diagonales, l'astuce passe via un compteur, si je ne perds pas trop mes neurones.

Hé oui! Je suis le cliqueur qui balance des solutions de manière détournée, afin de voir si quelqu'un, quelque part, capte quelque chose, à mes explications et mises en pratique "roxxor" (humour).

Nivram, my engine is a joke, why fun?
J'ai essayé de le dire sur un autre forum, mais je manque de compétences linguistiques.
Comment signaler à un modérateur que la gestion des collisions est mauvaise, qu'il déplace un PJ, avec un moteur de tir?

Le mieux est d'attendre un éclair de lucidité, de sa part...
T'as raison Gaston, je suis très en colère parce qu'on pompe mes exemples.
Il est vrai qu'il est difficile de détecter mes jeux de mots (blagues), gros comme un nez au milieu de la figure.



Le problème "insoluble", dessiner des tuiles sans dessiner, il suffit de faire de l'assemblage et des captures d'écran.
Il y a des fois, MMF me fait retomber en enfance, vite lancer Gommettes version A, en souvenir de Gommettes version (gros) béta, qu'hélas un jour, quelqu'un a osé télécharger (MDR), j'ai oublié son pseudo par respect pour son travail, quand on cherche un "master"...



En tant que "spécialiste" de l'iso, quel est mon avis sur le moteur de déplacement libre?

Il a des défauts liés à sa nature, gestion des collisions et des plans, plus difficile qu'avec un moteur de déplacement case par case, surtout avec un rapport exotique, néanmoins une "parfaite" gestion des plans peut être atteinte, à l'aide de couches dédiées, domaine du mapping, donc nécessite une stratégie mapping.

Évidemment le moteur de déplacement case par case, est plus "hard" au départ, niveau mise au point, mais ceci est une autre histoire.

A+++

Edit:
Gommettes version A
https://www.dropbox.com/s/4t6mi9c5pcvq938/GOMMETTES%20VERSION%20A.zip?dl=1

Notez que je manque de courage, pour mettre un lien vers Gommettes version béta (open source).
Enfin si quelqu'un insiste...

A titre indicatif, il existe aussi le tile iso pousse rapiere:
http://pousse.rapiere.free.fr/tome/tiles/DO/tome-doterraintiles.htm

Taille du tile 54x27 pixels, 27 étant indivisible par 2, quel est le rapport "iso" pour le moteur de déplacement?

Je ramasse les copies dans une heure (lol).

Merci Kloug (alias SpringUp) pour cet exposé très complet  :bravos

Merci Volgot pour ton encouragement. C'est trop  8)

Mais hélas mon "exposé", n'est pas terminé, le sera t-il un jour?

Il est grand temps d'étudier, le moteur de déplacement case par case avec un rapport isométrique exotique.

Auparavant, un flashback, vers une époque troublée, où on m'a reproché de donner des solutions "parfaites" aux débutants.
Étant un être délicat et hyper sensible, cela a été un tel choc que ma production d'exemples est devenue "exemplaire" (expéditive).

Il y a des séries de tutoriaux, marquées à jamais par mes fautes de goût.

D'ailleurs, un sentiment de honte ne me quitte plus, le pire a été un moteur de déplacement case par case "iso".
L'exemple proposait un barbare lançant sa hache sur une araignée zigzagante, le délire indétectable d'un "master".

"Little Boy 05" se distingue, grâce à un déplacement case par case rectifié, et un tir qui ne respecte pas franchement les diagonales.

Deux choses à ne surtout pas reproduire.

Sorti d'un HDD fumant, de la série "Little boy" l'exemple "Freemaker Engine", plus frit que ça, c'est carbonisé.
https://www.dropbox.com/s/6i390bgwdygp3tl/LittleBoy05.zip

Heu! Pourquoi une piscine?
Pour sauter à pieds joints et toucher le fond (MDR).


Après cet intermède qui souligne, que télécharger, c'est prendre le risque de découvrir le principe d'un moteur de tir avec un PJ iso... La procédure pour un moteur de déplacement du PJ, case par case avec un rapport 4:3.

Au départ la procédure est exactement la même que celle du moteur libre 8 directions.
Testeur d'activité du joueur, "key wait", une base (où se fixe le PJ) mouvement statique, dont le déplacement est géré par le timer.

La petite nuance le "théorème" du saut de puce hyper simple avec de la pratique.

La base d'un jeu vidéo 2D est la tuile.
Taille du tile iso 64x48 pixels.

Axe X, 4x16=64 pixels.
Axe Y, 3x16=48 pixels.

Combien de sauts de puce avec un rapport 4:3 sur une diagonale?
8 sauts de puce à condition que la puce soit électronique.
4x8=32 sur l'axe X et 3x8=24 sur l'axe Y, car du centre d'une tuile à un autre.

Donc sur les droites axe X, 64/8=8 pixels et axe Y, 48/8=6 pixels, si conservation du nombre de sauts de puce.

Logiquement pour une même distance à l'écran, plus il y a de sauts de puce, plus il sera possible d'avoir un déplacement fluide, inversement, moins il y a de sauts de puce, plus il sera possible d'avoir un mouvement saccadé.

La résolution de la problématique n'est pas top sur les droites, le mieux est donc un déplacement de 4 pixels en 4 pixels ou de 3 pixels en 3 pixels, car plus fluide.
Cela donne à l'arrivée, un moteur un peu plus complexe et forcément plus de lignes, donc un peu plus de travail.

Un moteur de déplacement optimisé loin de son contexte, devient incompréhensible.
J'essaye de partager des principes basiques, des notions, même si mes mises en pratique, laissent quelques fois à désirer (lol).

Une fois capté la théorie du saut de puce électronique, avec hâte et précipitation, ouvrir TGF, MMF ou CTF 2.5, et passer à la pratique.

Existe t-il, une autre crémerie "Klougy" capable de pondre un moteur de déplacement case par case simplifié, 8 directions, avec un rapport iso 4:3?

A ma connaissance il n'existe pas encore de moteur case par case potable pour une tuile Reiner.

Voici trois phases schématiques, afin de décortiquer le "théorème" du saut de puce (17 lignes):
https://www.dropbox.com/s/gzi30aq6931dv7k/Saut%20de%20puce%20Iso.zip



Quel est mon humble avis sur ce moteur?

Comparé au déplacement libre, il sera moins prise de tête, pas besoin de couches pour la gestion des plans, à condition que les ennemis bénéficient aussi, d'un moteur de déplacement case par case.

En gros les deux tendances pour faire un choix.

Déplacement libre >> Exploration >> Genre hack and slash.
Déplacement case par case >> Jeu de plateau >> RPG Tactique.

Tout dépend au final des objectifs à atteindre.

Est-il possible d'avoir, un compromis entre le déplacement libre et le déplacement case par case?

Oui, la solution est pratiquement donnée dans "Freemaker Engine", au lieu d'un déplacement case par case, un déplacement demi-case par demi-case, avec la même hitbox PJ, qu'un déplacement case par case.

Demi-case par demi case. >> 4 sauts de puce, x=4*4=16 pixels, y=3*4=12 pixels.
Cela évite... La gestion des plans avec un système de layers (couches).

A vous de modifier le moteur "Saut de puce iso".

J'avoue avoir acheté TGF2 à cause des ressources graphiques, gratuites de Monsieur Reiner, il y a de quoi faire niveau animation des personnages.
Gratuites ne veut pas dire sans licence:
http://www.reinerstilesets.de/lizenz/

Passer de 250 actifs avec TGF1 à plus de 500 actifs si besoin, quel progrès!

Dans le domaine de l'isométrie être persévérant ne suffit pas, le mieux être pugnace, ne rien lâcher jusqu'à atteindre un résultat valable.

Le PJ, le bestiaire, les projectiles doivent longer les diagonales, afin de garder l'effet pseudo 3D.
Genre hack and slash, stratégie mapping indispensable pour des couches dédiées à la gestion des plans.

Une stratégie mapping pour un moteur de déplacement libre, se trouve dans Légende 1.
https://www.dropbox.com/s/e18t29tm81mlkcl/Legende1.zip?dl=1

Ce big tutorial explique comment monter et descendre des escaliers.
La mise en pratique, montre la mise en place de l'astuce pour inverser le rapport iso, toujours pour des escaliers.

Il est à craindre que sans mes explications, mes moteurs ne valent pas un radis, et il y a des fois, autant dire que je rigole à n'en plus finir derrière mon clavier.

Votre mission si vous l'acceptez, rassembler les moteurs dispersés aux quatre vents, dans différents exemples, par ce tête en l'air de Spring UP.

Vous avez tous les éléments à disposition pour obtenir le début d'un moteur de jeu "iso" cohérent.

Bien sûr mes explications et mises en pratique, sont aussi valables pour n'importe quel rapport "iso".

A condition de ne pas mélanger les ressources graphiques, j'ai déjà vu quelqu'un reprendre (copier) l'un de mes moteurs pour faire du 2:1, avec mon détecteur de collisions 4:3, quand on ne sait pas réaliser un détecteur 2:1 avec MMF, autant prendre des cours de castagnettes.



Olé! Olé! Bonne continuation à tous les cliqueurs et cliqueuses.

A+++

Edit: Tout le monde à zéro, vous n'avez pas trouvé le rapport iso pour la tuile David Gervais, taille 54x27.