Besoin de conseils

Bonjour/bonsoir,

Apres avoir commencer une base de jeu je commence a tourner en rond a propos du design de celui-ci.

J'ai créais une classe Engine puis des classes dérivées EngineWindow, EngineContrlol et EngineScene.
Engine contient une instance de chaqu'une de ses classes dérivées (en statique) et la boucle principal du jeu. Je voudrais que mon moteur de jeu soit le plus modulable. J'ai pas envie de modifier le cœur même de mon moteur lorsque je rajoute un personnage ou un menu par exemple. Je voudrais aussi que chaque "scene" gère ses contrôles clavier Engine ne contenant qu'une vérification sur la fermeture de la fenêtre dans sa boucle. Que pensait vous du fait de gerer les contrôles en dehors* de la boucle principal?

Si quelqu'un a déjà créer un moteur de jeu assez modulable il serait aimable de m'aider dans ma quête du moteur facile a a utiliser :hola:

* par là je veut dire que tout les "if" sont dans les scènes qui sont "actualisés" par Engine et non pas directement dans la fameuse boucle.

T'aime bien le mot Engine :mouarf:
autant certaine partie je l'appellerai peut être moteur , mais un moteur pour les controls je trouve ça marrant (en général une fonction permet de gérer le truc).
Pareil pour affichage en general en 2D , a part les rotation/position (et éventuellement animation) , y a pas grand chose a faire en tous cas pas assez pour appeler ça un moteur (de monj point de vue toujours) :aie:

Mais bref je vais essayer de t'aider , sachant que pour ma part j'utilise une architecture qui marche toujours (et qui fonctionne en 3D ) , je vais te donner mon conseil après c'est une façon comme une autre.

Voila dans ordre de la boucle de jeu.

En général on récupérè , les touche dans un tableau de booléen (on peut créer une structure/méthode possèdent des évènements plus complets , comme la souris et le joystick et la fenêtre).

Puis on créer une fonction gameplay qui modifiera les animation/variables/vecteur du perso ect.
On fait IA.

On fait les collisions (par rapport au vecteur vitesse).
On fait la camera (mais certain jeu 2D n'en possède pas).

On affiche le perso a x,y (et Z si c'est un jeu 3D) , ennemi map , et le HUD.
Et on fait une fonction FPS.

Voila en espèrent que ça te permettra d'y voir plus clair.

Bonjour,

Moi je trouve bizarre l'héritage de Window/Control/Scene par rapport à une classe Engine. Je n'arrive pas à concevoir le lien qu'elles ont et ensuite vous rajoutez :

Citation:

---

Engine contient une instance de chaqu'une de ses classes dérivées (en statique) et la boucle principal du jeu.

---

D'un point de vue orienté objet, c'est assez étrange.

Déjà, faire quelque chose en statique (vous ne pourrez avoir qu'une seule scène ? qu'un seul Control ?) cela limite beaucoup. Ensuite, statique sous entend un ordre d'initialisation pas ou peu controler (car fait avant le main par le système) et provoquant parfois des choses étranges.

Ok, je vais vendre un peu mon truc, mais vous pouvez vous inspirer de mon moteur : https://code.google.com/p/openawars/...ches%2FNEngine que j'ai fait de façon très modulaire (en théorie, je peux changer de bibliothèque dès que je veux).

Bon, contrairement à Kannagi, moi, c'est pour de la 2D :aie:

D'abord je suis extrêmement désolé du temps que j'ai mis a répondre j'ai eu quelques problème. Ensuite merci pour ces réponse très complètes.

Citation:

---

T'aime bien le mot Engine
autant certaine partie je l'appellerai peut être moteur , mais un moteur pour les controls je trouve ça marrant (en général une fonction permet de gérer le truc).
Pareil pour affichage en general en 2D , a part les rotation/position (et éventuellement animation) , y a pas grand chose a faire en tous cas pas assez pour appeler ça un moteur (de monj point de vue toujours)

---

Enfaite j'aimais bien l'idée d'avoir mon code séparer en plusieurs module mais c'est vrai que de toute façons les différents modules seront forcement actif tout le temps et puis c'est pas très pratique finalement.

Citation:

---

D'un point de vue orienté objet, c'est assez étrange.

---

Je voulais que mes engines soit accessible dans tout mon code, je sait jamais comment faire dans ces cas là.

Citation:

---

Ok, je vais vendre un peu mon truc, mais vous pouvez vous inspirer de mon moteur : https://code.google.com/p/openawars/...ches%2FNEngine que j'ai fait de façon très modulaire (en théorie, je peux changer de bibliothèque dès que je veux).

---

Merci j'y jette un oeil(même si c'est du SDL :/).

Citation:

---

Déjà, faire quelque chose en statique (vous ne pourrez avoir qu'une seule scène ? qu'un seul Control ?) cela limite beaucoup.

---

Ça c'est voulu, je trouve normal qu'il n'y est qu'une seul scène active a la fois.

Juste après avoir posté j'ai commencer mon moteur et je dois avouer que je le trouve assez bien construit pour l'instant(malgré l'aspect moteur). Le seul problème que je rencontre est assez minime mais carrément handicapant: Lorsque j'appuie sur une touche mon "personnage" avance d'un pixel attend une seconde puis avance normalement. On dirait que le keyrepeat ne fonctionne pas correctement.

J'essaie de régler ce problème et si j'y arrive pas je pense refaire tout mon moteur.

Encore merci pour vos précieux conseils.

Même si mon moteur a une implémentation en SDL, ce n'est pas la couche native qu'il faut regarder. En effet, la SDL est isolé et si je veux mon moteur utilise SFML, Qt ou je ne sais pas quoi. Vous pouvez ne pas regarder cette partie là, car ce ne sont que des définitions des fonctions utilisée par le moteur.

Sinon, faire des modules c'est bien, on a jamais dit le contraire. Mais tous les appeler Engine, cela semble rompre la responsabilité unique.

LittleWhite a raison ,qu'il utilise la SDL ou non n'a pas de grande importance.
Mon architecture je utilise avec 2 lib bien différente 2D ->SDL et 3D opengl , on général en ce souci peu de la lib , ça peut donné ça :

Code:

---

1 2 3 4 5 6

//en 2D affiche(hero,x,y);   //en 3D affiche(hero,x,y,z);

---

La différence sera surtout les appel de fonction/méthode affichage et la représentation en mémoire des objet 2D/3D.

La responsabilité unique est plus lié , il est vrai a un concept POO , (en programmation fonctionnel chaque fonction est complètement indépendante).

Mais c'est vrai que c'est plutôt étrange ton système de Window/Control/Scene , peut être un peu abusé de faire un héritage dessus , de simple méthode assez indépendante entre elle suffise largement a mon avis.