Wie und warum haben wir unser ECS geschrieben?

In einem früheren Artikel habe ich die Technologien und Ansätze beschrieben, die wir bei der Entwicklung eines neuen mobilen, schnellen Shooters verwenden. Weil Es war eine Rezension und sogar ein oberflächlicher Artikel - heute werde ich tiefer gehen und detailliert erklären, warum wir beschlossen haben, unser eigenes ECS-Framework zu schreiben und die vorhandenen nicht verwendet haben. Am Ende gibt es Codebeispiele und einen kleinen Bonus.

Was ist ECS als Beispiel?

Ich habe bereits kurz beschrieben, was Entity Component System ist, und es gibt Artikel auf Habré über ECS (im Grunde genommen jedoch Übersetzungen von Artikeln - siehe meine Rezension der interessantesten davon am Ende des Artikels als Bonus). Und heute werde ich Ihnen anhand unseres Codebeispiels erklären, wie wir ECS verwenden.

Das obige Diagramm beschreibt die Essenz des Players , seine Komponenten und deren Daten sowie die Systeme, die mit dem Player und seinen Komponenten arbeiten. Das Hauptobjekt im Diagramm ist der Spieler:

• kann sich im Raum bewegen - Transformations- und Bewegungskomponenten , MoveSystem ;
• hat etwas Gesundheit und kann sterben - Komponente Gesundheit , Schaden , DamageSystem ;
• nach dem Tod erscheint am Respawn-Punkt - die Transformationskomponente für die Position, das RespawnSystem ;
• kann unverwundbar sein - Komponente unbesiegbar .

Wir beschreiben dies mit einem Code. Lassen Sie uns zunächst Schnittstellen für Komponenten und Systeme erhalten. Komponenten können gemeinsame Hilfsmethoden haben, das System hat nur eine Execute- Methode, die den Zustand der Welt am Eingang zur Verarbeitung empfängt:

public interface IComponent { // < > } public interface ISystem { void Execute(GameState gs); } 

Für Komponenten erstellen wir Stub-Klassen, die von unserem Codegenerator verwendet werden, um sie in tatsächlich verwendeten Komponentencode zu konvertieren. Lassen Sie uns ein paar Leerzeichen für Gesundheit , Schaden und Unbesiegbar bekommen (für den Rest der Komponenten wird es ähnlich sein).

