Hi,
dies hier ist mein erster Beitrag hier im Forum. Ich habe mich angemeldet um zu folgender Situation Feedback zu bekommen: (Ist eine rein logische Frage zur Code-Philosophie)
Ich arbeite an der Code-Struktur für eine Spiele-Entwicklung und habe da momentan zwei Ansätze, beide auch schon im Code verwirklicht:
Erster Ansatz: Hierarchischer Ansatz. Es gibt verschiedene Ebenen wie z.B. "Vordergrund", "Hintergrund", "Zwischeneben 1", ... Diese jeweiligen Ebenen haben dann einzelne Objekte wie z.B. auch die Spielfigur, Gegner, Hindernisse und so weiter. Die Hintergrundebenen kümmern sich dabei um die grafische Ausfüllung, z.B. durch sich automatisch erweiternde Bäume und andere grafische Spielereien. Die jeweiligen Ebenen sind dabei voneinander getrennt und müssen zur Laufzeit auch keine Daten austauschen. Die Logik für Gegner, Spieler und andere Sachen findet in den jeweiligen Objekten selbst statt. Das Erstellen von neuen Objekte zur Laufzeit ebenfalls. Ggf. noch in der Ebene unterhalb. Niemals aber an einem gemeinsamen Punkt z.B. in einer "Controller"-Klasse oder gleichen.
Zweiter Ansatz: Component & Entity. Die Hierarchie beim Rendering ist die selbe. Jedoch gibt es eine "Master"-Klasse in der alle Entities, sprich Objekte wie Gegner, die Spielfigur, Hindernisse aber auch Ebenen, Kamera, etc. erzeugt werden und mit ihren jeweiligen Components, wie z.B. Rendering-Component, Scrolling-Component, Logic-Component, Kollisions-Component, etc. verbunden werden.
Beide Ansätze funktionieren. Nur verbraucht der zweite Ansatz ein wenig mehr Ressourcen und benötigt erheblich mehr Code für das Component&Entity System. Persönlich gefällt mir der Component&Entity Ansatz, also der zweite Ansatz, sehr gut. Nur eine Sache stört mich gewaltig: Im Gegensatz zur dezentralen Variante des ersten Ansatzes habe ich nun wieder eine riesige Klasse die sich um die Erstellung und Verbindung der Entities mit den jeweiligen Components kümmert. Auch wenn dies später beim Laden von Level-Daten ggf. von Vorteil sein kann, ist es für mich jedoch zur Zeit irgendwie hässlich mit anzusehen. Ein Auslagern der Erstellung in die jeweiligen Entities habe ich auch schon in Erwägung gezogen. Nur dann muss ich zwischen den Klassen wieder jede Menge Referenzen hin und herschicken und bin somit wieder fasst bei meinem ersten Ansatz.
Vielleicht habt ihr ja ähnliche Erfahrungen machen können? Was wäre euer Ansatz? Vielleicht habe ich das Entity&Component-Modell ja auch falsch verstanden!? Für welchen Ansatz würdet ihr euch entscheiden!?
Vielen Dank,
Simon
dies hier ist mein erster Beitrag hier im Forum. Ich habe mich angemeldet um zu folgender Situation Feedback zu bekommen: (Ist eine rein logische Frage zur Code-Philosophie)
Ich arbeite an der Code-Struktur für eine Spiele-Entwicklung und habe da momentan zwei Ansätze, beide auch schon im Code verwirklicht:
Erster Ansatz: Hierarchischer Ansatz. Es gibt verschiedene Ebenen wie z.B. "Vordergrund", "Hintergrund", "Zwischeneben 1", ... Diese jeweiligen Ebenen haben dann einzelne Objekte wie z.B. auch die Spielfigur, Gegner, Hindernisse und so weiter. Die Hintergrundebenen kümmern sich dabei um die grafische Ausfüllung, z.B. durch sich automatisch erweiternde Bäume und andere grafische Spielereien. Die jeweiligen Ebenen sind dabei voneinander getrennt und müssen zur Laufzeit auch keine Daten austauschen. Die Logik für Gegner, Spieler und andere Sachen findet in den jeweiligen Objekten selbst statt. Das Erstellen von neuen Objekte zur Laufzeit ebenfalls. Ggf. noch in der Ebene unterhalb. Niemals aber an einem gemeinsamen Punkt z.B. in einer "Controller"-Klasse oder gleichen.
Zweiter Ansatz: Component & Entity. Die Hierarchie beim Rendering ist die selbe. Jedoch gibt es eine "Master"-Klasse in der alle Entities, sprich Objekte wie Gegner, die Spielfigur, Hindernisse aber auch Ebenen, Kamera, etc. erzeugt werden und mit ihren jeweiligen Components, wie z.B. Rendering-Component, Scrolling-Component, Logic-Component, Kollisions-Component, etc. verbunden werden.
Beide Ansätze funktionieren. Nur verbraucht der zweite Ansatz ein wenig mehr Ressourcen und benötigt erheblich mehr Code für das Component&Entity System. Persönlich gefällt mir der Component&Entity Ansatz, also der zweite Ansatz, sehr gut. Nur eine Sache stört mich gewaltig: Im Gegensatz zur dezentralen Variante des ersten Ansatzes habe ich nun wieder eine riesige Klasse die sich um die Erstellung und Verbindung der Entities mit den jeweiligen Components kümmert. Auch wenn dies später beim Laden von Level-Daten ggf. von Vorteil sein kann, ist es für mich jedoch zur Zeit irgendwie hässlich mit anzusehen. Ein Auslagern der Erstellung in die jeweiligen Entities habe ich auch schon in Erwägung gezogen. Nur dann muss ich zwischen den Klassen wieder jede Menge Referenzen hin und herschicken und bin somit wieder fasst bei meinem ersten Ansatz.
Vielleicht habt ihr ja ähnliche Erfahrungen machen können? Was wäre euer Ansatz? Vielleicht habe ich das Entity&Component-Modell ja auch falsch verstanden!? Für welchen Ansatz würdet ihr euch entscheiden!?
Vielen Dank,
Simon