conception et programmation ECS

Version imprimable

Voir 40 message(s) de cette discussion en une page

15/04/2015, 12h10
mazertys17

conception et programmation ECS

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 :P

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

Code:

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:

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:

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:

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:

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:

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 :lol:, ( ce qui serait bien la premi�re fois pour moi :aie:)...Mais �videment surtout si vous trouvez que quelque chose cloche.

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:

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:

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:

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:

float x , y , z ;

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

Code:

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:

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.

16/04/2015, 10h48
mazertys17

Merci pour ta r�ponse, LittleWhite.

Citation:

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.

Citation:

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 ?

Citation:

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

Citation:

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..

Citation:

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 ; )

Citation:

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....
16/04/2015, 11h18
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 ?!?!
16/04/2015, 11h32
mazertys17

Citation:

- 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 ?

Citation:

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 ?

Citation:

const-correctness

Oui, l�, je vais relire un peu les cours C++ ;)
16/04/2015, 14h07
LittleWhite
Citation:

Envoy� par mazertys17

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.
Citation:

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++).

Citation:

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 :)

Citation:

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).
16/04/2015, 14h38
mazertys17
Merci pour votre r�ponse.

Citation:

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�.

Oui, bien vu...apr�s j'ai pris le parti de calculer le temps ainsi :
Code:

1 2 3 4 5 6 if(elapsed.asMicroseconds() >= 62500 ) { clock.restart(); _time = true ; }
Donc si le jeu rame...le _time sera forc�ment true � un moment donn�, vu que le temps �coul� sera fatalement sup�rieur � 62500 microseconds...En revanche, bien sur, l'animation sera ralenti...Donc merci pour la remarque, je vais voir si je peux pas trouver quelque chose de mieux.

Citation:

Le nom de la variable est peut �tre pas tr�s bien choisi (?).

oui. Peut �tre que je peux utiliser quelquechose comme "_time62500mcs"

Citation:

d'utiliser des r�f�rence constante

( pour les string ).

Yes, oui, merci. Je vais proc�der ainsi dor�navant :D.

Citation:

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

Oui, tout � fait.
Donc cette technique ( design pattern Factory ) serait un bonne chose � appliquer dans mon cas ?
Ca va me faire encore un chapitre a lire :mouarf::aie:
16/04/2015, 15h10
koala01

Salut,

En fait (pour r�pondre � LittleWhite), la partie ECS permet de r�pondre � un besoin r�current dans les jeux vid�os : le besoin de cr�er continuellement (bon, on se comprend sur le sens � donner � ce terme, hein) des �l�ments utilisant un grand nombre de compos�s dans un grand nombre de combinaisons et qui, avec l'approche orient� objet, finiraient par donner des hi�rarchies de classes totalement incompr�hensibles.

Car l'approche "naive" serait de se dire que l'on a les sorts, divis� en "sorts offensifs", "sorts de d�fense" et "sorts d'am�lioration", que les armes seraient s�par�es en "armes � une main", "arme de jet" et "armes � deux mains", et ainsi de suite. Le probl�me, c'est que, chaque fois que tu voudra fournir un �l�ment suppl�mentaire (l'�p�e flamboyante du tueur de dragon), tu devras rajouter une classe � ta hi�rarchie, prendre cette nouvelle classe en compte dans l'ensemble du projet et ... recompiler (quasiment) tout ton projet pour arriver � l'int�grer.

L'approche ECS permet de partir de quelque chose ressemblant � une base de donn�es : un "certain" nombre de tables repr�sentant les composants de base ("caract�ristique", "type d'arme", "type de d�gats", "type d'�l�ment d'inventaire", "position d'�quipement", ... De cette mani�re, si je veux rajouter mon �p�e flamboyante du tueur de dragon, je cr�es une entit� (repr�sent�e uniquement par un identifiant unique), au pire, je rajoute les enregistrements "tranchant" et "feu" dans la table "type de d�gat", l'enregistrement "arme � une main magique" dans la table "type d'arme", et ainsi de suite pour terminer par un enregistrement dans une table particuli�re qui fera le lien entre toutes les caract�ristiques sp�cifiques � cette arme. Pas besoin de recompiler, il n'y "a qu'�" enregistrer les modifications dans la base de donn�es ;)

