Enregistrer les composants d'objet de jeu dans les sous-systèmes de jeu? (Conception d'objet de jeu basée sur les composants)

Je crée un système d'objets de jeu basé sur des composants . Quelques conseils:

GameObjectest simplement une liste de Components.
Il y en a GameSubsystems. Par exemple, le rendu, la physique, etc. Chacun GameSubsystemcontient des pointeurs vers certains Components. GameSubsystemest une abstraction très puissante et flexible: elle représente n'importe quelle tranche (ou aspect) du monde du jeu.

Il est nécessaire dans un mécanisme d'enregistrement Componentsen GameSubsystems(quand GameObjectest créé et composé). Il existe 4 approches :

1: Modèle de chaîne de responsabilité . Tout Componentest offert à tous GameSubsystem. GameSubsystemprend la décision Componentsde s'inscrire (et comment les organiser). Par exemple, GameSubsystemRender peut enregistrer des composants pouvant être rendus.

pro. Componentsne savent pas comment ils sont utilisés. Couplage bas. A. Nous pouvons en ajouter de nouveaux GameSubsystem. Par exemple, ajoutons GameSubsystemTitles qui enregistre tous les ComponentTitle et garantit que chaque titre est unique et fournit une interface pour interroger des objets par titre. Bien sûr, ComponentTitle ne doit pas être réécrit ou hérité dans ce cas. B. Nous pouvons réorganiser l'existant GameSubsystems. Par exemple, GameSubsystemAudio, GameSubsystemRender, GameSubsystemParticleEmmiter peuvent être fusionnés dans GameSubsystemSpatial (pour placer tous les fichiers audio, emmiter, restituer Componentsdans la même hiérarchie et utiliser des transformations relatives aux parents).

con. Chèque de chaque à chaque. Très inefficace.

con. Subsystemssavoir Components.

2: Chacun Subsystemrecherche Componentsdes types spécifiques.

pro. De meilleures performances qu'en Approach 1.

con. Subsystemssavoir encore Components.

3: Components'enregistre dans GameSubsystem(s). Nous savons au moment de la compilation qu'il existe un GameSubsystemRenderer, nous allons donc appeler ComponentImageRender quelque chose comme GameSubsystemRenderer :: register (ComponentRenderBase *).

pro. Performance. Pas de contrôles inutiles comme dans Approach 1.

con. Componentssont mal couplés avec GameSubsystems.

4: Motif médiateur . GameState(qui contient GameSubsystems) peut implémenter registerComponent (Component *).

pro. Componentset GameSubystemsne savent rien les uns des autres.

con. En C ++, cela ressemblerait à un commutateur de typeid laid et lent.

Questions: Quelle approche est la meilleure et la plus utilisée dans la conception basée sur les composants? Quelle pratique dit? Des suggestions sur la mise en œuvre de Approach 4?

Je vous remercie.

c++ architecture component-based

— en haut à droite
source

Je sens une ingénierie excessive. Les composants s'enregistrent auprès de GameObject. Si GameSubsystem est ce que je pense que c'est, alors ce n'est qu'une liste de composants qui peuvent être ajoutés à un GameObject à la fois. Comment vous le décrivez, il semble qu'il y ait une sorte de «magie» dans la façon dont les objets et les composants se réunissent (ils se recherchent? Pourquoi?) J'ai également l'impression que vous essayez d'utiliser des composants pour pratiquement tout dans votre moteur, ce que je reconsidérerais également. Pour ce que ça vaut, je ne considérerais que les options 3 ou 4.

— LearnCocos2D

@GamingHorror, Enregistrement Componentsen GameObjectsest hors de portée de ma question. Lisez des articles sur l'approche basée sur les composants ou posez votre propre question sur ce site si cela vous intéresse. Ce à quoi vous pensez GameSubsystemest totalement faux.

— au

Je suis partisan de développer des composants pour la logique du jeu, pas des composants de moteur, et votre description semble aller dans ce sens. Je comprends très bien les systèmes de composants, je pense que j'ai été dérouté parce que je ne connais pas la terminologie que vous avez utilisée, en particulier GameSubsystem. D'après ce que j'ai lu, il semblait que vous essayiez de tout construire (par exemple le moteur entier) uniquement à partir de composants.

— LearnCocos2D

Oui, "Objets de jeu basés sur des composants" et "Programmation orientée composants" sont des termes différents, cela peut prêter à confusion. Ne soyez pas biaisé, mieux vaut être "bilasé": scottbilas.com/files/2002/gdc_san_jose/game_objects_slides.ppt

— topright

Porte numéro 3 ... Le composant s'enregistre dans GameSubsystem (s)

Le composant est en place pour garder le couplage abstrait du GameObject lui-même. Quelque part, quelque part quelque chose a en fait besoin d'interagir avec les sous-systèmes et c'est le composant et son objectif.

Le couplage n'est pas vraiment une mauvaise chose dans ce cas.

Les performances sont essentiellement requises dans ce cas si vous vous attendez à avoir une complexité dans votre système, vous ne pouvez tout simplement pas vous permettre les approches de style de recherche des autres options.

Enfin, si un sous-système doit être réactif à un autre (rendu, physique, audio, tous doivent faire des choses quand quelque chose se passe), les composants peuvent faciliter cela les uns avec les autres à travers l'objet de jeu et garder ce type particulier de couplage de systèmes croisés gérable à travers le Composants.

— Meule
source

C'est bon. Mais comment les composants connaissent-ils les GameSubsystems? Tous les sous-systèmes sont-ils des singletons? Ce n'est pas moche? ... Je pense à une autre solution comme l'injection de dépendances ... mais quand et qui passe l'instance de sous-système à chaque composant?

— Dani

Les composants @Dani n'ont pas besoin d'accéder directement à l'instance de sous-système, ils ont juste besoin d'envoyer un message demandant que l'enregistrement soit fait, ils n'ont pas besoin de savoir ce qu'est le sous-système (mais ils le seront probablement) Et pourquoi seraient-ils des singletons? Ce n'est pas une exigence, même si dans la plupart des cas, vous n'aurez besoin que d'une seule instance de sous-système pour chaque sous-système.

— Pablo Ariel le

@Pablo - d'accord.

— Rick