Discussion :

[MonsieurHelmut]

Bonjour à tous,

Cela fait quelque temps que je glane des informations afin de me lancer dans un bon projet. En effet, j'ai dans l'idée de réaliser un moteur de jeu (et peut etre un jeu qui va avec) 2D, surement un jeu de plate-forme pas trop compliqué.
Je me lance dans ce projet principalement pour voir jusqu'où je suis capable d'aller en programmation et si j'en viens à bout, j'aviserai pour un projet plus complexe. Et si j'arrive par dessus ca à developper des outils qui pourrons me reservir, j'en sortirais d'autant plus gagnant.

Pour en revenir au projet, un jeu de plate forme 2D donc. Du côté technique, j'ai opté pour le couple SDL & OpenGL, essentiellement dans un souci et portabilité, le tout en C++ (qui est le langage que je connais le mieux). Depuis 2 mois je bricole des petites démos et je n'ai à priori pas problème avec la 2D sous OpenGL (j'ai fait des routines de tiling).

Donc maintenent, j'essai de passer à une analyse papier de mon futur moteur de jeu et la je me heurte à quelques problèmes. C'est le premier jeu que j'essai de faire d'une facon un temps soit peu serieuse et j'ai du mal à avoir une vue conceptuelle de celui ci et l'approche C++ à avoir du problème. J'ai aussi du mal à trouver d'éventuels articles sur la facon de concevoir un moteur, du moins on nous balance bien souvent une succession de code sans avoir présenté un schéma d'approche.

Après une ptite reflexion, j'en suis arrivé au schéma suivant:



Pour synthétiser, le moteur tirera ses infos de fichiers XML pour toutes les données du jeu et faire le lien avec les fichiers sons et graphiques.
La partie logique du programme calculera le déroulement du jeu, la position des objets, les évenements clavier, sonore, etc, et mettra à jour ainsi le graphe de scène et enfilera dans le gestionnaire sonore les sons à jouer (ou arreter etc).
Ensuite, les deux parties de rendu iront piocher leur infos dans leurs parties supérieures respectives.
Par contre, sur ce schéma, j'ai mis que le graphe de scène et le gestionnaire sonore font directement le lien avec les fichiers sons et graphiques, or, je pense qu'il serait plus judicieux de passer d'abord par des managers (de texture, pour opengl, etc), histoire de faire cela proprement, sans doublons en mémoire.

Donc voila où j'en suis et n'étant pas sur d'avoir une approche convenable, j'en viens au but principale de cette discussion, avoir votre avis sur la chose .
Je suis à votre écoute, si avez des avis, des reproches ou des lectures à me conseiller, je vous en serai reconnaissant.

Merci d'avance.

[vanacid]

Hum, c'est pas tout à fait ça... je crois bien que ce devrait être un schéma ressemblant plus à celui-ci :


- Data -
Base de donnée (peut-être des fichiers XML)
Son
Graphismes

- Module Sound Load -
Ce module charge les fichiers son et les mets en tampon mémoire, ils sont bien identifié pour être exécuté lorsque c'est nécessaire

- Module Graphic Load -
Charge les images nécessaires pour le niveau courant, les identifie et les charge sous forme d'arbre.

- Module Data load -
Charge les données relatives à tous le reste :
+ Les règles du jeu
+ L'emplacement des graphismes (map)
+ Les sauvegardes
+ etc.

- Module Game Logic -
Appelle les autres modules selon l'information qu'il a besoin et effectue la synchronisation entre l'image, le son et l'input.

- Module Render Scene -
Affiche le résultat de l'image (son thread à lui)

- Module Play Sound -
Joues les sons et effectue le mixage (son thread à lui)

Dans le fond :
Game Logic est en haut, tout le reste ne fait que lui offrir des services.

C'est Game Logic qui gère le data, pas le module de rendu ou de mixage.

[shenron666]

Donc maintenent, j'essai de passer à une analyse papier de mon futur moteur de jeu et la je me heurte à quelques problèmes. C'est le premier jeu que j'essai de faire d'une facon un temps soit peu serieuse et j'ai du mal à avoir une vue conceptuelle de celui ci et l'approche C++ à avoir du problème. J'ai aussi du mal à trouver d'éventuels articles sur la facon de concevoir un moteur, du moins on nous balance bien souvent une succession de code sans avoir présenté un schéma d'approche.

Salut,

j'ai le même problème que toi, réussir à déterminer l'approche conceptuelle d'un "moteur" et rares (à la limite de l'inexistant) sont les bouquins qui te donnent autre chose que du code sortit d'on ne sais où et pas forcément exploitable