En s'assurant que chaque "caract�ristique" soit prise en compte par un syst�me particulier (SRP inside ;) ) il devient tr�s facile de g�rer ces ajouts et suppressions continuels ;)
16/04/2015, 15h13
ternel

Pour le nom de la variable, pense non pas � la cause, mais � ce qu'il provoque. Par exemple force_refresh.
16/04/2015, 15h27
mazertys17

En tout cas, tu m'a convaincu, Koala01 ;)

Le tout maintenant est de bien mettre en place tout ca !

J'ai du recommencer 10 fois mon programme depuis que j'apprends la programmation. Il faut que cette fois ci, ce soit la bonne !

Donc merci infiniment � tous ceux qui m'aident dans la conception, car cette aide m'est tr�s pr�cieuse ! J'ai j'esp�re atteint un niveau suffisant pour pouvoir me lancer d�finitivement ( � condition de prendre mon mal en patience bien sur et de proc�der pas � pas ).

Citation:

Pour le nom de la variable, pense non pas � la cause, mais � ce qu'il provoque. Par exemple force_refresh.

oui. Donc dans mon cas :

_time devrait �tre _timeIs65200mcs ?

et pour le Data, je crois que ce serait plut�t une Entity...Qui � la limite contiendrait une Data qui elle contiendrait le "_TimeIs65200mcs", et d'autre donn�es global du jeu..?
16/04/2015, 15h55
Bousk
Euh Koala, je confonds p-e, ou alors c'est toi, mais ce dont tu parles c'est juste �tre "Data-driven". Non on ne va pas recompiler pour cr�er une �p�e de feu apr�s avoir cr�� l'�p�e de glace. On a un objet �p�e, une datasheet correspondante et des attributs de part et d'autre.

ECS c'est l'approche Unity, on cr�e une Entity, et on bind des composants : un script, une boite de collisions, ... et quand le moteur met � jour l'Entity, elle met � jour chacun de ses composants.

Citation:

J'ai du recommencer 10 fois mon programme depuis que j'apprends la programmation. Il faut que cette fois ci, ce soit la bonne !

Tu d�butes, et tu commences par un exercice des plus difficiles : un jeu-vid�o, temps r�el qui plus est. :roll:
Citation:
Code:

1 2 3 4 5 if(elapsed.asMicroseconds() >= 62500 ) { clock.restart(); _time = true ; }
C'est, euhh... nul.
http://gafferongames.com/game-physic...your-timestep/
16/04/2015, 16h12
koala01

Citation:

Envoy� par Bousk

Euh Koala, je confonds p-e, ou alors c'est toi, mais ce dont tu parles c'est juste �tre "Data-driven". Non on ne va pas recompiler pour cr�er une �p�e de feu apr�s avoir cr�� l'�p�e de glace. On a un objet �p�e, une datasheet correspondante et des attributs de part et d'autre.

Disons plut�t que ce que j'ai expliqu�, c'est le d�but des bases pour les composants, qui sont effectivement essentiellement "data-driven". Mais c'est peut �tre aussi la partie la plus difficile � appr�hender si l'on est "trop format�" par le paradigme objet ;)

Mais, � partir du moment o� l'on arrive � comprendre qu'une entit� n'est qu'un ensemble de composants (auxquels il est normalement possible d'acc�der gr�ce � un simple identifiant unique) et qu'il suffit de modifier un composant pour modifier l'entit� qui l'utilise, on arrive � comprendre le reste du principe "sans trop de probl�me" ;)
16/04/2015, 16h56
mazertys17

Toujours en partant sur ce concept Entity Composant System, svp dites moi si j'ai bien suivit :

