Quel est le rôle des «systèmes» dans une architecture d'entité à base de composants?


177

J'ai beaucoup lu sur les composants et les systèmes des entités et je pense que l'idée d'une entité qui n'est qu'un identifiant est très intéressante.

Cependant, je ne sais pas comment cela fonctionne complètement avec les composants ou les systèmes. Un composant est simplement un objet de données géré par un système pertinent. Un système de collision utilise un composant BoundsComponent avec une structure de données spatiales pour déterminer si des collisions ont eu lieu.

Tout va bien jusqu'à présent, mais que se passe-t-il si plusieurs systèmes ont besoin d'accéder au même composant? Où les données doivent-elles vivre? Un système d'entrée peut modifier un BoundsComponent d'entités, mais le ou les systèmes physiques doivent avoir accès au même composant que certains systèmes de rendu.

Aussi, comment les entités sont-elles construites? L'un des avantages dont j'ai beaucoup entendu parler est la flexibilité dans la construction d'entités. Les systèmes sont-ils intrinsèquement liés à un composant? Si je veux introduire un nouveau composant, dois-je aussi introduire un nouveau système ou en modifier un existant?

Une autre chose que j'ai souvent lue est que le «type» d'une entité est déduit de ses composants. Si mon entité est juste un identifiant, comment puis-je savoir que mon entité robot doit être déplacée ou restituée et donc modifiée par un système?

