Spielobjektkomponenten in Spiel-Subsystemen registrieren? (Komponentenbasiertes Spielobjektdesign)

Ich erstelle ein komponentenbasiertes Spielobjektsystem . Einige Hinweise:

GameObjectist einfach eine Liste von Components.
Es gibt GameSubsystems. Zum Beispiel Rendering, Physik usw. Jedes GameSubsystementhält Zeiger auf einige von Components. GameSubsystemist eine sehr mächtige und flexible Abstraktion: Sie repräsentiert jeden Teil (oder Aspekt) der Spielwelt.

Es besteht ein Bedarf in einem Mechanismus der Registrierung Componentsin GameSubsystems(wenn GameObjecterstellt und zusammengesetzt). Es gibt 4 Ansätze :

1: Muster der Verantwortungskette . Jeder Componentwird jedem angeboten GameSubsystem. GameSubsystemtrifft eine Entscheidung, welche Componentsregistriert werden soll (und wie sie organisiert werden sollen). Beispielsweise kann GameSubsystemRender renderbare Komponenten registrieren.

Profi. Componentsweiß nichts darüber, wie sie verwendet werden. Niedrige Kopplung. A. Wir können neue hinzufügen GameSubsystem. Fügen wir beispielsweise GameSubsystemTitles hinzu, das alle ComponentTitle registriert und garantiert, dass jeder Titel eindeutig ist und eine Schnittstelle zum Abfragen von Objekten nach Titel bietet. Natürlich sollte ComponentTitle in diesem Fall nicht neu geschrieben oder vererbt werden. B. Wir können bestehende neu organisieren GameSubsystems. Beispielsweise können GameSubsystemAudio, GameSubsystemRender und GameSubsystemParticleEmmiter in GameSubsystemSpatial zusammengeführt werden (um alle Audiodaten, Emmiter, Rendering Componentsin derselben Hierarchie zu platzieren und übergeordnete relative Transformationen zu verwenden).

con. Jeder Scheck. Sehr ineffizient.

con. Subsystemswissen über Components.

2: Jeder Subsystemsucht nach Componentsbestimmten Typen.

Profi. Bessere Leistung als inApproach 1 .

con. Subsystemsnoch wissen über Components.

3: Componentregistriert sich in GameSubsystem(s). Wir wissen zur Kompilierungszeit, dass es einen GameSubsystemRenderer gibt. Lassen Sie uns also ComponentImageRender so etwas wie GameSubsystemRenderer :: register (ComponentRenderBase *) aufrufen.

Profi. Performance. Keine unnötigen Überprüfungen wie inApproach 1 .

con. Componentssind schlecht gekoppelt mit GameSubsystems.

4: Mediatormuster . GameState(das enthält GameSubsystems) kann registerComponent (Component *) implementieren.

Profi. ComponentsundGameSubystems nichts voneinander wissen.

con. In C ++ würde es wie ein hässlicher und langsamer Typeid-Switch aussehen.

Fragen: Welcher Ansatz ist besser und wird hauptsächlich im komponentenbasierten Design verwendet? Welche Praxis sagt? Anregungen zur Umsetzung vonApproach 4 ?

Vielen Dank.

c++ architecture component-based

— oben rechts
quelle

Ich rieche nach Überentwicklung. Komponenten registrieren sich bei GameObject. Wenn GameSubsystem das ist, was ich denke, dann ist es nur eine Liste von Komponenten, die einem GameObject gleichzeitig hinzugefügt werden können. Wie Sie es beschreiben, klingt so, als ob es eine Art "Magie" gibt, wie GameObjects und Komponenten zusammenkommen (sie suchen sich gegenseitig? Warum?). Ich habe auch das Gefühl, dass Sie versuchen, Komponenten für praktisch alles in Ihrem Motor zu verwenden, was ich auch noch einmal überdenken würde. Für das, was es wert ist, würde ich nur die Optionen 3 oder 4 in

— Betracht ziehen.

@GamingHorror, Die Registrierung Componentsin GameObjectsist nicht Gegenstand meiner Frage. Lesen Sie Artikel über komponentenbasierte Ansätze oder stellen Sie auf dieser Website eigene Fragen, wenn Sie daran interessiert sind. Was Sie denken, GameSubsystemist völlig falsch.

— Topright

Ich bin voreingenommen gegenüber der Entwicklung von Komponenten für die Spielelogik, nicht von Engine-Komponenten, und Ihre Beschreibung schien in diese Richtung zu weisen. Ich verstehe Komponentensysteme sehr gut. Ich glaube, ich bin vom Kurs abgekommen, weil ich mit der von Ihnen verwendeten Terminologie, insbesondere GameSubsystem, nicht vertraut bin. Nach dem, was ich gelesen habe, hörte es sich so an, als würden Sie versuchen, alles (z. B. den gesamten Motor) nur aus Komponenten zu bauen.

— LearnCocos2D

Ja, "Komponentenbasierte Spielobjekte" und "Komponentenorientierte Programmierung" sind unterschiedliche Begriffe. Dies kann verwirrend sein. Seien Sie nicht voreingenommen, sondern "bilasiert": scottbilas.com/files/2002/gdc_san_jose/game_objects_slides.ppt

— topright

Tür Nummer 3 ... Komponente registriert sich in GameSubsystem (s)

Die Komponente ist vorhanden, um die Kopplung vom GameObject selbst zu abstrahieren. Irgendwie muss tatsächlich irgendwo etwas mit den Subsystemen interagieren, und dies ist die Komponente und ihr Zweck.

Die Kopplung ist in diesem Fall eigentlich keine schlechte Sache.

Die Leistung ist in diesem Fall im Wesentlichen erforderlich , wenn Sie eine Komplexität in Ihrem System erwarten, können Sie sich die Suchstilansätze der anderen Optionen einfach nicht leisten.

Wenn ein Subsystem auf ein anderes reagieren muss (Renderer, Physik, Audio müssen alle Dinge tun, wenn etwas passiert), können die Komponenten dies durch das Spielobjekt miteinander ermöglichen und diese bestimmte Art der systemübergreifenden Kopplung über das Spielobjekt verwalten Komponenten.

— Rick
quelle

Das ist gut. Aber woher wissen Komponenten über GameSubsystems Bescheid? Sind alle Subsysteme Singletons? Das ist nicht hässlich? ... Ich denke über eine andere Lösung wie die Abhängigkeitsinjektion nach ... aber wann und wer übergibt die Subsysteminstanz an jede Komponente?

— Dani

@Dani-Komponenten müssen nicht direkt auf die Subsysteminstanz zugreifen, sondern nur eine Nachricht senden, in der die Registrierung angefordert wird. Sie müssen nicht wissen, was das Subsystem ist (aber sie werden es höchstwahrscheinlich tun) und warum wären sie Singletons? Dies ist keine Voraussetzung, auch wenn Sie in den meisten Fällen nur eine einzige Subsysteminstanz für jedes Subsystem benötigen.

— Pablo Ariel

@Pablo - stimme zu.

— Rick