On a une Entity, dans mon cas, plus haut, le Data ( qui devrait donc s'appeler Entity ), qui repr�sente un objet du jeu ( une biche, un arbre, etc...).

On a des Components, qui sont des modules utilis�s/ouPas pour une Entity ( ex un Graphics, qui l'affiche, un Physics, qui le positionne ).

On a des System, qui sont des sortes de containers intelligents de components, qui les font tourner.

Donc, il serait profitable que l'Entity soit accessible par la plupart des components non ?
J'ai essay� de la mettre en r�f�rence, mais il me semble que ce n'est pas vraiment faisable dans cette utilisation...

Et...en tournant un peu la situation dans tous les sens, un frisson d'horreur me prend, et je pense....au...8O...au....:calim2:...:mouarf:

...au shared_ptr...:aie:

Chose que je voulais �viter puisqu'on arr�te pas de dire, probablement � raison que c'est un signe de mauvaise conception.

Pourtant, dans mon cas, l'Entity est cr�e d�s qu'un component au moins est utilis�. En fait, elle peut exister tant qu'un des component qui lui correspond au moins tourne. La responsabilit� de l'objet peut donc �tre partag� par plusieurs de ces components ?

Que pensez vous donc, dans ce cas, de :

-la coh�rence en terme de nom et d'utilisation de "Entity" ( qui contiendrait donc toutes les infos importante d'un objet ).
-son utilisation en tant que std::shared_ptr par des components ( si d�j� je suis dans le juste sur le concept Entity/Component/System )
-utilisation de Data, une class qui contient les infos technique du jeu, comme une ref sur la fen�tre, une ref sur le temps, etc...et serait contenue dans Entity, afin que les diff�rents composants puissent y avoir acces.

Et enfin une derni�re question :

A suppos� que l'id�e d'avoir une Entity qui repr�sente l'objet contenue dans la plupart des composants soit bonne, pensez vous que, pour une question de performances, la quantit� d'informations qu'elle peut contenir doit �tre absolument minimale ? ou au contraire, si elle en contient beaucoup, c'est pas un pb...

Merci si vous pouvez m'aider :)

Citation:

Envoy� par mazertys17

Que pensez vous donc, dans ce cas, de :

-la coh�rence en terme de nom et d'utilisation de "Entity" ( qui contiendrait donc toutes les infos importante d'un objet ).
-son utilisation en tant que std::shared_ptr par des components ( si d�j� je suis dans le juste sur le concept Entity/Component/System )

Si tu utilises un ECS c'est pour �viter 2 choses (principalement) :
* une �norme arborescence de classes
* une classe de base qui contienne plein de trucs utilis�s par les types d�riv�s

Le but est aussi de favoriser la localit� des donn�es : les positions de 2 entit�s seront proches en m�moire, si on utilise la position d'une entit�, il est probable qu'on ai besoin de la position de l'entit� suivante par la suite.

Dans un ECS, tes entit�s ne devraient �tre rien d'autres qu'un identifiant (un int par exemple).
Du coup, pas besoin de std::shared_ptr pour les manipuler.

Avoir une classe du type
Code:

