[C++]Gérer les évènements

[zeldalyoko]

Bonsoir all ou bonjour a vous de voir ^^

Je suis en train depuis 4/5 jours de faire mumuse a faire un moteur2D/RPG en C++/SDL (qui, jusqu'à présent fonctionne, maps, collisions, musiques etc , faut pas voir les codes par contre    *lémoch*), le seul ennuis c'est que je ne vois pas comment gérer les évènements dans le jeu (texte de conversation avec un "PNJ" etc.)

J'ai penser un certains temps utilisé des fichiers de config qui aurait une structure dans ce genre là : (exemple ici : conversation avec un PNJ.)

Code Sélectionner Étendre

[2,5,3]
Text Bonsoir, comment allez-vous aujourd'hui ?\2blablabla\2J'ai entendu dire que blabla
Events 2
IDObjet 5

[2,5,3]  //2 corresponds au chapitre 2 du jeu, 5 ème messages/10 du personnage, 3 ID Du personnage qui lui aussi serait dans un fichier config, avec ses coordonnees X/Y et l'ID de la map qui serait aussi dans un fichier Config

Text Bonsoir, comment allez-vous aujourd'hui ?\2blablabla\2J'ai entendu dire que blabla //c'est se que dit que le PNJ et les /2 c'est pour dire que l'on demande une interaction au joueur comme "appuyer sur space" pour passer au message suivant etc.

Events 2 //ex : donne objet, 3: donne une quête, 4: donne de l'argent etc. chaque Events appellera une fonction : ex void ArgentRecut(); etc.

IDObjet 5 //ID de l'objet qui lui aussi aurait ses informations dans un fichier config (nom, type, genre, pouvoir etc.)

J'arriverai a tout faire fonctionner, mais je trouve qu'utiliser se genre de système est un peu trop lourd (20 PNJ sur une map = 3 Fichiers (*20 ; car on analyse 20fois les 3 fichiers, vu que 20PNJ sont présent) configs, d'ouvert et analysé) et comme que je suis a court d'idée, je me demandais si vous n'en n'auriez pas ? (des idées )

Quelques choses de moins lourd que de devoir ouvrir 3 fichiers config et de rechercher les infos a propos de chaque PNJ, a moins que ma façon de faire soit bonne    Je ne sais pas, mais vous que me proposez vous ?

Merci et @bientôt =)

PS : Vous allez le temps pour me donner les idées , je ne suis pas encore arriver là, mais je n'ai pas envie d'être bloqué quand je coderai la gestion des évènements

[Geomaster]

Idéalement, tu devrais mettre en place un système de scripting, basé sur LUA par exemple, comme expliqué par Christopho dans sa dernière news sur ZSDX. Ce qui est intéressant car c'est une solution qui serait utilisée pour bien d'autres choses. Après tout dépend ce que tu veux faire, surtout si c'est juste pour faire mumuse et avoir un code moche, vaut mieux pas que tu t'embêtes avec ça.

Sinon, plus généralement, pour les dialogues en eux-mêmes, je te conseillerais (par exemple) un seul fichier regroupant toutes les phrases quelles qu'elles soient (dialogues, éléments de menus, etc) numérotées et listées par un ID (et plus facile après pour faire un fichier "anglais", un fichier "français", etc).

[zeldalyoko]

Hum... Le Lua, c'est simple a prendre en main ? (Jamais fais) et hum... non ce n'est pas juste pour faire mumuse, je souhaite apprendre un peu plus le C++ (j'ai appris principalement le C++ grâce a la réalisation de se moteur, quoique, il me manque quelques notions et les codes ne sont pas superbes, mais c'est déjà ça (je réalise plusieurs centaines dizaines de versions d'un code <- jusqu'à reussir a faire un code parfait ) :p 'fin bref...

Le Lua, complexe ou pas ? =)

Pas bête l'idée des dialogues dans un seul fichier :p Je n'en ai pas eut l'idée ^^

[Geomaster]

Euh ben déjà on apprend pas le C++ en faisant un moteur RPG 2D... Enfin après chacun utilise la méthode qu'il souhaite

Après, je ne connais pas ton niveau de compétences et s'il est suffisant pour appréhender Lua.

[zeldalyoko]

Euh ben déjà on apprend pas le C++ en faisant un moteur RPG 2D... Enfin après chacun utilise la méthode qu'il souhaite

Après, je ne connais pas ton niveau de compétences et s'il est suffisant pour appréhender Lua.

Je n'ai pas totalement appris le C++ via le moteur RPG 2D :p
J'ai un premier temps lu le bouquin "C++ pour les programmeurs C" de Claude Delannoy

J'ai ensuite tout oublié (car sa remonte de Fevrier l'année dernière :p), puis relu une bonne partie avant de me lancé dans deux/trois projets "tests" dans notre cher console tout noir :p =)

