Bonsoir, bonsoir,

Je me suis remis doucement dans la création d'un ECS. Donc j'avançais tranquillement quand j'en suis arrivé à l'étape de le fenêtre.

Plusieurs questions me taraudent, d'abord est-ce que je dois voir la fenêtre comme une entité ou comme un composant ? Dans un premier temps, je me suis dit que j'allais en faire une entité mais... je me suis dis que ce serait peut-être mieux d'en faire un composant qui serait "attaché" à une entité Game par exemple. Mais j'ai de gros doutes quand même. Pour l'instant, je l'ai mise dans les composants :

struct Window : public BaseComponent
{
    Window(
        unsigned windowWidth,
        unsigned windowHeight,
        const std::string& title)
    :
        windowWidth{windowWidth},
        windowHeight{windowHeight},
        title{title}
    {}

    unsigned windowWidth{};
    unsigned windowHeight{};
    std::string title{};
};

Ensuite, si j'arrive à finaliser l'ECS, je l'utiliserai pour travailler avec la SFML, mais du coup je ne sais pas trop sur quel pied danser au niveau des composants. Par exemple pour une fenêtre SFML, je sais que j'aurais besoin de la structure sf::ContextSettings pour l'initialiser correctement selon les besoins, mais si je l'inclus dans l'ECS, il y aura dépendance... et j'imagine que ce n'est pas ce qu'on veut dans un ECS. Du coup comment faire ? Utiliser des structs templates pour certains composants ?

Par avance merci.

-
Edité par Guit0Xx 2 novembre 2018 à 1:11:54

Pour moi, Game et Window ne sont ni des entités, ni des composants.

Ok, donc j'étais hors-sujet, vaut mieux voir ça comme un système.

J'ai quand même un mal de chien à me débarasser de la pensée OO. Par exemple, j'ai toujours eu l'habitude d'avoir une classe Game, qui gère un objet Window, du coup j'ai un peu de mal à concevoir le bazar dans un ECS.

Guit0Xx a écrit:

Ok, donc j'étais hors-sujet, vaut mieux voir ça comme un système.

J'ai quand même un mal de chien à me débarasser de la pensée OO. Par exemple, j'ai toujours eu l'habitude d'avoir une classe Game, qui gère un objet Window, du coup j'ai un peu de mal à concevoir le bazar dans un ECS.

ECS != pas de classe.
ECS c'est le paradigme utiliser concernant la logique de jeu et ses game objects , mais rien t'empeche d'avoir des classe classique alentour de l'ecs .. Un classe window qui se charge , render , update comme elle serait probablement intuitivement implemente et ce qui serait par exemple membre de ton "systeme graphique'

-
Edité par CrevetteMagique 2 novembre 2018 à 15:34:27

Zérotisme a écrit:

ECS != pas de classe.

Ok ! Tu m'enlèves un voile là. J'ai toujours pensé le contraire du fait que, bien souvent dans la description d'un ECS, on nous explique que les données et les fonctions sont séparées.

Zérotisme a écrit:

ECS c'est le paradigme utiliser concernant la logique de jeu et ses game objects , mais rien t'empeche d'avoir des classe classique alentour de l'ecs .. Un classe window qui se charge , render , update comme elle serait probablement intuitivement implemente et ce qui serait par exemple membre de ton "systeme graphique'

D'accord, je vois 

Oui. L'ECS est une approche "data driven", c'est a dire qu'on reflechie en termes de flux de données en priorité. Mais pour implémenter ces flux de données, rien n'interdit de créer des classes.

Voire même d'avoir de l'héritage. On pourrait avoir par exemple une classe de base Renderer et des classes dérivées OpenGLRenderer et VulkanRendered, ca ne pose pas forcement de problème. (Ce qui pose probléme, c'est le cout en performance de l'héritage, donc on évite d'utiliser dans un flux de données tres consomateur)

Pour simplifier comment je vois l'ECS :

- entity = éléments du jeu (pas du point de vue du developpeur, mais du point de vue du gameplay)

- composant = data

- systeme = comportements (= algos)

Ok, je commence à y voir bien plus clair, merci à vous deux d'avoir rectifier ma vision de la chose.