Du bist nicht angemeldet.

Werbeanzeige

Julién

Alter Hase

  • »Julién« ist der Autor dieses Themas

Beiträge: 723

Wohnort: Bayreuth

Beruf: Student | Hilfswissenschaftler in der Robotik

  • Private Nachricht senden

1

30.12.2014, 01:12

ECS | Organisation der Entitys / Actors

Guten Abend,
ich spiele jetzt mit meiner Variante einer naive ECS Implementation herum.
Das Grundkonzept habe ich verstanden; gemeint: Idee hinter Componenten und den Entitys.
Bei mir herscht jedoch eine gewisse Unsicherheit, wenn ich darüber nachdenke wie die Entitys verwaltet werden.
Ich habe eine Singletonklasse "EntityManager", die jedes Entity direkt bei der Erzeugung erhält und in einer "List<Entity>" speichert.
Der EntityManager hat eine Methode "updateEntitys", die über jedes Entity und über jedes Component loopt.

Ist diese Vorgehensweise richtig bzw. auf dauer "praktikabel" ?
Was könnte ich besser machen? Kann man die Entitys besser verwalten?
Denn in der Hinsicht konnte ich nichts zum ECS finden.

Gruß Julién
I write my own game engines because if I'm going to live in buggy crappy filth, I want it to me my own - Ron Gilbert

DeKugelschieber

Community-Fossil

Beiträge: 2 664

Wohnort: Rheda-Wiedenbrück

Beruf: Software-Entwickler

  • Private Nachricht senden

2

30.12.2014, 01:41

Du hast das S für System vergessen. Ein Singelton dass alle Entities updatet? Dann muss die Logik dafür ja in das Entity oder in die Komponenten.
Bei dem System sind die Komponenten jedoch nur als Datenhalter gedacht und die Entities als Zusammenfassung von Komponenten.
Für die Logik nutzt du dann Systeme die auf den Enities mit ihren Komponenten operieren. Dadurch hast du spezialisierte System (= Logik) und kannst auch Components aus den Entities entfernen, ohne alles kaputt zu machen.

Hier einmal in JavaScript, hier in C++ und hier in Java, ja ich mag das System :D
In den Projekten findest du auch Systeme die tatsächlich etwas tun. Und vielleicht noch der Hinweis dass ich mich nicht immer zu 100% an die "Vorgabe" halte.

buggypixels

Treue Seele

Beiträge: 125

Wohnort: Meerbusch

Beruf: Programmierer

  • Private Nachricht senden

3

30.12.2014, 08:49

Ich empfehle folgende Lektüre:
http://bitsquid.blogspot.de/2014/08/buil…ity-system.html
Ist kompliziert aber gut.
Außerdem würde ich den BurningByte Code eher nur als Orientierung in Betracht ziehen.
Oder besser gar nicht, da er dich eher auf den falschen Weg bringt.

DeKugelschieber

Community-Fossil

Beiträge: 2 664

Wohnort: Rheda-Wiedenbrück

Beruf: Software-Entwickler

  • Private Nachricht senden

4

30.12.2014, 11:24

Ist ganz klar Interpretationssache. Ich hab jetzt 10 Artikel mit 10 Ansätzen gefunden.
Bei meiner Variante würde ich in der C++ Version schon ein paar Dinge wieder anders machen.

Zitat von »buggypixels«

Oder besser gar nicht, da er dich eher auf den falschen Weg bringt.

Warum?

Julién

Alter Hase

  • »Julién« ist der Autor dieses Themas

Beiträge: 723

Wohnort: Bayreuth

Beruf: Student | Hilfswissenschaftler in der Robotik

  • Private Nachricht senden

5

30.12.2014, 14:04

@DeKugelschieber:
Ich glaube du hast den neuesten Code noch nicht hochgeladen. Alles was ich gestern gesehen habe, das waren leere Klassendeklarationen.

Für mein Verständnis bitte:

Entity / Actor / GameObject:
- Das Objekt im Spiel
- Hat eine ID, ev. Namen
- Ein Array von Component Pointern

Component / Behvaiour:
- Eig. nur Informationen
- Hat einen Pointer auf das Objekt, dass dieses Component enthält
- Ist irgendwie identifizierbar um es den Systemen zu zuordnen

System:
- Eine Klasse die nur bestimmte Components bearbeitet
- ev. ein eigener Thread

Jetzt ist meine Frage wie ich die Components den Systemen zuordnen kann.


Ich werde mir zwar die nächste "iX Developer" holen, die eine gute Erklärung des ECS haben soll, dennoch fände ich es toll wenn jemand es mir erklären könnte.

