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 :
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 ?
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.
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
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'
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)
Ok, je commence à y voir bien plus clair, merci à vous deux d'avoir rectifier ma vision de la chose.
...
ECS - Window (Entity ou Component ?)
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
...
Discord NaN. Mon site.
...
...
Discord NaN. Mon site.
...