Discussion :

[mazertys17]

Bonjour.

Apr�s une discussion avec entre autre, Koala, je me suis laiss� convaincre qu'il fallait repenser mon programme, et m'orienter vers le ECS, apparemment bien adapt� pour le jeu vid�o ( mon projet est de faire un STR en 2D avec la SFML ).

Avant de me lancer d�finitivement, j'aimerais vous exposer la fa�on dont je vais proc�der afin de soumettre celle ci � vos critiques, pour prendre du recul et orienter au mieux mon programme d�s le d�but.

voici comment je compte proc�der ( dans les grandes lignes ) :


-une class Game va contenir l'Engine, les Systemes, et les Resources. Elle aura pour but de charger les niveaux, en lisant les fichiers sur le disque dur pour cr�er tous les syst�mes et objets n�cessaires � la sc�ne.

-une class Engine, va r�cup�rer tous les syst�mes utilis�s et les updater continuellement, en veillant � lier les modules quand il le faut.

-des class System, polymorphique, contiendront � la base un multimap avec le num�ro de l'objet, et le module qu'elles manipulent. ( un Graphics, collision etc... ) . ils seraient des unique_ptr dans un vector contenue dans Game/Engine .

-une class Data, contient les donn�s fondamentales de chaque objet ( son nom, sa position, etc...), et sera utilisable dans chaque module. ( en outre, un module "Graphics", par ex, aura une r�f�rence/ptr data auquel il aura acc�s lors de l'update : ainsi si le module Physics bouge l'objet, le module Graphics, lors de l'update, le repositionnera automatiquement ).

Mes interrogations sont les suivantes :

_est-ce une bonne id�e d'utiliser l'h�ritage pour les syst�mes ( selon vous ) ? Et si oui, allier cela avec des templates serait-il chose � faire ?

_utiliser un Data pour chaque module est-il l� aussi une id�e valable ?

Il y a �videment une infinit� d'autres interrogations, mais ce sont les premi�res qui me viennent...

Merci si vous pouvez commenter, proposer, orienter etc...la conception

[mazertys17]

Voici la class Game, qui r�cup�re la fen�tre et le contr�le du temps depuis le main :

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
 
 
class Game
{
public :
 
    Game( sf::RenderWindow& window , bool& time ) ;
    ~Game() ;
 
    void                                                         load() ; //lit depuis le disque dur tous les objets à construire avec build.
    void                                                         build( std::string name , float x , float y ) ; //construit un objet depuis le disque
    void                                                         play() ; //fait tourné l'engine avec ts les systèmes nécessaire
 
    std::unique_ptr < System >                                   getSystem( std::string name ) ; // construit et ajoute un system pour le niveau
 
private :
 
    sf::RenderWindow                                              &_window ; //pour l'ajouter aux systèmes qui en auront besoin, comme Graphics
    Engine                                                        _engine ;
    Resources                                                     _resources ; // contient tout le package ( textures etc...) chargé, sinon le charge 
    std::vector < std::unique_ptr < System > >                    _system ;//la class mère de tous les systèmes.
    std::vector < Data >                                          _data ; //contient les données de base d'un objet.
    size_t                                                        _number ; //le numér implémentable de chaque objet...
    bool&                                                         _time ;//un repère de temps donné depuis le main (1/16s , pour l'animation etc...)
 
 
};

voici le Data, contenue donc en vector dans le Game, qui est vou� � �tre utilis� en r�f�rence dans pas mal d'entit�s, ( comme ici plus loin le graphics ) :

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
 
 
class Data
{
public :
 
    Data( bool& time ) : _time ( time ) {}
    ~Data(){}
 
    void                                                    setNumber ( const size_t number ) { _number = number ; }
    const size_t                                            getNumber () { return _number ; }
 
    std::string                                      _name , _behavior , _state ;
    float                                            x , y , z ;
    bool                                             &_time ;
 
private :
 
    size_t                                                  _number ;
 
};

et ici l'exemple de la construction d'un objet depuis le disque, syst�m Graphics :

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
 
 
void Game::build( std::string name , float x , float y )
{
 
        _number ++ ;
 
        ...
 
        if( flux )
        {
            Data data ( _time ) ;
            data.setNumber ( _number ) ;
            data._name = name ;
            _data.push_back ( data ) ;
            while( wordFlux !=  "end" )
            {
 
                flux >> wordFlux ;
                    word0 = wordFlux ;
 
                if ( word0 ==  "Graphics" )
                {
                    std::unique_ptr < System > model = getSystem ( "Graphics" ) ;
                    std::vector < Data > :: iterator it = _data.end()-1 ;
                    Graphics graph ( *it ) ;
                    ....
                    graph.add ( word0 , _resources.getTexture ( word1 ) , int0 , int1 , int2 , int3 , int4 , condition ) ;
                    ....
                    model -> add ( _number , graph ) ;
                    _system.push_back ( std::move ( model ) ) ;
                    ...etc...pour les autres modules...

Le syst�me Draw, h�rit� de System :

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
 
 
class Draw : public System
{
public :
 
    Draw( sf::RenderWindow& window ) ;
    ~Draw() ;
 
    void                                                         add ( size_t number , Graphics graph ) ;
    void                                                         update() ;
 
private :
 
    sf::RenderWindow&                                            _window ;
    std::multimap < size_t , Graphics >                          _graphics ;
 
};

La class Graphics ( juste pour montrer comment une entit� peut contenir le data correspondant � l'objet ).

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
 
class Graphics
{
public :
 
    Graphics( Data& data ) ;
    ~Graphics() ;
    ....
private :
    ....
    Data&                                               _data ;
 
};

et enfin l'Engine, jou� depuis le Game ( pour l'instant sous sa forme minimaliste ):

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
 
 
void Engine::update()
{
    for ( auto& it : _system )
    {
        it -> update() ;
    }
}

Voil�, ce sont les grandes lignes de mon projet en terme de programmation, qui arrive d�j� � afficher une animation, � l'aide du syst�m Graphics.

Merci beaucoup si vous pouvez me dire ce que vous en pensez ( aussi m�me si ca vous para�t coh�rent , ( ce qui serait bien la premi�re fois pour moi )...Mais �videment surtout si vous trouvez que quelque chose cloche.

[LittleWhite]

Bonjour,

Ouep, l'ECS est "sympa" mais je crois que c'est surtout un effet de mode. Il ne me semble pas que l'on puisse faire un jeu complet avec l'ECS. Enfin, c'est ce dont j'ai l'impression, je me trompe surement.
Maintenant voyons le code et je dois dire, il y a quelque trucs qui me font peur.
Ici :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

std::vector < std::unique_ptr < System > >                    _system ;//la class mère de tous les systèmes.

Le commentaire ne convient pas � ce que je vois. Le commentaire, pour moi, semble dire que je n'aurais qu'une instance de System, alors qu'ici, on a plusieurs probablement syst�mes.

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
Resources                                                     _resources ; // contient tout le package ( textures etc...) chargé, sinon le charge 
std::vector < Data >                                          _data ; //contient les données de base d'un objet.

Quelle est la diff�rence entre Data (une donn�es) et une ressources ?

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

Data( bool& time ) : _time ( time )

Un temps en bool�en, moi, j'ai du mal. Mais en plus, je n'ai pas du tout, compris � quoi il servait, surtout dans le constructeur.

Une Data avec :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

float                                            x , y , z ;

C'est plus qu'une Data, genre, elle est Positionnable.

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

void Game::build( std::string name , float x , float y )

Je conseille de passer les std::string en r�f�rence constante. Mais on me dit qu'en C++11, ce n'est plus vraiment d'actualit� ?
De plus la fonction "build" me semble g�rer beaucoup de chargement (load).

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

std::multimap < size_t , Graphics >                          _graphics ;

Pour moi, Draw n'a pas besoin de contenir les Graphics. De plus, pourquoi la size est la cl� (pour identifier les types ?) ?
Pour moi, on passe une instance par une de Graphics au Drawer afin de lui demander d'afficher.


Enfin, comme je l'ai dit, je ne suis pas convaincu de l'ECS, mais si je trouve cela cool et amusant.

[mazertys17]

Merci pour ta r�ponse, LittleWhite.

je ne suis pas convaincu de l'ECS, mais si je trouve cela cool et amusant.

Mon but n'est pas de m'amuser, mais de faire un jeu qui tienne la route.

semble dire que je n'aurais qu'une instance de System, alors qu'ici, on a plusieurs probablement syst�mes.

Oui, le commentaire est probablement mauvais. Il y a en effet dans ce vector tous les system n�cessaire au jeu dont la class m�re est repr�sent� par l'objet "System"... et cela est-il valable selon vous, en terme de conception sur ce point ?

Quelle est la diff�rence entre Data (une donn�es) et une ressources ?

C'est plus qu'une Data, genre, elle est Positionnable.

Le data repr�sente en fait, dans mon cas, plut�t une entit�...( il faudrait peut �tre que je change le mot ). Chaque objet a une "Data" qui contient ses informations principales, ( nom, position, comportement etc...), le but �tant de faire passer ces infos simplement d'un module � l'autre par r�f�rence. C'est �galement une class un peu fourre tout, pour avoir acc�s facilement � des informations comme le temps, qui sera utilis� dans pleins de modules. ( par exemple le Graphics, qui doit animer ses sprites toutes les 62500 microsecondes...)

La class Resource, elle est une class unique qui contient les textures charg�s, sons etc..

De plus la fonction "build" me semble g�rer beaucoup de chargement (load).

La fonction "load" se contente de lire le fichier du niveau ex :

personnage1 1014 , 2048
arbre 500 512
arbre 489 1546
bidul 456 644
etc...

et utilise pour chacun des objets demand�s la fonction build qui les construits, avant de les positionner avec les bonnes coordonn�es ( qui vont de pair).

Mais oui, sans doute ma fonction build risque d'�tre tr�s longue...Puisque qu'elle lira � elle seule toutes les donn�s constructibles du jeu ( Graphics, Physics, control, behavior etc...), contenu dans des fichiers textes individuels pour chaque objet, et pourra demander � cr�er tous les syst�mes appropri�s...

Cela vous para�t-il g�rable/coh�rent ? ou dangereux et lourd ? ( si vous avez une meilleur solution, je suis toujours preneur ; )

Pour moi, Draw n'a pas besoin de contenir les Graphics. De plus, pourquoi la size est la cl� (pour identifier les types ?) ?
Pour moi, on passe une instance par une de Graphics au Drawer afin de lui demander d'afficher.

Dans mon cas, Draw est un System. N'est-ce pas le principe du ECS ? Le System Draw va contenir les clefs de tous les objets qui utilisent l'affichage ( des simples num�ros ) auquel est associ� un module, qui va lui, pouvoir afficher ce qui correspond � l'objet.
Si un signal dit : "objet 4198456, devient rouge", alors le System Draw va s'arr�ter � l'objet "4198456" et demander au module Graphics apropri� de devenir rouge...est-ce bien correct ?

Merci pour ta r�ponse , ca me permet de r�fl�chir et prendre du recul. D�j� il faudrait surement que je transforme le nom Data en Entity, probablement....

[Bousk]

Salut,

avant de vouloir aller plus loin, il faudrait avoir des bases solides.

Juste en lisant rapidement
- const-correctness
- copie de string dans tous les sens
- bool& _time ;//un repère de temps donné depuis le main (1/16s , pour l'animation etc...) un bool pour un rep�re de temps ?!?!

[mazertys17]

- bool& _time ;//un rep�re de temps donn� depuis le main (1/16s , pour l'animation etc...) un bool pour un rep�re de temps ?!?!

Oui. Apparemment, ca a pas l'air conventionnel. L'id�e est que, toutes les 62500 microseconds ( soit 1/16 secondes ), le bool est true, et false le reste du temps. Ainsi, si le bool est true, alors, par ex, les animations peuvent �tre incr�ment�s. Le but �tant d'avoir des animation qui tournent � 16 images / secondes...

Est-ce si absurde que ca ?

copie de string dans tous les sens

Est-ce une mauvaise chose ? Mon projet de jeu est de faire un STR, donc il y aura de nombreux �l�ments. Des strings me paraissent indispensable pour bien s'organiser, non ?

const-correctness

Oui, l�, je vais relire un peu les cours C++

[LittleWhite]

Oui. Apparemment, ca a pas l'air conventionnel. L'id�e est que, toutes les 62500 microseconds ( soit 1/16 secondes ), le bool est true, et false le reste du temps. Ainsi, si le bool est true, alors, par ex, les animations peuvent �tre incr�ment�s. Le but �tant d'avoir des animation qui tournent � 16 images / secondes...

Est-ce si absurde que ca ?

Ahhhhhh, c'est �a votre id�e. Le nom de la variable est peut �tre pas tr�s bien choisi (?).
En r�alit�, ce n'est pas si absurde que �a, m�me peut �tre pas du tout mais :

• chaque animation peut avoir un temps d'animation diff�rent ;
• si votre jeu rame (ralentissement du PC pour X raisons, ind�pendante de votre code), l'update de l'instance se fera en d�calage et donc, le bool a une chance d'�tre � false � ce moment l�.
• le point pr�c�dent est encore plus vrai en multithread.

Est-ce une mauvaise chose ? Mon projet de jeu est de faire un STR, donc il y aura de nombreux �l�ments. Des strings me paraissent indispensable pour bien s'organiser, non ?

Les string c'est "OK", mais il ne faut pas les copier dans tous les sens. J'ai connu un projet, sur ce forum, qui perdait 50 % des perfs, juste par des copies des strings dans tous les sens (� chaque appel de fonction). C'est pour �a que l'on vous dit d'utiliser des r�f�rence constante (voir FAQ C++).

Mon but n'est pas de m'amuser, mais de faire un jeu qui tienne la route.

Je parlais du concept de l'ECS. Pas n�cessairement de votre projet et j'esp�re que le votre arrivera au bout

Mais oui, sans doute ma fonction build risque d'�tre tr�s longue...Puisque qu'elle lira � elle seule toutes les donn�s constructibles du jeu ( Graphics, Physics, control, behavior etc...), contenu dans des fichiers textes individuels pour chaque objet, et pourra demander � cr�er tous les syst�mes appropri�s...

Cela vous para�t-il g�rable/coh�rent ? ou dangereux et lourd ? ( si vous avez une meilleur solution, je suis toujours preneur ; )

Cela ressemble � un gros switch case. Je vous conseille de voir le design pattern Factory.


Dans votre programme "Data" me semble bien trop g�n�rique, cela englobe trop de chose (et je parlerai ici du principe de responsabilit� unique).