concernant ton approche, aussi minimale soit-elle, et comme le dit vanacid (si je ne me trompe) ce qui est externe à l'application doit passer par le module de logique que tu devrais redécomposer (dans un schéma de niveau 2 par exemple)

par contre, un conseil, évites le multithread surtout si tu ne maitrises pas déjà la conception d'un moteur (faire quelques petits programmes de tests avant pour se familiariser aussi)
je te dis ça parceque sécuriser un programme multithread est important, un thread qui modifie une donnée au moment où un autre va la lire par exemple est le genre de cas que tu rencontreras souvent et auquel tu dois faire très attention
et surtout, surtout, le débogage multithread est un enfer

[vanacid]

Ce que *shenron666* dit est vrai.

Il s'agit du problème appelé les "races conditions". La façon la plus simple d'y remédier est de faire en sorte que seul un thread puisse traiter les données à la fois.

Le thread d'écriture est habituellement Game Logic.
Les threads de lecture sont habituellement ceux de rendu.

par exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
 
private volatile bool lockedWrite;
private volatile bool lockedRead;
 
pulic bool getLockedWrite()
{
  return lockedWrite;
}
 
public bool getLockedRead()
{
  return lockedRead;
}
 
pulic void setLockedWrite(bool paramLocked)
{
  // On évite d'écrire durant la lecture par un autre thread
  while(lockedRead)
  {
    SDL_Delay(1); // Ou tout autre fonction permettant d'attendre un peu
  }
 
  lockedWrite = paramLocked;
}
 
pulic void setLockedRead(bool paramLocked)
{
  // On évite de lire durant l'écriture par un autre thread
  while(lockedWrite)
  {
    SDL_Delay(1); // Ou tout autre fonction permettant d'attendre un peu
  }
 
  lockedRead = paramLocked;
}

Le fait de mettre les variables "locked" volatiles t'assure que le compilateur ne mettera jamais la valeur des variables en tampon dans les registres du CPU et qu'il ira toujours chercher la valeur en mémoire. Ainsi, la valeur sera toujours correcte lorsqu'on ira la chercher.

Ainsi, dès que le tu fais une modification à la liste des données à afficher, le thread de Game Logic met la variable lockedWrite à true. Ensuite tu fais tes modifications. Ensuite il remet la variable lockedWrite à false.

Le thread de lecture (tel celui de l'affichage ou de restitution du son) met la variable lockedRead à true avant de lire les données, ensuite remets la variable lockedRead à false.

De manière à faire plusieurs traitement en même temps (parce que tu ne peux pas lire et écrire au même moment), et bien tu fais une copie des données que tu viens de lire dans une variable qui appartient à ton thread. Ainsi, avant de faire un quelconque traitement, la variable LockedRead est de nouveau à false et les données sont de nouveau disponible pour changement immédiat.

Si c'est trop compliqué, tu peux te limiter à un seul thread puisque c'est plus simple. Seulement, voici une façon facile de remédier au problème.

[ash.ice.loky]

Oui et je dirais même qu'avant de parler parrallelisme il faut revoir l'archi generale de ton moteur.

Le probleme dans ton archi est de "Reexploiter et ameliorer" ton moteur.

Une appriche satisfaisante, si tu ne sais pas trop comment faire, est une approche bottom-up, c'est a dire que tu developpes sous forme de "module" (un singleton fait en generale tres bien l'affaire) un ensemble d'outils ! indépendant ! que tu réunis ensuite via une "facade".

