Enregistrer un jeu Composants d'objets dans le jeu? Subsystems (Jeu basé sur la conception des composants de l'objet)
-
08-10-2019 - |
Question
Je crée un système d'objet jeu à base de composants . Quelques conseils:
-
GameObject
est simplement une liste deComponents
. - Il y a
GameSubsystems
. Par exemple, le rendu, la physique, etc. ChaqueGameSubsystem
contient des pointeurs vers certains desComponents
.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 :
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
pourComponents
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 dansGameSubsystem(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é parGameSubsystem(s)
).
pro. Performance. Pas de chèques inutiles comme dans Approach 1
et Approach 2
.
con. Components
sont mal couplé avec GameSubsystems
.
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.
La solution
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.
Autres conseils
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.