 [Component] public class Health { [Max(1000)] //  -  1000 public int Hp; // -   public Health(int hp) {} } [Component] public class Damage { [DontSend] //      ,      public uint Amount; // -  public Entity Victim; //    public Entity Source; //    public Damage(uint amount, Entity victim, Entity source) {} } [Component] public class Invincible //   ,  ,    { } 

Komponenten bestimmen den Zustand der Welt, daher enthalten sie nur Daten ohne Methoden. Gleichzeitig enthält Invincible keine Daten. Sie werden in der Logik als Zeichen der Unverwundbarkeit verwendet. Wenn die Essenz des Spielers diese Komponente enthält, ist der Spieler jetzt unverwundbar.

Das Component- Attribut wird vom Generator verwendet, um die leeren Klassen für die Komponenten zu finden. Die Attribute Max und DontSend werden als Hinweise für die Serialisierung und Reduzierung der Größe des Status der Welt benötigt, der über das Netzwerk übertragen oder auf der Festplatte gespeichert wird. In diesem Fall serialisiert der Server das Feld Betrag nicht und sendet es über das Netzwerk (da Clients diesen Parameter nicht verwenden, wird er nur auf dem Server benötigt). Und das HP- Feld kann angesichts des maximalen Gesundheitswerts gut in mehrere Bits gepackt werden.

Wir haben auch eine vorgefertigte Entitätsklasse , in der wir Informationen zu allen möglichen Komponenten einer Entität hinzufügen, und der Generator erstellt bereits eine echte Klasse daraus:

 public class Entity { public Health Health; public Damage Damage; public Invincible Invincible; // ... < > } 

Danach erstellt unser Generator den Code der Komponentenklassen " Gesundheit" , " Schaden" und " Unbesiegbar" , der bereits in der Spielelogik verwendet wird:

 public sealed class Health : IComponent { public int Hp; public void Reset() { Hp = default(int); } // ... <  > } public sealed class Damage : IComponent { public int Amount; public Entity Victim; public Entity Source; public void Reset() { Amount = default(int); Victim = default(Entity); Source = default(Entity); } // ... <  > } public sealed class Invincible : IComponent { } 

Wie Sie sehen können, blieben die Daten in den Klassen und Methoden wurden hinzugefügt, z. B. Zurücksetzen . Es ist erforderlich, um Komponenten in Pools zu optimieren und wiederzuverwenden. Andere Hilfsmethoden enthalten keine Geschäftslogik - ich werde sie der Kürze halber nicht geben.

Es wird auch eine Klasse für den Zustand der Welt generiert, die eine Liste aller Komponenten und Entitäten enthält:

 public sealed class GameState { //  public Table<Movement> Movements; public Table<Health> Healths; public Table<Damage> Damages; public Table<Transform> Transforms; public Table<Invincible> Invincibles; //   public Entity CreateEntity() { /* <> */ } public void Copy(GameState gs2) { /* <> */ } public Entity this[uint id] { /* <> */ } // ... <   > } 

Und schließlich der generierte Code für Entity :

 public sealed class Entity { public uint Id; //   public GameState GameState; //     //     : public Health Health { get { return GameState.Healths[Id]; } } public Damage Damage { get { return GameState.Damages[Id]; } } public Invincible Invincible { get { return GameState.Invincibles[Id]; } } // …     public Damage AddDamage() { return GameState.Damages.Insert(Id); } public Damage AddDamage(int total, Entity victim, Entity source) { var c = GameState.Damages.Insert(Id); c.Amount = total; c.Victim = victim; c.Source = source; return c; } public void DelDamage() { GameState.Damages.Delete(Id); } // … <     > } 

Die Entitätsklasse ist im Wesentlichen nur eine Komponentenkennung. Der Verweis auf die Objekte der GameState- Welt wird nur in Hilfsmethoden verwendet, um das Schreiben von Geschäftslogikcode zu vereinfachen. Wenn wir die Kennung einer Komponente kennen, können wir damit Beziehungen zwischen Entitäten serialisieren und Verknüpfungen in Komponenten zu anderen Entitäten implementieren. Beispielsweise enthält die Schadenskomponente einen Verweis auf die Opfereinheit , um festzustellen, wer beschädigt wurde.

Dies beendet den generierten Code. Im Allgemeinen benötigen wir einen Generator, um nicht jedes Mal Hilfsmethoden zu schreiben. Wir beschreiben die Komponenten nur als Daten, dann erledigt der Generator die ganze Arbeit. Beispiele für Hilfsmethoden:

• Entitäten erstellen / löschen;
• Hinzufügen / Entfernen / Kopieren einer Komponente, Zugriff darauf, falls vorhanden;
• vergleiche zwei Staaten der Welt;
• den Zustand der Welt serialisieren;
• Delta-Komprimierung;
• Code einer Webseite oder eines Unity-Fensters zur Anzeige des Zustands der Welt, der Entitäten, der Komponenten (siehe Details unten);
• usw.

Fahren wir mit dem Systemcode fort. Sie definieren Geschäftslogik. Schreiben wir zum Beispiel den Code eines Systems, das den Schaden eines Spielers berechnet:

 public sealed class DamageSystem : ISystem { void ISystem.Execute(GameState gs) { foreach (var damage in gs.Damages) { var invincible = damage.Victim.Invincible; if (invincible != null) continue; var health = damage.Victim.Health; if (health == null) continue; health.Hp -= damage.Amount; } } } 

Das System durchläuft alle Schadenskomponenten der Welt und prüft, ob ein potenziell beschädigter Spieler ( Opfer ) eine unbesiegbare Komponente enthält. Wenn dies der Fall ist, ist der Spieler unverwundbar und es entsteht kein Schaden. Als nächstes erhalten wir die Gesundheitskomponente des Opfers und reduzieren die Gesundheit des Spielers um die Größe des Schadens.

Betrachten Sie die Hauptmerkmale der Systeme:

1. Ein System ist normalerweise eine zustandslose Klasse, enthält keine internen Daten und versucht nicht, sie irgendwo zu speichern, außer für Daten über die Welt, die von außen übertragen werden.
2. Systeme durchlaufen normalerweise alle Komponenten eines bestimmten Typs und arbeiten mit ihnen. Sie werden normalerweise nach der Art der Komponente ( Damage → DamageSystem ) oder nach der von ihnen ausgeführten Aktion ( RespawnSystem ) aufgerufen .
3. Das System implementiert minimale Funktionalität. Wenn wir beispielsweise weiter gehen, nachdem das DamageSystem ausgeführt wurde, entfernt ein anderes RemoveDamageSystem alle Damage- Komponenten. Im nächsten Tick kann ein anderes ApplyDamageSystem, das auf dem Schießen des Spielers basiert, die Schadenskomponente erneut mit neuem Schaden aufhängen. Und dann überprüft das PlayerDeathSystem den Zustand des Spielers ( Health.Hp ) und zerstört, wenn er kleiner oder gleich 0 ist, alle Komponenten des Spielers mit Ausnahme von Transform und fügt die Komponente Dead Flag hinzu.

Insgesamt erhalten wir die folgenden Klassen und die Beziehungen zwischen ihnen:

Einige Fakten zu ECS

ECS hat seine Vor- und Nachteile als Entwicklungsansatz und als Repräsentationsmethode für die Welt des Spiels. Jeder entscheidet selbst, ob er es nutzt oder nicht. Beginnen wir mit den Profis:

• Zusammensetzung versus Mehrfachvererbung. Bei Mehrfachvererbung kann eine Reihe unnötiger Funktionen vererbt werden. Im Fall von ECS wird die Funktionalität angezeigt / ausgeblendet, wenn eine Komponente hinzugefügt / entfernt wird.
• Trennung von Logik und Daten. Die Fähigkeit, die Logik zu ändern (Systeme ändern, Komponenten entfernen / hinzufügen), ohne Daten zu beschädigen. Das heißt, Sie können die Gruppe von Systemen, die für eine bestimmte Funktionalität verantwortlich sind, jederzeit deaktivieren. Alles andere funktioniert weiterhin und dies hat keine Auswirkungen auf die Daten.
• Der Spielzyklus wird vereinfacht. Ein Update wird angezeigt und der gesamte Zyklus ist in Systeme unterteilt. Daten werden unabhängig von der Engine vom "Flow" im System verarbeitet (es gibt keine Millionen von Update- Aufrufen wie in Unity).
• Eine Entität weiß nicht, welche Klassen sie betreffen (und sollte es nicht wissen).
• Effiziente Speichernutzung . Dies hängt von der Implementierung von ECS ab. Sie können erstellte Entitätsobjekte und -komponenten mithilfe von Pools wiederverwenden. Sie können Werttypen für Daten verwenden und diese nebeneinander im Speicher speichern ( Datenlokalität ).
• Es ist einfacher zu testen, wann Daten von der Logik getrennt sind. Besonders wenn man bedenkt, dass Logik ein kleines System mit mehreren Codezeilen ist.
• Zeigen Sie den Zustand der Welt in Echtzeit an und bearbeiten Sie ihn . Weil Der Zustand der Welt besteht nur aus Daten. Wir haben ein Tool geschrieben, das auf der Webseite den gesamten Zustand der Welt in einem Match auf dem Server (sowie die Matchszene in 3D) anzeigt. Jede Komponente einer Entität kann angezeigt, geändert oder gelöscht werden. Dasselbe kann im Unity-Editor für den Client ausgeführt werden.

Und jetzt die Nachteile:

• Sie müssen lernen, Code anders zu denken, zu entwerfen und zu schreiben . Denken Sie in Entitäten, Komponenten und Systemen. Viele Entwurfsmuster in ECS werden auf völlig andere Weise implementiert (siehe ein Beispiel für die Implementierung des Zustandsmusters in einem der Übersichtsartikel am Ende).
• Mehr Code . Umstritten. Einerseits gibt es aufgrund der Tatsache, dass wir die Logik in kleine Systeme aufteilen, anstatt alle Funktionen in einer Klasse zu beschreiben, mehr Klassen, aber nicht viel mehr Code.
• Die Reihenfolge der aufrufenden Systeme beeinflusst den Betrieb des gesamten Spiels . Normalerweise sind die Systeme voneinander abhängig, die Reihenfolge ihrer Ausführung wird durch die Liste festgelegt und sie werden in dieser Reihenfolge ausgeführt. Beispielsweise berücksichtigt DamageSystem zuerst den Schaden, dann entfernt RemoveDamageSystem die Damage- Komponente. Wenn Sie versehentlich die Reihenfolge ändern, funktioniert alles anders. Im Allgemeinen gilt dies auch für den üblichen OOP-Fall, wenn Sie die Reihenfolge der Methodenaufrufe ändern. In ECS ist es jedoch einfacher, einen Fehler zu machen. Wenn beispielsweise ein Teil der Logik zur Vorhersage auf dem Client ausgeführt wird, sollte die Reihenfolge dieselbe sein wie auf dem Server.
• Wir müssen die Daten und Ereignisse der Logik irgendwie mit der Ansicht verbinden . Im Fall von Unity haben wir MVP:
  
  - Modell - GameState von ECS;
  - Anzeigen - bei uns sind dies ausschließlich Standardklassen für MonoBehavior Unity ( Renderer , Text usw.) und Fertighäuser.
  - Presenter verwendet den GameState , um die Ereignisse des Auftretens / Verschwindens von Entitäten, Komponenten usw. zu bestimmen, erstellt Unity-Objekte aus Fertighäusern und ändert sie entsprechend den Änderungen im Zustand der Welt.

Wussten Sie, dass:

• Bei ECS geht es nicht nur um Datenlokalität . Für mich ist dies eher ein Programmierparadigma, ein Muster, eine andere Art, die Spielwelt zu gestalten - nennen Sie es wie Sie wollen. Die Datenlokalität ist nur eine Optimierung.
• Einheit hat kein ECS! Oft fragen Sie Kandidaten bei einem Teaminterview - was wissen Sie über ECS? Wenn du nichts gehört hast, sagst du es ihnen und sie antworteten: "Ah, so ist es wie in Unity, dann weiß ich es!" Aber nein, es ist nicht wie in der Unity-Engine. Dort werden Daten und Logik in der MonoBehaviour- Komponente kombiniert, und GameObject (im Vergleich zu einer Entität in ECS) verfügt über zusätzliche Daten - einen Namen, einen Platz in der Hierarchie usw. Unity-Entwickler arbeiten derzeit an einer normalen Implementierung von ECS in der Engine, und bisher scheint es gut zu sein. Sie haben Spezialisten auf diesem Gebiet eingestellt - ich hoffe, es wird cool.

Unsere Auswahlkriterien für das ECS-Framework

Als wir beschlossen, ein Spiel auf ECS zu entwickeln, suchten wir nach einer vorgefertigten Lösung und schrieben die Anforderungen dafür auf der Grundlage der Erfahrung eines der Entwickler auf. Und sie haben gemalt, wie vorhandene Lösungen unseren Anforderungen entsprechen. Es war vor einem Jahr, im Moment hätte sich etwas ändern können. Als Lösungen haben wir betrachtet:

• Entitas
• Artemis C #
• Ash.net
• ECS ist zu dem Zeitpunkt, als wir es konzipiert haben, unsere eigene Lösung. Das heißt, unsere Annahmen und Wünsche, was wir selbst tun können.

Wir haben zum Vergleich eine Tabelle zusammengestellt, in der ich auch unsere aktuelle Lösung (als ECS (jetzt) ​​bezeichnet ) aufgenommen habe:


Rote Farbe - die Lösung unterstützt unsere Anforderungen nicht, orange - teilweise unterstützt, grün - vollständig unterstützt.

Für uns war die Analogie der Operationen für den Zugriff auf Komponenten und die Suche nach Entitäten in ECS Operationen in einer SQL-Datenbank. Daher haben wir Konzepte wie Tabelle (Tabelle), Join (Join-Operation), Indizes (Indizes) usw. verwendet.

Wir werden unsere Anforderungen beschreiben und inwieweit Bibliotheken und Frameworks von Drittanbietern diesen entsprachen:

• Separate Datensätze (Verlauf, aktuell, visuell, statisch) - Die Möglichkeit, Weltzustände separat abzurufen und zu speichern (z. B. den aktuellen Status für die Verarbeitung, das Rendern, den Statusverlauf usw.). Alle berücksichtigten Entscheidungen unterstützten diese Anforderung .
• Entitäts-ID als Ganzzahl - Unterstützung für die Darstellung einer Entität durch ihre Identifikationsnummer. Es ist notwendig für die Übertragung über das Netzwerk und die Fähigkeit, Entitäten in der Geschichte der Staaten zu verbinden. Keine der als unterstützt betrachteten Lösungen. In Entitas wird eine Entität beispielsweise durch ein vollwertiges Objekt dargestellt (wie ein GameObject in Unity).
• Join durch ID O (N + M) - Unterstützung für eine relativ schnelle Abtastung von zwei Arten von Komponenten. Zum Beispiel, wenn Sie alle Entitäten mit Komponenten des Schadenstyps (z. B. deren N-Teile) und Gesundheit (M-Teile) zum Berechnen und Verursachen von Schaden erhalten müssen. Es gab volle Unterstützung in Artemis; In Entitas und Ash.NET ist es schneller als O (N²), aber langsamer als O (N + M). Ich kann mich jetzt nicht an die Einschätzung erinnern.
• Join durch ID-Referenz O (N + M) - das gleiche wie oben, nur wenn eine Komponente einer Entität eine Verknüpfung zu einer anderen hat und diese eine andere Komponente erhalten muss (in unserem Beispiel bezieht sich die Schadenskomponente der Hilfsentität auf die Spielerentität Opfer und von dort müssen Sie die Gesundheitskomponente erhalten ). Wird von keiner der betrachteten Lösungen unterstützt.
• Keine Abfragezuweisung - Keine zusätzlichen Speicherzuweisungen beim Abfragen von Komponenten und Entitäten aus dem Zustand der Welt. In Entitas war es in bestimmten Fällen, aber für uns unbedeutend.
• Pooltabellen - Speicherung von Weltdaten in Pools, Möglichkeit zur Wiederverwendung von Speicher, Zuordnung nur, wenn der Pool leer ist. Es gab "einige" Unterstützung in Entitas und Artemis, eine völlige Abwesenheit in Ash.NET.
• Vergleich nach ID (add, del) - Integrierte Unterstützung für Ereignisse beim Erstellen / Zerstören von Entitäten und Komponenten nach ID. Die Anzeigeebene (Ansicht) muss Objekte ein- / ausblenden, Animationen und Effekte abspielen. Wird von keiner der betrachteten Lösungen unterstützt.
• Δ-Serialisierung (Quantisierung, Überspringen) - integrierte Delta-Komprimierung zur Serialisierung des Weltzustands (z. B. um die Größe der über das Netzwerk gesendeten Daten zu verringern). Out of the Box wurde in keiner der Lösungen unterstützt.
• Interpolation ist ein eingebauter Interpolationsmechanismus zwischen Weltstaaten. Keine der unterstützten Lösungen.
• Komponententyp wiederverwenden - Die Möglichkeit, einmal geschriebenen Komponententyp in verschiedenen Entitätstypen zu verwenden. Nur unterstützte Entitas .
• explizite Reihenfolge der Systeme - die Möglichkeit, eigene Anrufreihenfolgesysteme festzulegen. Alle Entscheidungen unterstützt.
• Editor (Einheit / Server) - Unterstützung für das Anzeigen und Bearbeiten von Entitäten in Echtzeit, sowohl für den Client als auch für den Server. Entitas unterstützte nur die Möglichkeit, Entitäten und Komponenten im Unity-Editor anzuzeigen und zu bearbeiten.
• schnelles Kopieren / Ersetzen - die Möglichkeit, Daten kostengünstig zu kopieren / ersetzen. Keine der unterstützten Lösungen.
• Komponente als Werttyp (Struktur) - Komponenten als Werttypen. Grundsätzlich wollte ich darauf basierend eine gute Leistung erzielen. Es wurde kein einziges System unterstützt, Komponentenklassen waren überall.

Optionale Anforderungen ( keine der Lösungen unterstützte sie zu diesem Zeitpunkt ):

• Indizes - Indizierung von Daten wie in einer Datenbank.
• zusammengesetzte Schlüssel - komplexe Schlüssel für den schnellen Zugriff auf Daten (wie in der Datenbank).
• Integritätsprüfung - die Fähigkeit, die Integrität von Daten in einem Zustand der Welt zu überprüfen. Nützlich zum Debuggen.
• Die inhaltsbewusste Komprimierung ist die beste Datenkomprimierung, die auf dem Wissen über die Art der Daten basiert. Zum Beispiel, wenn wir die maximale Größe der Karte oder die maximale Anzahl von Objekten auf der Welt kennen.
• Typen- / Systembegrenzung - Beschränkung der Anzahl der Arten von Komponenten oder Systemen. In Artemis war es zu dieser Zeit unmöglich, mehr als 32 oder 64 Arten von Komponenten und Systemen zu erstellen .

Wie aus der Tabelle hervorgeht, wollten wir alle Anforderungen außer den optionalen selbst implementieren. In der Tat haben wir im Moment nicht getan:

• Join durch ID O (N + M) und Join durch ID-Referenz O (N + M) - Die Auswahl für zwei verschiedene Komponenten belegt immer noch O (N²) (tatsächlich eine verschachtelte for- Schleife). Andererseits gibt es nicht so viele Entitäten und Komponenten für eine Übereinstimmung.
• Vergleich nach ID (add, del) - wird auf Framework-Ebene nicht benötigt. Wir haben dies auf einer höheren Ebene in MVP implementiert.
• schnelles Kopieren / Ersetzen und Komponente als Werttyp (Struktur) - irgendwann wurde uns klar, dass das Arbeiten mit Strukturen nicht so bequem ist wie mit Klassen und wir entschieden uns für Klassen - wir bevorzugten Entwicklungskomfort anstelle einer besseren Leistung. Übrigens haben die Entitas-Entwickler am Ende dasselbe getan .

Gleichzeitig haben wir dennoch eine der Anforderungen realisiert, die unserer Meinung nach zunächst optional waren:

• inhaltsbewusste Komprimierung - aufgrund dessen konnten wir die Größe des über das Netzwerk übertragenen Pakets erheblich (zehnmal) reduzieren. Für mobile Datennetze ist es sehr wichtig, die Paketgröße in die MTU einzupassen, damit sie nicht in kleine Teile zerlegt wird, die verloren gehen können, in einer anderen Reihenfolge ablaufen und dann in Teile zusammengesetzt werden müssen. Wenn in Photon beispielsweise die Datengröße nicht in die MTU-Bibliothek passt, werden die Daten in Pakete aufgeteilt und als zuverlässig (mit garantierter Zustellung) gesendet, selbst wenn Sie sie von oben als "unzuverlässig" senden. Mit Schmerzen aus erster Hand getestet.

Merkmale unserer Entwicklung bei ECS

• Wir bei ECS schreiben ausschließlich Geschäftslogik . Keine Arbeit mit Ressourcen, Ansichten usw. Da der ECS-Logikcode gleichzeitig auf dem Client in Unity und auf dem Server ausgeführt wird, sollte er so unabhängig wie möglich von anderen Ebenen und Modulen sein.
• Wir versuchen Komponenten und Systeme zu minimieren . Normalerweise starten wir für jede neue Aufgabe neue Komponenten und Systeme. Manchmal kommt es jedoch vor, dass wir die alten ändern, den Komponenten neue Daten hinzufügen und die Systeme „aufblasen“.
• In unserer ECS-Implementierung können Sie einer Entität nicht mehrere Komponenten desselben Typs hinzufügen . Wenn ein Spieler in einem Tick mehrmals getroffen wurde (z. B. mehrere Gegner), erstellen wir normalerweise für jeden Schaden eine neue Entität und fügen ihr eine Schadenskomponente hinzu .
• Manchmal reicht die Präsentation nicht aus, um Informationen im GameState zu erhalten . Dann müssen Sie spezielle Komponenten oder zusätzliche Daten hinzufügen, die nicht an der Logik beteiligt sind, die die Ansicht jedoch benötigt. Zum Beispiel ist die Aufnahme sofort auf dem Server, ein Tick lebt und visuell ist sie auf dem Client länger. Daher wird für den Client der Schuss zum Parameter "Schusslebensdauer" hinzugefügt.
• Wir implementieren Ereignisse / Anforderungen, indem wir spezielle Komponenten erstellen . Wenn beispielsweise ein Spieler gestorben ist, hängen wir ihm eine Komponente ohne tote Daten auf. Dies ist ein Ereignis für andere Systeme und die Ansichtsebene, in der der Spieler gestorben ist. Oder wenn wir den Spieler auf den Punkt bringen müssen, erstellen wir mit der Respawn- Komponente eine separate Entität mit zusätzlichen Informationen darüber, wen wir wiederbeleben sollen. Ein separates RespawnSystem zu Beginn des Spielzyklus durchläuft diese Komponenten und schafft bereits die Essenz des Spielers. Das heißt, Tatsächlich ist die erste Entität eine Anforderung zum Erstellen der zweiten.
• Wir haben spezielle "Singleton" -Komponenten / -Entitäten . Zum Beispiel haben wir eine Entität mit ID = 1, an der spezielle Komponenten hängen - die Spieleinstellungen.

Bonus

— ECS — . , , , :

• Unity, ECS -- — ECS . mopsicus , ECS, . : Unity ECS , . . «» ECS Unity. ECS-, : LeoECS , BrokenBricksECS , Svelto.ECS .
• Unity3D ECS Job System — , ECS Unity. fstleo , Unity ECS, , - , JobSystem.
• Entity System Framework ? — Ash- ActionScript. , , OOP- ECS-.
• Ash Entity System — , FSM State ECS — , .
• Entity-Component-System — — ECS C++.