Cette facade est en fait l'api de ton moteur.

Les modules en question sont pour la pluspart des manager comme l'affichage, le son, les IO, les loaders, les "stockeurs", ..., mais PAS la logique !!! et surtout pas la logique.
Si tu mais la logique dans ton moteur tu annules le concept de réutilisabilité.

La logique doit se présenter sous la forme d'un langage de script qui utiliseras la facade (et donc l'api si tu suis toujours ) de ton moteur pour construire un jeu.

Par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
 
 
class ManagerGraphic
{
displaySprite () ;
}
 
class ManagerSprite
{
stockSprite () ;
}
 
class Facade
{
ManagerGraphic * mGraphic = new ...
idem sprite
 
StockSprite (string nom) {mSprite.verif(nom) ; mSprite.load(nom) ; mSprite.stockSprite(nom);}
 
}
 
puis dans ton langage de script :
 
#langage de script lambda du style lua, python, ruby, tcl, perso ...
 
#Script_data
StockSprite("hero")
StockSprite("heroine")
 
#Script histoire
...
display("heros" , attaque) ;
...

Enfin bref tout ca pour dire que en aucun cas la logique ne doit etre dans ton moteur.

Pour le reste c'est un peu comme chacun veut, c'est ce qui fait l'interet de la chose

Pour infos la facade ou le singleton sont des patterns, et un bon bouquin comme design pattern tete la premiere ou design pattern par la pratique te ferais ENORMEMENT progresser pendant ton apprentissage du C++.

[MonsieurHelmut]

Merci pour vos réponses, j'ai cru que le topic était tombé dans l'oubli .

J'avais bien conscience que la logique allait etre séparée de l'API, enfin, que ca n'allait pas faire partie du moteur lui même. J'ai mal représenter ma conception .
En guise de langage de script j'avais dans l'idée d'utiliser XML (lua si j'ai l'occasion de m'y mettre et si j'y trouve un avantage, ou si vous avez des propositions).
En fait, la logique comme je l'ai représenté, n'etait rien d'autre qu'un interpreteur de script, la vrai logique étant dans des scripts externes (XML sur le schéma).

Je vois un peu mieux le chemin à suivre et mes erreurs. Sans trop savoir ce qu'est une approche bottom-up, je pense avoir compris le concept, et j'avais justement penser à une approche en modules "tout singleton".

Question pattern, singleton, ok, mais facade... En gros ca revient à faire un API des différentes modules? Je vais me renseigner la dessus.

Pour le coté multi thread, c'etait surtout pour simuler le parallèlisme de tout les modules. J'avais pensé en effet à synchroniser les ecritures/lectures (exclusions mutuelles, avec les blocs verts foncés en données partagées) pour les problèmes évoqués. Mais ca s'annonce comme un bon merdier en effet . Pas de thread serait tout aussi bien et surtout moins ambitieux de ma part pour un commencement.
Et dans l'absolue, une gestion threadée avec vérous revient plus ou moins à un déroulement en un seul thread, les choses se faisant plus ou moins dans un certain ordre.

Merci encore pour vos réponses. Je vais voir comment je peux organiser mes modules, essayer de me refaire des schémas et me renseigner sur quelques trucs.

[shenron666]

En guise de langage de script j'avais dans l'idée d'utiliser XML (lua si j'ai l'occasion de m'y mettre et si j'y trouve un avantage, ou si vous avez des propositions).
En fait, la logique comme je l'ai représenté, n'etait rien d'autre qu'un interpreteur de script, la vrai logique étant dans des scripts externes (XML sur le schéma).

