Enregistrer un jeu Composants d'objets dans le jeu? Subsystems (Jeu basé sur la conception des composants de l'objet)

Question

Je crée un système d'objet jeu à base de composants . Quelques conseils:

1. GameObject est simplement une liste de Components.
2. Il y a GameSubsystems. Par exemple, le rendu, la physique, etc. Chaque GameSubsystem contient des pointeurs vers certains des Components. GameSubsystem est une abstraction très puissant et flexible. Il représente une tranche (ou aspect) du monde du jeu

Il est nécessaire dans un mécanisme d'enregistrement Components dans GameSubsystems (lorsque GameObject est créé et composé). Il y a 4 approches :

---

• 1: chaîne de modèle de responsabilité. Chaque Component est offert à tous les GameSubsystem. GameSubsystem prend une décision qui Components d'enregistrer (et comment les organiser). Par exemple, GameSubsystemRender peut enregistrer Renderable composants.

pro. rien savoir Components sur la façon dont ils sont utilisés. couplage faible. . Nous pouvons ajouter de nouvelles GameSubsystem. Par exemple, nous allons ajouter GameSubsystemTitles que tous les registres ComponentTitle et garantit que chaque titre est unique et offre une interface aux objets quering par titre. Bien sûr, ComponentTitle ne doit pas être Réécriture ou hérité dans ce cas. B. Nous pouvons réorganiser GameSubsystems existant. Par exemple, GameSubsystemAudio, GameSubsystemRender, GameSubsystemParticleEmmiter peut être fusionné dans GameSubsystemSpatial (pour placer tous les fichiers audio, emmiter, rendre Components dans la même hiérarchie et l'utilisation transforme relative au parent).

con. Chaque à chaque chèque. Très innefficient.

con. savoir de Subsystems à propos Components.

---

• 2. Chaque recherches Subsystem pour Components des types spécifiques

pro. Une meilleure performance que dans Approach 1.

con. Subsystems savoir encore sur les Components.

---

• 3: registres Component lui-même dans GameSubsystem(s). Nous savons à la compilation qu'il ya un GameSubsystemRenderer, donc nous allons ComponentImageRender appellera quelque chose comme GameSubsystemRenderer :: registre (ComponentRenderBase *).
  le modèle de l'observateur. Component est abonnée à l'événement "mise à jour" (envoyé par GameSubsystem(s)).

pro. Performance. Pas de chèques inutiles comme dans Approach 1 et Approach 2.

con. Components sont mal couplé avec GameSubsystems.

---

• 4: modèle médiateur. GameState (qui contient GameSubsystems) peut mettre en œuvre registerComponent (Component *).

pro. Components et le savoir de GameSubystems rien les uns des autres.

con. En C ++, il ressemblerait typeid-switch laid et lent.

---

Questions: Quelle est la meilleure approche et surtout utilisé dans la conception à base de composants? Qu'est-ce que dit la pratique? Toute suggestion mise en œuvre de Approach 4 sur (piloté par les données)?

Merci.

Answer 1

Voter pour la troisième approche.

Je travaille actuellement sur le système d'objets de jeu à base de composants et je vois clairement certains des avantages supplémentaires de cette approche:

• Le composant est de plus en plus sous-entité autosuffisante car elle ne dépend que d'un ensemble de sous-systèmes disponibles (je suppose que cet ensemble est fixé dans votre projet).

• conception axée sur les données est plus applicable. Idéalement, cette façon, vous pouvez concevoir un système dans lequel les composants sont complètement définis dans les termes de données, mais pas C ++.

---

EDIT: Une caractéristique i pensé à tout en travaillant sur CBGOS. Parfois, il est pratique d'avoir la capacité de concevoir et de construire subsystemless composants passifs. Lorsque cela est sur votre esprit la quatrième approche est la seule façon.

Answer 2

Mon approche a consisté à mettre en œuvre le modèle proxy au sein de chaque sous-système. Comme chaque sous-système est uniquement intéressé par un sous-ensemble de la totalité des composants de chaque entité peut contenir, les pointeurs proxy stocke aux seuls composants les soins du système au sujet, par exemple, un système de mouvement ne soucie de position et la vitesse, donc il a besoin d'un proxy qui stocke deux pointeurs, à ces composants. Si l'entité manque un ou plusieurs de ceux-ci, alors le sous-système ignorera. Si les deux composants sont présents, un noeud proxy est créé et ajouté à une collection interne. Il est également utile pour le proxy pour stocker la valeur d'identifiant unique pour l'entité, de sorte que les procurations peuvent être ajoutés / supprimés en temps constant de chaque sous-système, si cela était nécessaire.

Dans une telle façon, si une entité nécessaire pour être retiré du moteur, un seul message contenant l'identifiant de l'entité peut être envoyé à chaque sous-système. Le proxy peut alors être retiré de chaque sous-système de collecte de manière autonome.