Une fois les tests terminées, je me suis lancé (le 20 pour être exact) dans la création du moteur 2D qui n'est pas du tout au point (fonctionnel, mais pas au point (code assez moche, bien que certaines choses me plaise comme la gestions/animations des sprites), je vais en faire plusieurs versions et donnes des améliorations dans le futur ! ^^)

Bref... Je fais se moteur pour m'améliorer, car je suis habitué (en C déjà) a faire une bonne centaine de version d'un même code avant d'en faire un qui me convient (et vu que rie ne me convient )

Bref... :p je vais chercher des tutos sur le Lua ^^

Merci de m'avoir répondu et donner ses conseils en tout cas =)

[Noxneo]

je suis habitué (en C déjà) a faire une bonne centaine de version d'un même code

Va lire un bouquin de conception dans ce cas.

[zeldalyoko]

je suis habitué (en C déjà) a faire une bonne centaine de version d'un même code

Va lire un bouquin de conception dans ce cas.

Hum... se que j'appelle : centaine de version, se sont des sortes de màj... Je sais consevoir un code, seulement, y a des choses auquels je n'avais pas pensés... Dans les tests que j'ai fais jusqu'à présent, je n'avais pas penser a devoir faire X ou X chose et améliore/ajout des choses aux codes, Pour ça que je dis : "Je suis habitué a faire une bonne centaine de version d'un même code", je récupère mon code a pars et l'améliore/ajout de choses.. Si maintenant, ajouter des fonctions a son code est egual a "ne pas savoir consevoir son code" c'est tout de même énorme :-\

[Geomaster]

La conception, ce n'est pas le fait d'écrire ton code, ça, ça s'appelle programmer ou développer. Concevoir, c'est réfléchir à ton projet et à ton code et le modéliser sur papier, avec des diagrammes, etc. Et quand tu as une bonne modélisation, tu as la moitié du travail de fait, tu évites des aller-retours inutiles, la pollution du code, bref tu es bien plus efficace et savoir se positionner en hauteur et avoir une vue d'ensemble suffisante de ton code aide à se poser les bonnes questions et au final programmer sainement du premier coup même des choses auxquelles tu n'aurais pas pensé de prime abord, ou les coder différemment pour préparer la suite, etc.

[Noxneo]

Si maintenant, ajouter des fonctions a son code est egual a "ne pas savoir consevoir son code" c'est tout de même énorme :-\

Si tu te dis "Ah ben flûte, j'ai oublié ce cas là, va falloir que je rajoute cette fonction", ou bien "En fait cette fonction là je vais la changer ça marche pas" ou des choses similaires, alors oui ça s'appelle ne pas savoir concevoir son code.

Après, ce n'est pas tout négatif, c'est en faisant mal les choses et en le réalisant qu'on apprends.

[zeldalyoko]

Ouais, en quelques mots faut réalisé un "Cahier des Charges", c'est ça ? =)