Gruß Julién
I write my own game engines because if I'm going to live in buggy crappy filth, I want it to me my own - Ron Gilbert

DeKugelschieber

Community-Fossil

Beiträge: 2 664

Wohnort: Rheda-Wiedenbrück

Beruf: Software-Entwickler

  • Private Nachricht senden

6

30.12.2014, 15:48

Ich glaube du hast den neuesten Code noch nicht hochgeladen. Alles was ich gestern gesehen habe, das waren leere Klassendeklarationen.

Dann hast du nicht richtig geguckt. Dass z.B. Component leer ist ist ja klar, die Klasse dient nur als Basis. Dass man diese in JS z.B. auch gar nicht brauch auch.
Guck dir mal konkrete Implementierungen an, z.B. dieses Ding.

Hier hast du auch noch eine Grafik:


(Link)


Mach dir da um die Details nicht zu viele Gedanken, das ganze soll ja nur als Gerüst dienen. Letztendlich könnte man es auch ohne irgendetwas vorher zu schreiben nutzen.

PuppetMaster

Frischling

Beiträge: 20

Beruf: Embedded-System Entwickler (C++)

  • Private Nachricht senden

7

30.12.2014, 16:08

Warum sollten die Komponenten einem System fest zugeordnet werden?
Die Dynamik (und damit alle Vorteile von CBSE "Component Based System Engineering") gehen damit doch verloren...

Ein Beispiel:

Das Entity welches den Player repräsentiert hat eine Komponente Position.
Mit dem Input System werden Eingaben aufgenommen.
Ein System Movement reagiert auf Eingaben aus dem Input System (evtl. später auch aus dem AI System).
Im System Collision wird überprüft ob eine Änderung der Position plausibel ist, oder ob bestimmte Collision-Trigger aufgerufen werden.
Das PauseMenu System reagiert auf Eingaben aus dem Input System.

Bild:

(Link)


Die Komponente Position ist unabhängig von den Systemen, deshalb lässt sich ein weiteres System welches mit der Position arbeitet beinahe ohne Implikationen hinzufügen.
Das Einzige was bei den Systemen feststeht sind die Events auf die sie reagieren, und dass eine Komponente Position vorhanden sein muss.

MfG
PuppetMaster

Zitat von »"Billy Talent - Fallen Leaves"«

Run away before you drown, or the streets will beat you down.
Fallen leaves, fallen leaves, fallen leaves on the ground.

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »PuppetMaster« (30.12.2014, 16:16)


Schorsch

Supermoderator

Beiträge: 5 205

Wohnort: Wickede

Beruf: Student

  • Private Nachricht senden

8

30.12.2014, 19:57

Du kannst das ganze auch noch weiter führen und dir dir Entity Klasse komplett sparen. Ein Entity ist an sich nur eine Sammlung von Komponenten. Also brauchst du eine Schnittstelle für eine Komponente. Ein Entity ist nun eine Liste vom Typ dieser Schnittstelle. Die einzelnen Komponenten kommunizieren dann wie in der Grafik von PuppetMaster. Ein Objekt ergibt sich also nur aus seiner Logik.
„Es ist doch so. Zwei und zwei macht irgendwas, und vier und vier macht irgendwas. Leider nicht dasselbe, dann wär's leicht.
Das ist aber auch schon höhere Mathematik.“

Julién

Alter Hase

  • »Julién« ist der Autor dieses Themas

Beiträge: 723

Wohnort: Bayreuth

Beruf: Student | Hilfswissenschaftler in der Robotik

  • Private Nachricht senden

9

31.12.2014, 18:27

Puh,
schwerer als ich erwartet habe.

Danke für die Antworten!
Ich hoffe ich habe es jetzt verstanden.

Gruß Julién
I write my own game engines because if I'm going to live in buggy crappy filth, I want it to me my own - Ron Gilbert

Schorsch

Supermoderator

Beiträge: 5 205

Wohnort: Wickede

Beruf: Student

  • Private Nachricht senden

10

01.01.2015, 17:50

Es ist halt Event getrieben. Da geht man ganz anders vor als sonst. Versuch doch vielleicht erst mal das ganze in klein umzusetzen. Vielleicht einfach mal in Unity da dir die ganze Verwaltung schon abgenommen wird.
„Es ist doch so. Zwei und zwei macht irgendwas, und vier und vier macht irgendwas. Leider nicht dasselbe, dann wär's leicht.
Das ist aber auch schon höhere Mathematik.“

Werbeanzeige