1 2 3 4 5 6 7 8 struct Entity { Vec2 position; Texture texture; // ... }; // puis quelques part on stock les entités std::vector<Entity> entities;
est contraire au principe d'un ECS : tu veux justement �viter d'avoir une classe de base qui contienne tout plein de bazar.

�a devrait plut�t ressembler �
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 typedef unsigned int Entity; struct PositionComponent { Vec2 position; }; struct VelocityComponent { ... }; // puis on les stock, un unordered_map n'est pas forcément le plus adapté std::unordered_map<Entity, PositionComponent> positions; std::unordered_map<Entity, VelocityComponent> velocities; std::vector<Entity> entites;
Pour savoir quels composants une entit� poss�de, un syst�me de mask marche bien
Code:

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 const unsigned nbComponents = 2; typedef std::bitset<nbComponents> Mask; std::unordered_map<Entity, Mask> masks; struct PositionComponent { static const Mask mask = 1 << 0; Vec2 position; }; struct VelocityComponent { static const Mask mask = 1 << 1; Vec2 velocity; }; struct MoveSytem { static const Mask mask = PositionComponent::mask | VelocityComponent::mask; // soit tu gardes une copie ici des entités qui ont des composants position et velocity // soit tu les cherches à partir de ta liste d'entités. void update() { for(auto e: entities) { if(masks[e] & mask == mask) { // l'entité possède les bons composants, elle peut être traitée par ce système. PositionComponent& pos = positions[e]; VelocityComponent& vel = velocities[e]; pos += vel /* *dt */; } } } };
Tu peux avoir une �tape interm�diaire avant les syst�mes aussi pour cr�er des sous ensembles d'entit�s qui seront fournis (correctement tri�s) aux diff�rents syst�mes.
Code:

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 struct MoveNode { static const Mask mask = PositionComponent::mask | VelocityComponent::mask; Entity e; PositionComponent pos; VelocityComponent vel; }; struct MoveSytem { std::vector<MoveNode> moves; void update() { for(auto& m: moves) { positions[m.e] = n.pos + n.vel /* *dt */; } } }; // un "systeme" qui va créer les nodes pour les autres systemes. struct MakeNode { std::vector<MoveNode>& moves; MakeNode(std::vector<MoveNode>& m): moves(m) { } void update() { moves.clean(); for(Entity e: entities) { if(masks[e] & MoveNode::mask == MoveNode::mask) { moves.emplace_back(e, positions[e], velocities[e]); } } } };
C'est en tout cas l'id�e g�n�rale (telle que je l'ai comprise).

edit : un article int�ressent sur le sujet : http://t-machine.org/index.php/2007/...opment-part-1/

16/04/2015, 19h19
LittleWhite
@koala01 : Oui, vous parlez d'un ECS (et encore, l�, cela n'en ai pas vraiment vraiment un, je pense) au niveau �l�ment ingame. Souvent, on parle d'un ECS, au niveau plus moteur du jeu (genre, gestion de la position, de l'affichage, des update, des comportements pour chaque update).
Mais j'ose croire qu'il est impossible de faire un jeu complet avec des composants et un syst�me ECS. C'est mon ressenti, mon impression et surement � cause de mon ignorance.
Il y a des parties de l'ECS que j'aime bien. Mais � part �a...

Citation:

_time devrait �tre _timeIs65200mcs ?

_time devrait �tre : force_refresh (proposition de leternel), ou should_update, ou ... mais de toute fa�on, comme le montre/indique Bousk, c'est une mauvaise fa�on de faire. Ou alors tr�s �trange et prouvez-nous que cela marche.

Citation:

J'ai du recommencer 10 fois mon programme depuis que j'apprends la programmation. Il faut que cette fois ci, ce soit la bonne !

Oui, mais le jeux vid�o, ce n'est pas le domaine le plus simple. D'ailleurs, c'est peut �tre m�me le plus dur :aie: ou du moins, le plus multidisciplinaire. Voici mes points :
- on commence par des exercices simples pour comprendre/apprendre le langage (et sa biblioth�que standard) ;
- on commence par des jeux simples (oui, les jeux pourris style Pong, mais on peux trouver mieux et tout aussi simple) pour apprendre � faire un jeu vid�o (boucle de jeu, affichage, ...) ;
- on fait son projet, petit morceau par petit morceau.
Je serai vous, pour tester l'ECS, je ne tenterai m�me pas de mettre �a dans mon jeu ni rien. Je tenterai de mettre �a dans un programme � part, un bac � sable, avec un main et quelques classes de base. Cela permet de tester les limitations, les contraintes, les avantages et mieux comprendre les articles que l'on lit sur Internet.

Ah oui, pour moi, le STR n'est pas le jeu le plus simple � faire, loin de l�.

Oui, Data est une Entity ... mais cela reste trop complet, trop vague. Alors, Iradrille a donn� la bonne direction. Comme dans ECS, il y a composant et entity, je pense qu'il y aura au moins deux classes : Entity, qui est une classe l�, juste pour contenir des Composants \*o / Et les composants, pour moi, c'�tait une classe m�re que l'on peux h�riter.

Si je veux un joueur, je fais une instance de Entity, auquel je lui donne les composants :
- Positionnable (une position) ;
- Drawable (je veux l'afficher) ;
- PlayerControllable (c'est le joueur qui le bouge :)) ;
- ...
Enfin, moi, c'est comme �a que je vois la chose.

Merci pour ta r�ponse, Iradrille.

j'ai du mal m'exprimer, car je ne parle pas d'envoyer l'Entity dans les syt�mes, mais dans les composants ( qui en auraient besoin ), et d'o� le shared_ptr.
Un exemple pour un composant Graphics, contenu dans le SystemGraphic :
Code:

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 void Game::add ()//pour lexemple { _number ++ ; //number est un size_t std::shared_ptr < Entity > entity ( new Entity ( _data ) ) ; entity -> setNumber ( _number ) ; entity -> _name = "cestPourLexemple" ; entity -> x = 10 ; entity -> y = 196541 ; _entity.push_back( entity ) ; ...//pour l'exemple d'un Component Graphics : Graphics graph ( entity ) ; graph.setTexture ( Resources.load ( "maTexture" ) ) ; graph.setShape ( "square" ); //ou que sais-je... etc.... systemGraphic.add ( _entity -> getNumber() , graphics ) ; //ou ce qui renvient au même : systemGraphic.add ( _number , graphics ) ;
ainsi, quand le systemGraphic update tous les graphics, la fonction "draw" de Graphics va faire appel a l'Entity simplement pour avoir ses coordonn�es ( qui peuvent changer ).
C'est en revanche bien le composant "Graphics" qui sera possesseur des textures, vertex etc...a afficher.
Code:

1 2 3 4 5 6 7 8 9 void SystemGraphic::update() { for ( auto& it : _graphics ) { it.second.update() ; } }
Et l� , si le SystemPhysics, qui fonctionne sur le m�me model, a d�plac� le x de l'Entity, alors le graphics, lors de l'update, va automatiquement bouger l'image en fonction...

Donc je ne pensais mettre dans l'Entity que les donn�es fondamentales de l'objet, auquel certains composants auraient acc�s ( dsl, je m r�p�te un peu )

Mais tr�s vite, quand je veux cr�er un composant Control, par ex, se pose le dilem, en effet, pourquoi ne pas mettre dans l'Entity aussi un sf::IntRect, qui serait la zone de selection de l'objet, par ex etc...etc.
..
Et on arriverait vite a ce que tu dis, c'est a dire, surcharger l'Entity d'information. Ca reviendrait certainement au m�me au final de mettre directement l'Entity dans le system. Donc probablement � �viter...

Mais que pensez vous du concept, utilis� raisonnablement, et en shared_ptr pour l'Entity

Citation:

_time devrait �tre : force_refresh (proposition de leternel)

ah ? Ok , je voyais pas les choses comme ca...pourquoi force ?

Citation:

Bousk, c'est une mauvaise fa�on de faire. Ou alors tr�s �trange et prouvez-nous que cela marche.

Citation:

Oui, mais le jeux vid�o, ce n'est pas le domaine le plus simple. D'ailleurs, c'est peut �tre m�me le plus dur ou du moins, le plus multidisciplinaire. Voici mes points :
on commence par des exercices simples pour comprendre/apprendre le langage (et sa biblioth�que standard) ;
on commence par des jeux simples (oui, les jeux pourris style Pong, mais on peux trouver mieux et tout aussi simple) pour apprendre � faire un jeu vid�o (boucle de jeu, affichage, ...) ;
on fait son projet, petit morceau par petit morceau.

Oui c'est sur. Mais quand je dis que j'ai recommenc� 10 fois mon programme, il faut voir qu'il marchait � chaque fois. Dans mon dernier programme, par ex, je peux utiliser un Editeur pour faire des niveaux, jouer un niveau avec batiments, qui peuvent produire des unit�s, dont un worker qui peut a son tour cr�er de nouveaux batiments, qui peuvent cr�er d'autres unit�s. Une unit�e qui peut �galement chercher des ressources automatiquement, tirer des boules de feu. Sachant que chaque �l�ment contr�lable du jeu a ses icones, qui d�clenchent les actions qu'ils peuvent faire, et une minimap fonctionne avec la vision noirci des zones non d�couvertes, les points lumineux pour les objets qui bougent, etc... une ia basique, qui fait interagir certains objets etc...etc...et tout ca marche ( sur mes 2 pc, et c'est moche ).

Donc je pense que je peux y arriver. Mais plus j'avance, plus je r�alise que je peux faire les choses encore mieux. ( et que c'est m�me probablement n�cessaire, pour aller au bout ).

Voil� pourquoi j'ai d�cid� de suivre les conseils de gens exp�riment�s, et cette fois ci, apr�s avoir bien tourn� mon GD dans tous les sens, appris la programmation ( du moins le minimum n�cessaire en c++ ) et appr�hend� les besoins du jeux, aussi bien dans les contraintes graphiques, que physiques, de me lancer...d�finitivement.

On dit, je crois, que la programmation, c'est 90% de conception, et 10% de maintenance. Il est temps pour moi de faire une conception 100% definitive. ( bien que je ne sois pas exp�riment�, j'ai constat� que faire un programme depuis un concept bien �labor� est en fait rapide. Le plus long...c'est d'�laborer ! pour ma part je sais qu'en d�marrant la programmation, je pouvais passer 2 mois sur un programme que je ferais aujourd'hui en 2 jours, et qu'il serait en plus infiniment plus efficace.) C'est pour ca que je vais essayer de suivre au mieux les concepts dont vous parlez ici, a Developpez ( et vous en remercie encore infiniment :D ).

Bref, dsl, je raconte ma vie, mais c'est pour dire que je n'ai clairement pas l'intention de me d�gonfler. ;)

Citation:

Si je veux un joueur, je fais une instance de Entity, auquel je lui donne les composants :
Positionnable (une position) ;
Drawable (je veux l'afficher) ;
PlayerControllable (c'est le joueur qui le bouge ) ;
...

Oui, en fait dans mon cas, j'ai probablement invers� Entity avec Composant. ( sauf erreur ).

Citation:

Envoy� par LittleWhite

Comme dans ECS, il y a composant et entity, je pense qu'il y aura au moins deux classes : Entity, qui est une classe l�, juste pour contenir des Composants \*o / Et les composants, pour moi, c'�tait une classe m�re que l'on peux h�riter.

Si je veux un joueur, je fais une instance de Entity, auquel je lui donne les composants :

Positionnable (une position) ;
Drawable (je veux l'afficher) ;
PlayerControllable (c'est le joueur qui le bouge :)) ;
...

Enfin, moi, c'est comme �a que je vois la chose.

Si une entit� contient (=aggr�gation) des composants, et que ces composants peuvent �tre h�rit�s, on se retrouve avec une approche OO "classique" et un pattern strategy. On parlerait surement plus de comportements que de composants dans ce cas
Code:

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 36 37 // interfaces struct PositionnableBehavior {}; struct DrawableBehavior {}; struct ControllableBehavior {}; // quelques implémentations struct Immobile : PositionnableBehavior {}; // pour les objets fixes struct Mobile : PositionnableBehaviour {}; // pour les objets qui peuvent bouger struct Mesh : DrawableBehavior {}; struct Sprite : DrawableBehavior {}; struct Camera : DrawableBehavior {}; // ?? struct NotDrawable : DrawableBehavior {}; struct PlayerControlled : ControllableBehavior {}; struct IAControlled : ControllableBehavior {}; struct GameObject { PositionnableBehavior *p; DrawableBehavior *d; ControllableBehavior *c; void draw() { d->draw(); } void moveTo(vec2 newPosition) { p->moveTo(newPosition); } // ... }; // avec une factory struct Factory { GameObject makePlayer() { PositionnableBehavior *p = new Mobile(); DrawableBehavior *d = new Camera(); ControllableBehavior *c = new PlayerControlled(); return GameObject(p, d, c); } // ... };
Un principe diff�rent, mais valide.

Citation:

Envoy� par mazertys17

j'ai du mal m'exprimer, car je ne parle pas d'envoyer l'Entity dans les syt�mes, mais dans les composants ( qui en auraient besoin ), et d'o� le shared_ptr.

Dans un ECS, un "objet" est une entit� + des composants.

L'entit� est un simple identifiant (tu parles de donn�es fondamentales : fondamentalement une entit� n'a besoin que d'un identifiant unique).
Les composants sont des aspects qu'on vient greffer sur une entit�. Tu pr�vois un composant "Graphics", pourquoi pas un autre "Position" ?

En quoi la position est sp�ciale et doit �tre int�gr�e � l'entit� ? (J'avoue que j'ai du mal � trouver un exemple d'entit� qui n'aurait pas de position, mais �a existe surement).

Citation:

Les composants sont des aspects qu'on vient greffer sur une entit�. Tu pr�vois un composant "Graphics", pourquoi pas un autre "Position" ?

Donc dans ce cas on aurait quelque chose comme ceci, alors :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 void Game::add( float x , float y ) { .... Position position ( x , y ) ; SystemPosition.add ( _number, potition ) ; .... Graphics graph ; graph.setTexture ( textureExemple ) ; graph.setPosition ( &position ) ; SystemGraphic.add ( _number, graph ) ; .... }
Bon, sachant que c'est pour l'exemple, puis qu�ici la r�f�rence position n'a aucun sens...Est-ce bien l'id�e ?

En somme, cela voudrait dire que mon id�e de faire une Entity fourre tout n'est pas terrible ? :aie:

Et autre chose, est-ce une bonne id�e, selon vous, d'avoir un objet "Data", qui contiendrait des r�f�rences sur _force_refresh, _window etc..accessible par tous les composants ?

16/04/2015, 21h58
Iradrille

Un composant n'a normalement pas besoin de r�f�rencer un autre composant : ce sont 2 aspects distincts qui n'ont aucun rapport entre eux.

C'est un syst�me qui "fera la liaison" entre les diff�rents composants.
Par contre un syst�me utilise (et met � jours) des composants, mais ne les poss�de pas.

Si un syst�me g�re l'affichage d'entit�s, alors il traitera (toutes) les entit�s qui poss�dent � la fois un composant "Graphics" et un composant "Position" (et seulement celles l�).

Tu n'auras pas forc�ment un syst�me pour chaque composant s�par�ment (par exemple avec une position seule on peut pas faire grand chose, donc tu risques de pas avoir de syst�me pour cet unique composant).

Si on reprend l'exemple d'un syst�me pour g�rer les mouvements : il utilise les composants "Position" et "Velocity". "Position" est utilis� par 2 syst�mes ("SystemGraphic" et "SystemMove"), �a doit donc pas �tre contenu par un syst�me.

edit :

Citation:

Envoy� par mazertys17

Et autre chose, est-ce une bonne id�e, selon vous, d'avoir un objet "Data", qui contiendrait des r�f�rences sur _force_refresh, _window etc..accessible par tous les composants ?

Accessible par tous les composants, �a n'a pas de sens : un composant n'a pas de m�thodes il ne pourra rien en faire. Si c'est accessible par tous les syst�mes, pourquoi pas, s'ils en ont tous besoin.

Voir 40 message(s) de cette discussion en une page