Si c'est le cas, d'une certaine façon j'en crée un, je mets tout se que je pense insérer dans le code sur papier (nombre de fonction ou class, pourquoi créer cette fonction, qu'elle sera son utilité etc.), et ensuite, j'écris en gros (très gros) comment sera le code =) ... c'est quelques jours/semaines après que je commence a codé, même si je sais que j'ai oublié des choses, ce n'est pas vraiment "grâve" car je commence toujours par faire une version alpha fonctionnel (qui est écrite en 2 semaines max (<- pour le moteur2D m'a fallu 3 jours pour faire afficher une map,  les sprites et les collisions (case par case) <- c'est une version Alpha <- c'est bizzare, oui oui) ), puis après la version final, qui reprendra se qu'il y a eut de meilleur de la version Alpha (<- ma façon de faire, depuis pas mal de temps déjà, elle est nul, mais j'ai tjrs reussit a faire ce que je voulais comme ça)

'fin, bref, chacun sa façon de faire, non ?

[Christopho]

D'après ce que tu dis, ta méthode ne me semble pas si mal . La théorie voudrait qu'on anticipe tout sur papier, et c'est bien sûr ce qu'on essaie de faire quand on procède correctement. Mais dans la vraie vie, on n'y arrive pas complètement. Il est tout à fait normal que tu te rendes compte qu'il manque des fonctions, voire qu'un morceau est carrément mal conçu et va devoir être revu car un cas crucial a été oublié ^^. Je suis le premier à qui ça arrive .
L'essentiel est que le code soit réutilisable. Pour cela il doit être suffisamment propre, séparé en classes et fonctions (éviter d'avoir une fonction de 500 lignes ou une classe de 5000 lignes !), et commenté afin qu'il soit réutilisable et modifiable ultérieurement. Certains disent qu'il faut 1/3 de commentaires et 2/3 de code. Il faut coder comme si le code était destiné à être utilisé par quelqu'un d'autre, car au bout de 6 mois, quand tu retouches à du code que tu n'avais plus regardé depuis tout ce temps, c'est presque comme si tu étais quelqu'un d'autre . Et ce n'est pas une mauvaise chose que de revoir plusieurs fois son code (même si 100 fois, ça me semble beaucoup ).

En ce qui concerne ZSDX, quand je regarde le code des tous premiers commits, je me rends compte que la majorité n'existe plus dans la version actuelle car ça a été remplacé par quelque chose de mieux ^^. Il m'est d'ailleurs arrivé plusieurs fois de modifier profondément l'arbre d'héritage. Par exemple à une époque, Link héritait de plusieurs classes : Entité, Sprite et ObjetEnMouvement. Comme ça il avait les propriétés qu'il fallait : un objet placé sur la map, qui s'affiche avec un sprite, et qui se déplace avec un certain mouvement. Aujourd'hui ça a bien changé, il n'y a plus d'héritage multiple. Link hérite juste de Entité, et toute entité peut avoir un ou plusieurs sprites ainsi qu'un ou plusieurs mouvements...
Autre exemple : au départ les maps étaient codées en dur (en C++) alors que maintenant elles sont dans des fichiers externes (un qui décrit le contenu de la map et l'autre qui contient son script). Les deux méthodes avaient leurs points forts et leurs points faibles. Je n'étais pas sûr au début alors j'avais essayé de coder ça de manière suffisamment propre pour pouvoir changer d'avis à l'avenir, et c'est ce qui s'est passé.
Bref, plus tu anticipes tous les cas, mieux c'est. On ne le dira jamais assez, il faut d'abord réfléchir sur papier avant de se plonger dans le code.

Pour en revenir à ton système d'événements puisque c'était la question initiale, ça me semble un peu compliqué. Je ne suis pas sûr qu'il y ait besoin d'autant de fichiers. Déjà, un fichier par map me semble nécessaire. Le reste, c'est des fichiers généraux : un pour tous les dialogues du jeu, un pour tous les PNJ, un pour tous les donjons, que sais-je... Mais pas besoin d'avoir trois fichiers différent pour chaque PNJ.

PS : en tout cas c'est courageux de te lancer dans un moteur de jeu avec un vrai langage de programmation, et je pense que tu peux compter sur Geo, Nox et moi-même pour te donner d'autres conseils car on a envie de soutenir de telles initiatives

[Noxneo]

et je pense que tu peux compter sur Geo, Nox et moi-même pour te donner d'autres conseils car on a envie de soutenir de telles initiatives

Tout à fait, même si on est un peu grincheux des fois 

Voilà une solution pour ton problème que j'ai codée rapidement. Elle est simple, mais tu peux facilement l'étendre du moment que tu comprends le concept.

On va écrire une classe DialogManager qui aura pour but d'afficher le dialogue correspondant à des coordonnées données. Le constructeur de cette classe prend un paramètre le fichier de dialogues à utiliser, dont la syntaxe (relativement simple) est la suivante:

Code Sélectionner Étendre

x y chaine (où x est la coordonnée x de l'évènement, y la coordonnée y, et chaine la chaine de dialogue).
La chaine de dialogue supporte aussi deux caractères spéciaux: \N, qui affiche le nom du héros, et \E, qui met un retour à la ligne.

Voici un fichier de démo:

(dialogs.dat)

Code Sélectionner Étendre

2 3 Bonjour, je suis un aventurier.\E
1 1 Comment ca va, \N?
4 5 Pour aller dans le donjon, il faut aller au nord.
3 3 Vive Hyrule.
2 2 Vois-tu, les ombres d'Angmar ne sont arrivees que\Erecemment. Et c'est a toi,\N, d'en debarasser\Ela contree.



Nous allons donc d'abord coder la boucle principale de notre programme de démo. Celui ci créée et initialise un DialogManager, , demande les coordonnées à l'utilisateur et exécute l'évènement associé (ou affiche un message d'erreur si il n'y a pas d'élément associé). Si l'utilisateur saisit -1 à l'une des deux coordonnées, le programme quitte.


(main.cpp)

Code Sélectionner Étendre


#include <iostream>
#include "DialogManager.h"

using namespace std;

int main(){
DialogManager* dialogManager;
dialogManager= new DialogManager("dialogs.dat");

bool exit=false;
signed int x=0;
signed int y=0;

while (exit==false){
cout << "Saisir les coordonnees ou est declenche l'evenement: (-1 pour quitter)" << endl;
cout << "X? ";
cin >> x;
if (x==-1)return 1;

cout << "Y? ";
cin >> y;
if (y==-1) return 1;

dialogManager->runEvent(x,y);

}


return 0;
}




Voilà, notre base est posée, il nous reste maintenant à spécifier et implémenter la classe DialogManager.

Cette classe va avoir pour attributs:

- la liste des dialogues (avec leur coordonnées associées)

Et pour méthodes:

- son constructeur, qui prend en paramètre une chaine
- runEvent, qui teste si il y'a un évènement aux coordonnées passées en paramètre et l'exécute si oui
- hasEvent qui renvoie vrai si il y'a un évènement aux coordonnées passées en paramètre, faux sinon.
- traiteControle qui s'occupe de traiter les caractères de contrôle (\E, \N, etc.)

Il ne faut réfléchir qu'à une chose vraiment: comment stocker les élèments de dialogue dans la liste. Nous allons tout simplement déclarer une structure comprenant 3 élèments: les 2 coordonnées, et la chaine de caractères. Nous allons ensuite déclarer une list (conteneur de la STL) qui contiendra des structures de ce type. Voilà donc la spécif:

(DialogManager.h)

Code Sélectionner Étendre

#ifndef _DIALOGMANAGER_H_
#define _DIALOGMANAGER_H_

#include <fstream>
#include <string>
#include <list>

using namespace std;

class DialogManager{
private:
struct objetDialogue{
int x;
int y;
string dialogue;
};

list<objetDialogue> dialogues;
list<objetDialogue>::iterator it;


void traiteControle(char caractere);
bool hasEvent(int x, int y);

public:
DialogManager(string Chemin);
void runEvent(int x, int y);
};
#endif


Il nous reste maintenant à implémenter le tout, ce qui n'est pas bien dur:


(DialogManager.cpp)

Code Sélectionner Étendre


#ifndef _DIALOGMANAGER_H_
#include "DialogManager.h"

#include <iostream>
#include <fstream>
#include <string>

using namespace std;

DialogManager::DialogManager(string chemin){
objetDialogue ligneCourante; //objet servant à construire la ligne courante, qui sera ensuite ajouté à la liste
string line; //chaine où on sauvera la ligne lue.
ifstream fichierDialogue;
fichierDialogue.open(chemin.data());
   
while (! fichierDialogue.eof()){
getline (fichierDialogue,line);

ligneCourante.x=atoi(&line[0]);
ligneCourante.y=atoi(&line[2]);

line.erase(0,4); //on a lu les coordonnées, on les efface donc de la chaine
ligneCourante.dialogue=line;

dialogues.push_back(ligneCourante);
    }
   
fichierDialogue.close();
}


bool DialogManager::hasEvent(int x, int y){
for (it=dialogues.begin();it!=dialogues.end();it++){
if ((*it).x==x && (*it).y==y)
return true;
}
return false;
}



void DialogManager::runEvent(int x, int y){
if (!hasEvent(x,y)){
cout << "Pas d'evenement ici" << endl;
} else {
string chaine=(*it).dialogue;
int i=0;
while (i!=chaine.size()){
if (chaine[i]!='\\'){ //tant qu'on est pas sur un caractère de contrôle, on affiche ce caractère à l'écran 
cout << chaine[i];
} else {
++i;
traiteControle(chaine[i]);
}
++i;
}
cout << endl;
}

}

void DialogManager::traiteControle(char caractere){
if (caractere=='E'){ //saut à la ligne
cout << endl;
} else if (caractere=='N'){ //afficher le nom du héros
cout << "Nox";
}
}
#endif

[SkyJedi]

Sympa comme classe, t'as oublié

Code Sélectionner Étendre

#include <stdlib.h>
Dans DialogManager.cpp

[Noxneo]

stdlib.h est la librairie standard C, je n'en ai pas besoin du tout ici.

Même si j'en avais besoin j'inclurais <cstdlib>, mais 1) ce n'est pas recommandé et 2) je ne fais pas usage de ses fonctions de toutes manières, donc je ne vois pas le besoin ici.

Hé oui, il ne s'agit pas de copier coller bêtement les include du site du zéro, faut aussi savoir à quoi ils servent 

[SkyJedi]

Si j'inclus pas stdlib; j'ai des erreurs ici :

Code Sélectionner Étendre


ligneCourante.x=atoi(&line[0]);
ligneCourante.y=atoi(&line[2]);

sur la fonction atoi; peut être mon IDE est mal configuré

[Noxneo]

Ah oui flûte, c'est une vieille version du code où j'ai utilisé atoi() pour aller plus vite- mais c'est moche, on en est C++, donc faudrait utiliser des flux.

Je posterais la MàJ si j'y pense quand je serais sur mon autre ordi.

[Shadax]

Bonjour

Je viens de lire ton message, et j'avoue avoir commencé un moteur en c++, après avoir lu la news de Christopho sur ZSDX.

J'ai vu que tu utilisais SDL (je commence tout juste avec), mais que penses tu de SFML ? En parcourant developpez.com, j'ai entendu parler de cette bibliothèque-ci, qui me semble plus simple et plus puissante (dailleurs SFML signifie Simple and Fast Multimedia Library), car développée spécifiquement pour C++ là où SDL est développée en C.

http://www.sfml-dev.org/

Sinon, petite question pour Christopho : dans la news, tu parles d'utiliser le Lua pour gérer les évènements. MAis ça inclue quand même d'avoir un lien avec le moteur de jeu en C++, et c'est là que je coince, pour la compréhension.

Sinon, j'en suis encore à me remettre le C++ en tête (3 ans que j'y ai pas touché), donc ça avance trèèèèèèèès lentement

[Christopho]

SFML a l'air d'être une bibliothèque très prometteuse. Cependant je reste avec la SDL étant donné qu'elle est plus avancée (et donc plus stable).
Pour les événements, les scripts Lua peuvent facilement appeler des fonctions C++ du moteur, et inversement. Ce tuto l'explique bien.
Il faut donc prévoir à l'avance un ensemble de fonctions C++ du moteur qui seront mises à la disposition des scripts Lua, comme jouer un son, afficher un message, fermer une porte, faire apparaître un monstre, modifier une variable de la sauvegarde...
Et également dans l'autre sens : prévoir des fonctions Lua que le moteur C++ appellera selon les circonstances, par exemple pour prévenir le script que le joueur dialogue avec un PNJ, qu'il vient de tuer un monstre, qu'il vient d'appuyer sur un interrupteur, etc.

[Sam101]

SFML a l'air d'être une bibliothèque très prometteuse. Cependant je reste avec la SDL étant donné qu'elle est plus avancée (et donc plus stable).

Personellement, l'impression que j'ai eu sur la SFML, c'est que contrairement à la SDL, l'API change vite et beaucoup entre les versions.

[Noxneo]

SFML a l'air d'être une bibliothèque très prometteuse. Cependant je reste avec la SDL étant donné qu'elle est plus avancée (et donc plus stable).

Personellement, l'impression que j'ai eu sur la SFML, c'est que contrairement à la SDL, l'API change vite et beaucoup entre les versions.

C'est dû à la jeunesse de la librairie.

Par ailleurs SFML est orientée objet, et certains préférent une librairie C comme SDL afin d'avoir une plus grande flexibilité de l'implémentation.

Aussi, il semblerait que SFML soit beaucoup plus lourde du fait de sa couverture fonctionnelle plus grande- la SDL reste donc un choix incontournable de flexibilité et de légereté.

[yoshi04]

Moi j'ai plutôt préférer miser sur la SFML pour renouveler justement l'utilisation des librairies, et oser le nouveau. Il y a de nombreuses possibilités avec la SDL que l'on retrouve dans la SFML, et c'est orienté objet. Petit négatif, on ne peut pas -code objet oblige- savoir ce qui se cache dans les objets prédéfinis, donc peut être existe-il des calculs inutiles qui peuvent rendre plus lourds l'utilisation de la lib.
De plus on peut pas mettre son jeu sur une dreamcast 
Enfin si on se base sur la plate forme PC, avec l'évolution actuelle, je pense que l'on a pas trop à se soucier pour les problèmes de "ralentissements" qui seraient au pire des cas minimes.

La SFML est donc aussi un bon choix, c'est différent, et en plein expansion !

[Noxneo]

Mouais, après c'est des choix de codeur- les deux vues se défendent

[Christopho]

L'idéal c'est de coder de manière indépendante à la bibliothèque, et d'avoir une classe qui fait l'interface entre le moteur et la bibliothèque utilisée
Comme ça, le jour où on veut changer de bibliothèque, on n'a qu'une seule classe à changer
L'intérêt ? Faire une version Nintendo DS

[yoshi04]

Oui tout à fait d'accord là dessus.

Quoique sur DS faudra peut être pas mal bidouiller, mais ça doit rester possible.
Et je sais pas si des scripts LUA ça passerait ? (la palib est assez limité, faudrait voir avec l'autre dont je ne me souviens plus le nom)

[Christopho]

Ce que j'ai décrit serait une première étape mais effectivement je pense qu'un portage DS demanderait plus de boulot. Et je ne sais pas du tout si les bibliothèques DS lisent le Lua ^^.

[Noxneo]

La dernière fois que j'avais un orteil dans le dév DS, ce n'était pas le cas. Par contre, c'est le cas sur PSP

Cela dit, si on a vraiment une seule classe qui fait l'interface entre la lib et le reste, alors un portage DS est plus que possible...il faut juste s'assurer que cette classe gère bien les résolutions, toussa comme il faut

[Sam101]

Ce que j'ai décrit serait une première étape mais effectivement je pense qu'un portage DS demanderait plus de boulot. Et je ne sais pas du tout si les bibliothèques DS lisent le Lua ^^.

Il existe une implémentation de Lua sur DS.. Et je crois que maintenant, il vaut mieux utiliser directement libnds..
Mais dans tout les cas, c'est une mission difficile, vu les capacités de la DS (A faire sur DSi, avec son ARM11 et ses 16 mo de ram *sbaf*).

[SkyJedi]

Effectivement, la SFML est beaucoup plus orientée C++ (contrairement à la SDL qui est destinée à la base à un usage en C); et plus besoin de se compliquer la vie avec la libération de mémoire, la SFML gère ça

Perso j'utilise ça pour mon jeu je la trouve très rapide et simple d'utilisation; en plus elle gère les nouvelles technologies par rapport à la SDL (utilisation de Quartz sur Mac par exemple); mais bon, je ne suis qu'un amateur ^^

[Shadax]

Sinon, autre question : pour gérer les différents plans d'affichage (premier plan, arrière plan) de sorte que link puisse passer sous un arbre, il ne s'agit que d'ordre d'affichage des différents niveaux du décor ? (dabord larrière plan, puis le plan juste devant, et ainsi de suite jusqu'au premier plan)

[Daru13]

Sinon, autre question : pour gérer les différents plans d'affichage (premier plan, arrière plan) de sorte que link puisse passer sous un arbre, il ne s'agit que d'ordre d'affichage des différents niveaux du décor ? (dabord larrière plan, puis le plan juste devant, et ainsi de suite jusqu'au premier plan)

J'imagine que il faut aussi définir sur quelles étages les collisions de Link doivent être calculées, ou non, non ?

[Noxneo]

Sinon, autre question : pour gérer les différents plans d'affichage (premier plan, arrière plan) de sorte que link puisse passer sous un arbre, il ne s'agit que d'ordre d'affichage des différents niveaux du décor ? (dabord larrière plan, puis le plan juste devant, et ainsi de suite jusqu'au premier plan)

Tout à fait, c'est l'approche la plus intuitive et la plus simple.

Après, certains moteurs (notamment ceux utilisant un moteur 3D à la base) permettent de donner un attribut Z à un sprite, afin de définir la profondeur. C'est plus pratique dans le sens que ça permet de rendre le sprite quand on veut, et on n'est pas obligé de faire une passe de rendu par niveau de profondeur dans l'ordre croissant.

Pour les collisions, il suffit de savoir sur quel plan se situe Link et de calculer les collisions uniquement sur ce plan.

Par contre on diverge bien du sujet là, faudrait pê penser à faire un nouveau topic :p

[Shadax]

Par contre on diverge bien du sujet là, faudrait pê penser à faire un nouveau topic :p

du genre Question simples / Réponses simple ? 

[Christopho]

Oui là on touche clairement aux questions du moteur de jeu, à l'opposé des événements donc ^^
Je réponds à la question, ce qui devrait clôturer cette digression. Sinon, s'il y a encore des questions liées à autre chose que les événements, ouvrez un topic
Donc pour les plans, dans Zelda Solarus DX j'ai un attribut Z, sur tous les objets : pas seulement Link, mais aussi les décors simples, les ennemis, les coffres, les téléporteurs, les PNJ... Comme ça je sais tout de suite si Link peut interagir ou pas avec l'objet. Le principal problème pour un Zelda c'est qu'il existe des phases où Link peut changer de plan, par exemple quand il marche au-dessus ou en-dessous d'une passerelle.
Ce "Z" n'a 3 valeurs possibles car 3 plans me suffisent, mais certains jeux permettent d'avoir autant de plans qu'on veut. Pour l'affichage il n'y a qu'à dessiner les 3 plans successivement, en commençant par celui du dessous évidemment.

[Sam101]

C'est pas idiot.. D'ailleurs ça doit être facile à faire en utilisant OpenGL ça non (Ce qu'utilise la SFML il me semble..) ?