Component Based Game Design - wie sieht das konkret aus?
-
Ich mache das nicht wirklich so wie in vielen Tutorials beschrieben wird, sondern habe einfach Abstand davon genommen einen Gottcontainer mit allen Spielobjekten zu benutzen. Wenn ich das erwähne dann eher damit der fragende TE, der in den meisten Fällen ziemlich unerfahren ist, mal eine andere Perspektive darauf bekommt wie man ein Spiel aufbauen kann und dass ein "class game_object" mit Vererbung in den allermeisten Fällen keine sonderlich gute Idee ist.
-
Habs mir jetzt auch ein Weilchen angelesen. Ich werde das Gefühl nicht los, daß ich lokal mit normaler Vererbung und gelegentlichen intrusiven doppelt verketteten Ringen viel besser aufgehoben wäre.
Für das MMORPG würde ich nicht anders vorgehen, außer daß Zeiger auf Objekte dann immer welteindeutige IDs wären.Das Hineinschubsen hat vielleicht den anderen Grund, daß entfernte "Scripter" was reindübeln können, ohne daß man eine LUA-Schnittstelle basteln muss. Also Trennung von Kernentwicklern und Storyentwicklern. Macht das unter Euch aus, wenn Ihr das trennen wollt. Vielleicht löst man da ein Nichtproblem mit fünffachem Aufwand.
-
cooky451 schrieb:
Ich mache das nicht wirklich so wie in vielen Tutorials beschrieben wird, sondern habe einfach Abstand davon genommen einen Gottcontainer mit allen Spielobjekten zu benutzen.
Wenn man das "klassische Gottcontainer Design" nimmt, und da den Gottcontainer entfernt, landet man aber immer noch lange nicht bei Component Based Design. Auch nicht bei einer Component Based Design ohne Cache-Optimierungen.
(Schonmal deswegen weil man den Gottcontainer bei Component Based Design ja trotzdem noch hat. Man verwendet ihn nur für die meisten Vorgänge nicht mehr. ;))Wenn ich das erwähne dann eher damit der fragende TE, der in den meisten Fällen ziemlich unerfahren ist, mal eine andere Perspektive darauf bekommt wie man ein Spiel aufbauen kann und dass ein "class game_object" mit Vererbung in den allermeisten Fällen keine sonderlich gute Idee ist.
Und ich frage mich, ob es Sinn macht einen unerfahrenen Entwickler etwas entgegenzuwerfen, wo ich als doch recht erfahrener Entwickler Schwierigkeiten habe zu verstehen wie es eigentlich gemeint ist.
Ich halte es durchaus für gut darauf hinzuweisen dass das von vielen Anfängern bevorzugte "IGameObject" Design nicht unbedingt gut ist. Ich denke aber dass jeder, und ganz speziell ein unerfahrener Entwickler, sich leichter tut das anhand von konkreten Beispielen zu verstehen. Und dass ich das was im Netz zum Thema "Component Based Design" so rumfliegt für reichlich wenig konkret halte, sollte ja mittlerweile klar sein.
-
hustbaer schrieb:
wenig konkret halte, sollte ja mittlerweile klar sein.
Es ist auch wenig konkret, aber die meisten Artikel beschreieben zumindest schön warum das klassische GameObject-Konzept so problematisch ist. Einen konkreten, guten Artikel zu: "So sollte man ein 3D-Spiel mit beliebigen Objekten und beliebiger Interaktion designen" ist mir leider nicht bekannt.
-
@cooky451
In den Artikeln die ich bisher gelesen habe, werden grösstenteils zwei Probleme erwähnt:-
Dass man in der klassischen Variante hunderte oder tausende Entity-Klassen hat und das ganze dadurch unübersichtlich wird.
Uff.
Hunderte oder tausende. Was sind das bitte für Spiele?
Klar, wenn ich 100 Mob-Typen habe, und stur für jeden Mob-Typ eine eigene Klasse schreibe, dann kann das schon sein. Nur wenn man das so macht, dann gehört man dafür verprügelt. Ich denke doch dass man in den meisten Spielen wo man 100 oder wenige 100 Entity-Typen hat, man die dafür nötige Anzahl an Klassen leicht auf 1/10 der Entity-Typen reduzieren kann.
100 Schwerter mit 100 verschiedenen Regeln wie der Damage berechnet wird, brauchen keine 100 verschiedenen Klassen, sondern genau eine. Mit nem kleinen "berechne mal eben den Damage" Script oder Funktor pro Schwert. Usw.
Bleiben also noch Spiele wo man wirklich so viele grundlegend unterschiedliche Entity-Typen hat, dass selbst 1/10 davon nocht zu viel ist um übersichtlich zu bleiben.
=> Uninteressant für jedes Projekt das jemand hier im Forum alleine ober mit ein paar Kumpels umsetzen wird. -
Performance.
Auch hier kommt man lange lange lange mit klassischem Design aus. Klar, man verschenkt dadurch Rechenzeit. So lange es schnell genug läuft, ist es aber eigentlich wurst wie viel schneller es laufen könnte, wenn man es anders machen würde.
Und das sind beides nicht die Probleme die der typische Anfänger-Entwickler hat.
Der typische Anfänger-Entwickler baut nämlich keine klassische Game-Architektur, sondern eine klassische Anfänger-Game-Architektur.
-
-
hustbaer schrieb:
Auch hier kommt man lange lange lange mit klassischem Design aus.
Wenn du mit "klassischem Design" meinst dass man von einer object Klasse erbt, nein. Das Problem damit ist ziemlich fundamental und hat eigentlich wenig mit der Menge an Klassen die man hat zu tun. Ganz einfaches Beispiel, hat man schon wenn man alle Objekte zeichnen will die "Drawable" sind. Wie findest du heraus welche Objekte das können?
-
Mich interessiert diese Component Based Game Design schon, nur mal so am Rande. Ich bin zwar weit davon entfernt ein Spiel entwickeln zu können, aber irgendwann will ich so etwas auch mal probieren.
Vor OOP-Design habe ich großen Respekt. So richtig weiß ich immer gar nicht wie ich was designen soll, wenn man bei mir überhaupt von Designer sprechen kann. Mir sind ein paar OOP-Pattern bekannt, aber so wirklich eigenen ausgefeilte Design fallen mir gar nicht ein. Ich mach halt erstmal das es funktioniert und schaue dann wo ich noch dran schrauben kann oder was ich komplett noch mal neu mache.
-
cooky451 schrieb:
hustbaer schrieb:
Auch hier kommt man lange lange lange mit klassischem Design aus.
Wenn du mit "klassischem Design" meinst dass man von einer object Klasse erbt, nein. Das Problem damit ist ziemlich fundamental und hat eigentlich wenig mit der Menge an Klassen die man hat zu tun. Ganz einfaches Beispiel, hat man schon wenn man alle Objekte zeichnen will die "Drawable" sind. Wie findest du heraus welche Objekte das können?
Warum sind die Objekte, die nicht drawable sind, überhaupt in der Liste der zu zeichnenden Objekte???
-
Genau das ist ja das Problem bei den Entitäten in Verbindung mit der Spiellogik und/oder Grafikprogrammierung.
Legt man für jede Funktionaliät eigene Listen an (drawable, hittable, ...) so ist der Aufwand enorm, diese Listen immer aktuell zu halten - und jede weitere Funktionaliät würde dann wieder eigene Listen erfordern. Dieses starre Design beeinträchtigt dann auch viele mögliche Spielerweiterungen (Features), z.B. temporäre Effekte oder Funktionskombinationen.Das Component Based Game Design dagegen konzentriert sich eben auf die Komponenten, so daß diese je Entität austauschbar sind. So bewahrt man sich eine große Flexibilität, jedoch kommt es eben dann auch zu den möglichen Problemen bei der Performance - und daher hat hustbaer ja diesen Thread erstellt.
@volkard, hast du auch nur schon mal im Ansatz überhaupt ein Spiel programmiert?
-
volkard schrieb:
Warum sind die Objekte, die nicht drawable sind, überhaupt in der Liste der zu zeichnenden Objekte???
-
cooky451 schrieb:
hustbaer schrieb:
Auch hier kommt man lange lange lange mit klassischem Design aus.
Wenn du mit "klassischem Design" meinst dass man von einer object Klasse erbt, nein. Das Problem damit ist ziemlich fundamental und hat eigentlich wenig mit der Menge an Klassen die man hat zu tun. Ganz einfaches Beispiel, hat man schon wenn man alle Objekte zeichnen will die "Drawable" sind. Wie findest du heraus welche Objekte das können?
Wenn die Frage ernst gemeint ist, dann hast du nichts verstanden.
Ich meine mit "klassischem Design" ganz normales, vernünftiges, nicht "component based" Softwaredesign.
Wieso meinst du dass da Gottklassen oder Gottinterfaces vorkommen würden, oder Listen wo haufenweise Objekte drin sind die nicht drin sein müssten?cooky451 schrieb:
volkard schrieb:
Warum sind die Objekte, die nicht drawable sind, überhaupt in der Liste der zu zeichnenden Objekte???
Nein, er hat vollkommen Recht.
Eine Liste wo nur "drawable" Objekte drin stehen hat mit Component Based Design so-gut-wie nichts zu tun.-----
BTW: Die Frage "drawable?" stellt sich normalerweise nicht. Die Trennung Logik/Grafik ist ja wohl quasi-Standard (oder sollte es zumindest sein).
D.h. man hat eine Struktur (Liste/Scene-Graph/...) in der man seine Entities (Logische Spielobjekte) verwaltet. Und diese besitzen dann "Drawables", die in einem eigenen Scene-Graph verwaltet werden.
Gezeichnet wird dann nur der "drawable" Scene-Graph. Das ist natürlich der selbe Ansatz wie bei Component Based Game Design. Macht man aber schon lange so. Bei Component Based Game Design geht es aber darum dass *alles* so gemacht wird, nicht nur ein Split zwischen Grafik und Logik.
Kurzfassung:
Klassisch = Graph mit Objekten
Component Based Game Design = Datenbank mit Tables
-
Th69 schrieb:
Das Component Based Game Design dagegen konzentriert sich eben auf die Komponenten, so daß diese je Entität austauschbar sind.
Versteh ich nicht. Erst redest du davon, dass das Problem wäre, dass man viele verschiedene Listen brauchen würde (find ich jetzt noch nicht unbedingt problematisch), und viel Aufwand dadurch entsteht, diese Listen aktuell zu halten (das schon eher).
Und dann kommt plötzlich dieser Satz und da sagst du, dass man die Komponenten pro Entität austauschen kann. Das hat ja mit den ganzen Listen nichts zu tun. Wenn es einen RenderManager gibt und er eine Liste von Renderables braucht, dann wird es ja dadurch nicht besser, dass die Klasse Spieler statt von Renderable abzuleiten in mehrere Komponenten aufteilst.