Désolé pour le long post (ou du moins, il semble que tel soit le cas de l'écran de mon téléphone)!

Réponses:


336

Il existe une multitude de façons de représenter et d'implémenter des systèmes de composants d'entités, mais voici une explication d'une manière. N'oubliez pas qu'il n'existe pas de définition concrète des architectures d'entité / composant / système, il ne s'agit donc que d'une implémentation.

Je vais introduire une analogie pour les architectures entité / composant / système qui pourrait aider. Pensons à une entité comme une clé.

L'entité

Clé d'entité

Les clés ont aussi des dents (bleu foncé). Les dents de notre clé d'entité sont les composants qui le composent. Vous pouvez distinguer les entités par leur ID, même si elles ont les mêmes dents. Alors, à quoi correspondent les clés? Serrures Les serrures sont nos systèmes. Par exemple, un système de mouvement.

Le système

Verrouillage du système de mouvement

La serrure ne fonctionne que si notre clé a des dents pour la position et la vitesse. Ce système ne traite que les entités qui ont une position et une vitesse. Il existe de nombreuses façons de définir comment ces systèmes reconnaissent les entités à traiter, mais l'une d'elles consiste à utiliser a long. Chaque bit est réservé à un type de composant. Pour notre exemple, supposons un type 4 bits au lieu de 64 bits. Notre exemple d'entité aurait tous les composants disponibles. Donc, la clé serait 1111. Ensuite, le système recherche toute entité possédant un 11--. (Le -représentant s'en fiche, car le mouvement ne se soucie pas de savoir s'il y a un sprite ou de la santé). Il peut vérifier une entité avec une simple ANDopération. Donc, notre entité correspond si ((1111 & 1100) == 1100). Si je vous ai perdu là-bas, jetez un œil aux opérations sur les bits .

Comme vous pouvez le constater, les systèmes ont accès à des ressources externes. Ils peuvent accéder à l’heure, aux graphiques, au son, etc. Ce sont simplement de petits processeurs qui utilisent une clé à la fois et traitent les données. Vous voyez que le système de déplacement prend la vitesse, le temps delta et la position; effectue ensuite des calculs et stocke le résultat dans sa position.

Les clés d'entité sont vraiment faciles à générer. Vous pouvez les ajouter ou les supprimer à volonté. L'entité s'en fiche, c'est juste une façon de regrouper et de contenir les composants. Les composants n'ont pas d'interdépendance. Les composants sont le plus près de l'interaction les uns avec les autres lorsqu'un système les exploite et utilise les données de l'un pour en mettre à jour un autre, comme dans notre exemple de mouvement.

Jetons un coup d'oeil à un autre système pour aider à concrétiser l'idée:

Verrouillage du système de dessin

Ceci est notre système de dessin. Il recherche les composants qui correspondent 1-1-. Cette entité correspond car: ((1111 & 1010) == 1010)En outre, vous pouvez voir que ce système affiche les informations à l'écran en dessinant l'image-objet de l'entité à sa position.

OK, un de plus. Regardons une autre entité et voyons comment cela pourrait s’intégrer à notre exemple jusqu’à présent.

Clé d'entité non mobile

Comme vous pouvez le constater, cette entité contient moins de composants. En regardant les composants dont il dispose, il semble que cela pourrait être un élément statique comme une roche. Il a juste une position et un sprite. Il ne va pas bouger et il ne va pas être affecté par aucun changement de santé. Cette entité produirait une clé de 1010. Alors, quels systèmes fonctionnent sur cette entité? Allons vérifier:

Contre notre système de mouvement: ((1010 & 1100) != 1100)Nope. On dirait que le système de déplacement ne se soucie pas de cette entité, car il ne dispose pas des composants nécessaires.

Contre notre système de dessin: ((1010 & 1010) == 1010)Hé, c'est un match. Cette entité sera exploitée par le système de dessin. Le système de dessin dessine l'image-objet à la position définie.


J'espère que vous pourrez voir à quel point il serait facile d'ajouter maintenant un autre système prenant en charge nos composants et les exploitant. Laissez-moi m'assurer que j'ai répondu à vos questions:

Et si plusieurs systèmes ont besoin d'accéder au même composant? Où les données doivent-elles vivre?

En règle générale, les systèmes fonctionnent les uns après les autres. Ils traitent toutes les entités qui correspondent à leurs besoins, puis le système suivant fait de même, etc. Les données vivent avec l'entité. Il ne devrait y avoir rien stocké dans le système, c'est juste un verrou qui se tourne, la clé est l'endroit où l'information reste et se déplace de verrouillage à verrouillage.

Comment sont construites les entités? Les systèmes sont-ils intrinsèquement liés à un composant? Si je veux introduire un nouveau composant, dois-je aussi introduire un nouveau système ou en modifier un existant?

Les entités ne sont que des sacs de composants. Ils ont un identifiant unique et une liste de composants. Les systèmes ne sont liés aux composants que de la manière décrite ci-dessus. Vous pouvez avoir des composants sans systèmes qui les exploitent, mais c'est plutôt inutile. De même, vous pouvez avoir des systèmes qui recherchent des composants qu'aucune entité n'a. C'est moins inutile, car ils peuvent simplement attendre la création d'une entité correspondant à leur verrou. Donc, oui, si vous introduisez un nouveau composant, vous souhaiterez créer un système utilisant ce composant. Sinon, vous ne faites qu'ajouter des dents à votre clé pour une serrure qui n'existe pas.

Si mon entité est juste un identifiant, comment puis-je savoir que mon entité robot doit être déplacée ou restituée et donc modifiée par un système?

Je pense que je réponds à cela avec l'idée d'une longclé qui définit les composants contenus dans une entité. Vous savez parce que la clé correspond à la serrure.

Phew! C'était un long post! (Ou du moins, cela semble être le cas de mon grand moniteur.)


23
Cette analogie clé est vraiment utile pour comprendre l’idée dans son ensemble maintenant. Idée brillante! Lol à votre dernier paragraphe :)
bio595

16
+1 Pour la meilleure explication du système de composant entité que j'ai jamais vu. : O!
knight666

7
-1 de ma part - non pas parce que c'est une mauvaise approche, mais parce qu'elle est décrite comme étant l'approche. Pourtant, de nombreux systèmes ne séparent pas les composants et les services (par exemple, dans Unity), et il existe des moyens plus simples pour les systèmes de savoir quelles entités doivent être traitées (ajoutez-les simplement lors de la création de l'entité).
Kylotan

37
@Kylotan, je dis " Il existe plusieurs façons de définir comment ces systèmes reconnaissent les entités à traiter, mais l'une d'elles consiste à utiliser unlong " . En outre, je réserve généralement le vote à la baisse aux réponses qui ne sont pas utiles (comme le dit). Je pense que vous perdriez beaucoup de temps à voter si vous le faisiez pour toutes les réponses qui ne couvraient pas 100% des sujets abordés.
MichaelHouse

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.