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