Attention, XML n'est pas un langage de script ni même un langage tout court, XML n'est qu'un format de stockage "universel"
tu peux t'en servir pour stocker des objets 3D, des scènes 3D complètes, des textes pour des questions / réponses dan sles RPG, une configuration programme, ect...

LUA par contre est un vrai langage de script, utilisé dans de nombreux projet commerciaux, il a fait ses preuves et s'avère très puissant et souple
tu peux trouver des tutoriaux ici : http://mdeverdelhan.developpez.com/tutoriel/lua/
histoire de débuter dessus

bonne continuation

[MonsieurHelmut]

Oui, je sais pour XML. Ce que je voulais dire, c'est que j'ai l'intention de créer mon langage de script via XML , ainsi que les maps et propriétés des niveaux etc.
Comme je sais deja parser de l'XML, je me suis dit "autant l'utiliser" plutot que me mettre à l'apprentissage d'un langage de script. De plus, ca resterait dans le cadre de mes études. Mais bon, peut etre plus fastidieux à mettre en oeuvre qu'un langage de script comme lua.

Enfin, je n'en suis pas encore à ce stade, mais je prend lua comme un candidat sérieux à cet usage.

Merci pour la précision et la suggestion.

[ash.ice.loky]

Alors pour le probleme du script XML ne te seras en effet d'aucun secours.
Tu auras beaucoup de mal a décrire des comportements dynamique avec cette techno.

Pour la difficulté de lua, je ne le connais pas mais je pense qu'une petite semaine dessus me permettrais d'en comprendre suffisament pour l'utiliser, Ruby, lua, python tout ca se ressemble a s'y méprendre a quelques différence pret.

La mise en place peut etre facilité par les tutos sur www.developpez.com avec du C ou du C++ au chois

L'abandon des threads est une bonne idée pour commencer.

[Edouard Kaiser]

Les tutoriaux de Laurent sont à regarder également même si ils correspondent à la réalisation d'un moteur 3D, ils apportent de trés bonnes bases afin d'avoir des bases solides concernant l'architecture de son moteur (gestion des ressources, memoire etc.).

[MonsieurHelmut]

Les tutoriaux de Laurent sont à regarder également même si ils correspondent à la réalisation d'un moteur 3D, ils apportent de trés bonnes bases afin d'avoir des bases solides concernant l'architecture de son moteur (gestion des ressources, memoire etc.).

Oui, j'en ai lu une bonne partie et c'est très interessant. J'ai d'ailleurs quelques outils de coté et des bouts de codes biens utiles que j'utilise de temps à autres depuis. Je ne compte pas aller jusqu'à un memory manager ou ne serait ce que des pointeurs intelligents (je ne me sens pas assez mur en c++ pour ca) et vu la taille de mon projet, je doute que ce soit essentiel. Qui sait, par la suite, j'aviserai, mais pour l'instant je vais me concentrer sur quelque chose d'abouti plutot qu'ambitieux.
La gestion de ressources est tout autant intéressante à voir.

Merci à vous pour les réponses. Je continu mon investigation et j'arrive bientot à un moment où je pourrais commencer quelque chose.

[ash.ice.loky]

Tu aurais tord de te passer des pointeurs intelligents, regarde le tuto sur boost et tu verras comment on peut les mettre en application et comment ca peut simplifier la vie (d'un programmeur )

[Ti-R]

Je ne compte pas aller jusqu'à un memory manager

Oui ce n'est pas forcément essentiel

ou ne serait ce que des pointeurs intelligents (je ne me sens pas assez mur en c++ pour ca)

Là, c'est une erreur, peut être "dur" à appréhender et voir l'intérêt, mais le temps gagné avec les smartpointeur ainsi que la facilité de programmation !

Là, par contre, il ne faut pas passer à côté !!

ps: Grillé par ash.ice.loky, qui partage visiblement mon avis

[MonsieurHelmut]

C'est vrai que ca peut etre pratique. Je vais m'enrichir de quelques lectures .

Merci pour les avis.