Discussion :

[_Fenrir_]

Bonjour à tous et tous,

Dans le cadre d'un projet personnel ayant pour but d'approfondir mes connaissances je me suis fixer comme objectif la réalisation d'un moteur isométrique.
A l'heure actuelle j'ai déjà réaliser de petit projets (souvent de test) mettant en oeuvre la 2D et 2D isométrique "simple" (création/affichage d'une carte simple, déplacement d'un personnage, gestion de collision simple etc.).
Cette fois-ci je souhaiterai mettre la barre un petit cran au dessous au travers d'un petit moteur 2D isométrique.
N'ayant pas trouver de réponses concrète à mes interrogations au travers de mes recherches je viens demander votre aide pour éclairé mes petites lanterne.

Une image valant mieux que mille mots voici l'objectif que je désire atteindre:

Nous y retrouvons les principes de base de l'isométrie auxquels nous ajoutons un nouvel élément à savoir la hauteur.
De ce que j'en déduis nous introduisons une composante 'z' à nos éléments.
Pour l'affichage il suffit d'afficher de l'élément le plus éloigné au plus proche (par exemple de bas en haut et de gauche à droite).

Là où je m'interroge concerne la gestion de la hauteur (afficher correctement le personnage (ou autre), représenter dans la vidéo par un bâton) mais aussi la gestion des collisions.
Dans une gestion de collision "simple" on teste si l'on peut traverser ou non la case suivante. Hors dans le cas d'un ajout de hauteur un nouvel élément fait son apparition: la pente.
Dans la vidéo on peut voir deux "types" de pente: celle tenant en un "seul bloc" et celle composer de plusieurs triangle.

De tout cela découle quelques questions:
1) Les éléments composant cette "univers" doivent-ils être "représenter" comme des volumes ? (pour facilité leur manipulation ou la collision ou autre)
2) Comment son gérer les interactions avec des éléments de type pente (ou autre "forme") ?
3) Comment faire pour qu'un élément puisse être "traversable" d'une (ou plusieurs) façon? (Dans la vidéo on peut voir que le bâton bloque contre la pente lorsqu'il la prend de coté mais monte correctement lorsqu'il vient de "face")

Voici ce que compte utilisé pour réaliser se projet
- C++
- SFML (voir Qt)

J'espère avoir étais assez clair dans mes propos au quel cas j'essayerai de répondre au mieux à vos interrogations ^^'

Cordialement

Ps: Désoler si mon message n'est pas dans la bonne section, si besoin déplacez le.

[yahiko]

C'est un sujet intéressant.

A froid je pense qu'il est nécessaire d'avoir une représentation 3D en interne.
Je remarque que le nombre de types de blocs possibles est fini. Il doit être possible de les énumérer assez simplement.
Ces blocs sont aussi réguliers et linéaires, ce qui devrait faciliter les calculs sur les distances et les tests de collision, sans avoir recours à des techniques sophistiquées.

Pour les déplacements, je vois deux grands cas de figure.
* Le premier, celui où le joueur ne "sort" pas de la case courante. Tant qu'il reste dans sa case, les mouvements sont possibles en veillant à ajuster la hauteur du joueur si la case est un bloc de type pente.

* Le second cas est celui où le joueur "sort" d'une case. Il faut tester à ce moment si la nouvelle case n'a pas une pente trop importante par rapport à la case courante. Si la pente est verticale, alors le déplacement du joueur n'est pas possible. Si la pente est inférieure, dans ce cas, le déplacement devrait être possible.

[skeud]

J'ai bosser su run moteur iso il y a un moment, donc je me ferais une joie de te répondre à toutes tes questions .

concernant les cases et déplacement, le plus simple est de stocké un tableau en 3 dimension de tes case (une pour x, unr pour y, une pour z).

Ensuite pour chaque case tu stock 4 booléen qui correspondent aux "endroits d'entrée". Tout ça pour dire que suivant le booléen, tu pourras savoir si ton joueur peux rentré dans cette case à partir de cette face .

Ensuite concernant l'affichage, il faut fonctionner par niveau, toujours représenter le niveau 0 puis monté dans les z pour afficher les suivants .
Pour chaque niveau, il faut afficher d'abord les éléments les plus éloignés de la caméra pour ensuite afficher les plus proche (on ne fait pas d’itération classique X puis y dans un monde isométrique, ensuite oui, il y a des techniques qui fonctionnent mais ne produise pas un rendu idéal).

C'est pourquoi il faut, en plus des coordonnées, stocké un entier correspondant à la distance de ta case du point 0 (point de ta caméra).
Si tu as des questions n'hésite pas, je répondrais dans le fil, et ça permettra d'avoir une base de connaissance rapide sur les moteur iso (toujours eu la flemme de faire des tutos la dessus.).

[_Fenrir_]

Tout d'abord merci à vous deux pour vos réponses.

Pour ma part voici comment je conçois pour le moment l'ensemble (dans une approche "3D"):

Une classe "Objet" : Représente un élément quelconque de la scène (une tile, un jouerur/pnj etc.)
Avec comme attribut
- deux vector3 (origine, dimension) : représente la position (x, y, z) de l'objet et sa boite englobante.
- une image : représentation graphique de l'élément qui sera afficher
- quatre booléen : pour bloquer ou non un côté de l'objet (ajout suite au message de skeud)
- un int : stockant le type de l'élément (ajout suite au message de yahiko)

Une classe "Octree" : Permet de partitionné / placer les éléments dans la scène.
Ainsi lorsque l'on veut obtenir un morceau de la scène il suffit de faire l'intersection entre une boite (jouant le rôle de caméra) et l'octree pour récupérer uniquement les éléments à afficher (avec un tri de leur origine au préalable).
Cette liste d'élément permettrai également de faire les test de collision (uniquement avec les élément proche) lors du déplacement.

Une classe "Map"
Contient:
- une liste de tout les éléments de la scène
- un tableau 3 dimensions contenant les éléments (de type "sol" ) pour effectuer le test de déplacement (savoir si y a une case après)
- une liste contenant tout les éléments dans le la scène précédemment afficher (pouvant être récupérer pour faire le test de collision (par intersection) entre les boite englobante des éléments)

Avec comme schéma de déroulement:
1) Créer / charge la carte
Dans une boucle à chaque itération:
2) Mise à jour des éléments (facultatif)
3) On place tout les éléments de la carte dans notre octree
4) On récupère les éléments présent dans notre vue
5) On les affiche
6) On recommence

Voila ma vision sur la chose j'aimerai bien avoir votre avis la dessus.


Après il est vrai que je n'avais pas penser à utiliser un système de booléen pour la "gestion de direction" ni de valeur pour définir un "type" à l'objet.

Cordialement

[Nekraa]

Salut !

Je trouve cela génial ! J'ai moi aussi un projet avec des amis concernant la création d'un petit jeu vidéo en 2D isométrique simple. Nous travaillons actuellement sur les déplacements et rencontrons quelques problèmes au niveau des tests de direction et de changement de case. Ton moteur est parfaitement ce qui nous conviendrait !

Peux-tu m'en dire un peu plus à son sujet, niveau code ?