Einführung
Entity-Component-Systeme sind eine objektorientierte Architekturtechnik.
Es besteht kein allgemeiner Konsens darüber, was der Begriff bedeutet, genau wie bei der objektorientierten Programmierung. Es ist jedoch klar, dass Entity-Component-Systeme speziell als architektonische Alternative zur Vererbung gedacht sind . Vererbungshierarchien sind ein natürlicher Ausdruck dafür, was ein Objekt ist . Bei bestimmten Arten von Software (z. B. Spielen) möchten Sie jedoch eher ausdrücken, was ein Objekt tut .
Es handelt sich um ein anderes Objektmodell als das „Klassen- und Vererbungsmodell“, an das Sie wahrscheinlich aus der Arbeit in C ++ oder Java gewöhnt sind. Entitäten sind genauso aussagekräftig wie Klassen, genau wie Prototypen wie in JavaScript oder Self - alle diese Systeme können in Bezug auf einander implementiert werden.
Beispiele
Angenommen, dies Playerist eine Entität mit Position, Velocityund KeyboardControlledKomponenten, die die offensichtlichen Dinge tun.
entity Player:
Position
Velocity
KeyboardControlled
Wir wissen, Positiondass davon Velocityund Velocityvon etwas betroffen sein muss KeyboardControlled. Die Frage ist, wie wir diese Effekte modellieren möchten.
Entitäten, Komponenten und Systeme
Angenommen, Komponenten haben keine Referenzen zueinander. ein externes PhysicsSystem durchläuft alle VelocityKomponenten und aktualisiert die Positionder entsprechenden Entität; Ein InputSystem durchläuft alle KeyboardControlledKomponenten und aktualisiert die Velocity.
Player
+--------------------+
| Position | \
| | Physics
/ | Velocity | /
Input | |
\ | KeyboardControlled |
+--------------------+
Dies erfüllt die Kriterien:
Keine Spiel- / Geschäftslogik wird von der Entität ausgedrückt.
Komponenten speichern Daten, die das Verhalten beschreiben.
Die Systeme sind jetzt für die Behandlung von Ereignissen und die Umsetzung des von den Komponenten beschriebenen Verhaltens verantwortlich. Sie sind auch für die Handhabung von Interaktionen zwischen Entitäten verantwortlich, z. B. für Kollisionen.
Einheiten und Komponenten
Allerdings wird angenommen , dass Komponenten zu tun haben Referenzen zueinander. Jetzt ist die Entität einfach ein Konstruktor, der einige Komponenten erstellt, sie zusammenfügt und ihre Lebensdauer verwaltet:
class Player:
construct():
this.p = Position()
this.v = Velocity(this.p)
this.c = KeyboardControlled(this.v)
Die Entität kann jetzt Eingabe- und Aktualisierungsereignisse direkt an ihre Komponenten senden. Velocitywürde auf Aktualisierungen und KeyboardControlledauf Eingaben reagieren. Dies erfüllt immer noch unsere Kriterien:
Die Entität ist ein "dummer" Container, der Ereignisse nur an Komponenten weiterleitet.
Jede Komponente führt ein eigenes Verhalten aus.
Hier werden Komponentenwechselwirkungen explizit und nicht von außen von einem System auferlegt. Die Daten, die ein Verhalten beschreiben (wie hoch ist die Geschwindigkeit?) Und der Code, der es ausführt (wie hoch ist die Geschwindigkeit?), Sind gekoppelt, jedoch auf natürliche Weise. Die Daten können als Parameter für das Verhalten angesehen werden. Und einige Komponenten wirken überhaupt nicht - a Positionist das Verhalten , an einem Ort zu sein .
Interaktionen können auf der Ebene der Entität ("wenn eine Playermit einer Enemy... kollidiert ") oder auf der Ebene einzelner Komponenten ("wenn eine Entität Lifemit einer Entität mit Strength... kollidiert ") behandelt werden.
Komponenten
Was ist der Grund für die Existenz des Unternehmens? Wenn es sich lediglich um einen Konstruktor handelt, können wir ihn durch eine Funktion ersetzen, die eine Reihe von Komponenten zurückgibt. Wenn wir später Entitäten nach ihrem Typ abfragen möchten, können wir auch eine TagKomponente haben, mit der wir genau das tun können:
function Player():
t = Tag("Player")
p = Position()
v = Velocity(p)
c = KeyboardControlled(v)
return {t, p, v, c}
Interaktionen müssen jetzt durch abstrakte Abfragen behandelt werden, wodurch Ereignisse vollständig von Entitätstypen entkoppelt werden. Es sind nicht mehr Entitätstypen abzufragen - beliebige TagDaten werden wahrscheinlich besser zum Debuggen verwendet als die Spielelogik.
Fazit
Entitäten sind keine Funktionen, Regeln, Akteure oder Datenflusskombinatoren. Sie sind Substantive, die konkrete Phänomene modellieren - mit anderen Worten, sie sind Objekte. Wikipedia sagt: Entity-Component-Systeme sind ein Software-Architekturmuster zur Modellierung allgemeiner Objekte.