# Applications > Dveloppement 2D, 3D et Jeux > Moteurs de jeux vido >  Conception d'un moteur 2D isomtrique

## _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 ralisation d'un moteur isomtrique.
A l'heure actuelle j'ai dj raliser de petit projets (souvent de test) mettant en oeuvre la 2D et 2D isomtrique "simple" (cration/affichage d'une carte simple, dplacement 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 isomtrique.
N'ayant pas trouver de rponses concrte  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 dsire atteindre:



Nous y retrouvons les principes de base de l'isomtrie auxquels nous ajoutons un nouvel lment  savoir la hauteur.
De ce que j'en dduis nous introduisons une composante 'z'  nos lments.
Pour l'affichage il suffit d'afficher de l'lment 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), reprsenter dans la vido par un bton) 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 lment fait son apparition: la pente.
Dans la vido on peut voir deux "types" de pente: celle tenant en un "seul bloc" et celle composer de plusieurs triangle.

De tout cela dcoule quelques questions:
1) Les lments composant cette "univers" doivent-ils tre "reprsenter" comme des volumes ? (pour facilit leur manipulation ou la collision ou autre)
2) Comment son grer les interactions avec des lments de type pente (ou autre "forme") ?
3) Comment faire pour qu'un lment puisse tre "traversable" d'une (ou plusieurs) faon? (Dans la vido on peut voir que le bton bloque contre la pente lorsqu'il la prend de cot mais monte correctement lorsqu'il vient de "face")

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

J'espre avoir tais assez clair dans mes propos au quel cas j'essayerai de rpondre au mieux  vos interrogations ^^'

Cordialement

Ps: Dsoler si mon message n'est pas dans la bonne section, si besoin dplacez le.

----------


## yahiko

C'est un sujet intressant.

A froid je pense qu'il est ncessaire d'avoir une reprsentation 3D en interne.
Je remarque que le nombre de types de blocs possibles est fini. Il doit tre possible de les numrer assez simplement.
Ces blocs sont aussi rguliers et linaires, ce qui devrait faciliter les calculs sur les distances et les tests de collision, sans avoir recours  des techniques sophistiques.

Pour les dplacements, 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 dplacement du joueur n'est pas possible. Si la pente est infrieure, dans ce cas, le dplacement devrait tre possible.

----------


## skeud

J'ai bosser su run moteur iso il y a un moment, donc je me ferais une joie de te rpondre  toutes tes questions  ::): .

concernant les cases et dplacement, 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 boolen qui correspondent aux "endroits d'entre". Tout a pour dire que suivant le boolen, 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 reprsenter le niveau 0 puis mont dans les z pour afficher les suivants  ::): .
Pour chaque niveau, il faut afficher d'abord les lments les plus loigns de la camra pour ensuite afficher les plus proche (on ne fait pas ditration classique X puis y dans un monde isomtrique, ensuite oui, il y a des techniques qui fonctionnent mais ne produise pas un rendu idal).

C'est pourquoi il faut, en plus des coordonnes, stock un entier correspondant  la distance de ta case du point 0 (point de ta camra).
Si tu as des questions n'hsite pas, je rpondrais 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. ::mouarf:: ).

----------


## _Fenrir_

Tout d'abord merci  vous deux pour vos rponses.

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

Une classe "Objet" : Reprsente un lment quelconque de la scne (une tile, un jouerur/pnj etc.)
Avec comme attribut
- deux vector3 (origine, dimension) : reprsente la position (x, y, z) de l'objet et sa boite englobante.
- une image : reprsentation graphique de l'lment qui sera afficher
- quatre boolen : pour bloquer ou non un ct de l'objet (ajout suite au message de skeud)
- un int : stockant le type de l'lment (ajout suite au message de yahiko)

Une classe "Octree" : Permet de partitionn / placer les lments dans la scne.
Ainsi lorsque l'on veut obtenir un morceau de la scne il suffit de faire l'intersection entre une boite (jouant le rle de camra) et l'octree pour rcuprer uniquement les lments  afficher (avec un tri de leur origine au pralable).
Cette liste d'lment permettrai galement de faire les test de collision (uniquement avec les lment proche) lors du dplacement.

Une classe "Map"
Contient:
- une liste de tout les lments de la scne
- un tableau 3 dimensions contenant les lments (de type "sol" ) pour effectuer le test de dplacement (savoir si y a une case aprs)
- une liste contenant tout les lments dans le la scne prcdemment afficher (pouvant tre rcuprer pour faire le test de collision (par intersection) entre les boite englobante des lments)

Avec comme schma de droulement:
1) Crer / charge la carte
Dans une boucle  chaque itration:
2) Mise  jour des lments (facultatif)
3) On place tout les lments de la carte dans notre octree
4) On rcupre les lments prsent dans notre vue 
5) On les affiche
6) On recommence

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


Aprs il est vrai que je n'avais pas penser  utiliser un systme de boolen pour la "gestion de direction" ni de valeur pour dfinir un "type"  l'objet.

Cordialement

----------


## Nekraa

Salut !

Je trouve cela gnial ! J'ai moi aussi un projet avec des amis concernant la cration d'un petit jeu vido en 2D isomtrique simple. Nous travaillons actuellement sur les dplacements et rencontrons quelques problmes 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 ?

----------

