Je ne comprends pas trop pourquoi tu t'embêtes à essayer de séparer arbitrairement ce qui est statique du reste.
Ce n'est pas arbitraire, ça a du sens du point de vue de l'application globale et d'un jeu en particulier.
Le fait que la masse ne change pas n'est pas lié au fait que la propriété 'masse' appartienne au composant 'physique'.
Si. La question c'est : «est-ce que tu vas devoir sauvegarder la masse parce qu'elle change pour chaque entité ou est-ce que l'information de masse va venir d'un fichier de config pour toutes les entités ?» Dans le premier cas, il faut la mettre directement dans le composant, dans le second, elle est dans un fichier de config. Ça change la manière de charger et de sauvegarder si on est dans un cas ou dans l'autre. Et après, tu as l'intermédiaire, c'est-à-dire qu'un type d'entités peut partager un ensemble de configurations possibles que tu vas identifier dans un composant (avec un enum ou un entier par exemple).
La logique que j'utilise pour mes composants c'est simplement d'y mettre toutes les entrées/sorties d'un système - au moins on voit clairement ce que manipule un système.
C'est ce que je fais aussi, mais par exemple, mettre tous les tuiles du fond de cartes dans des composants, c'est con. Outre le fait que c'est sous-optimal pour plein de raisons, ça n'a rien à faire là. Et pourtant, le système qui gère l'affichage, il mange des composants avec des sprites donc il pourrait manger des tuiles.
[^] # Re: Système à entité
Posté par rewind (Mastodon) . En réponse à la dépêche Je crée mon jeu vidéo E13 : un an, premier bilan. Évalué à 2.
Ce n'est pas arbitraire, ça a du sens du point de vue de l'application globale et d'un jeu en particulier.
Si. La question c'est : «est-ce que tu vas devoir sauvegarder la masse parce qu'elle change pour chaque entité ou est-ce que l'information de masse va venir d'un fichier de config pour toutes les entités ?» Dans le premier cas, il faut la mettre directement dans le composant, dans le second, elle est dans un fichier de config. Ça change la manière de charger et de sauvegarder si on est dans un cas ou dans l'autre. Et après, tu as l'intermédiaire, c'est-à-dire qu'un type d'entités peut partager un ensemble de configurations possibles que tu vas identifier dans un composant (avec un enum ou un entier par exemple).
C'est ce que je fais aussi, mais par exemple, mettre tous les tuiles du fond de cartes dans des composants, c'est con. Outre le fait que c'est sous-optimal pour plein de raisons, ça n'a rien à faire là. Et pourtant, le système qui gère l'affichage, il mange des composants avec des sprites donc il pourrait manger des tuiles.