Wo werden Entity Death-Ereignisse in ein Komponenten- / Systemdesign eingefügt?

Entitäten in meinem Spiel sind nichts anderes als eine Sammlung von Komponenten, die mit einer Entitäts-ID verknüpft sind. Ich habe (fast) reine Datenkomponenten und Systeme, die mit den Daten arbeiten.

Eine dieser Komponenten ist HitPoints. Es ist eine der wenigen Komponenten, die ein bisschen mehr als nur Daten enthält: Es enthält ein DyingEreignis, HitPointsSystemdas ausgelöst wird, wenn die Trefferpunkte unter 0 fallen. Einer der Ereignis-Listener ist meine Benutzeroberfläche, während eine Entität ausgewählt ist, hört sie zu zum DyingEreignis der aktuellen Auswahl . Bei Tod wird die Entität abgewählt. Wenn Objekte ausgewählt werden, werden kleine Kreise um die Auswahl gezogen. Es funktioniert großartig ... Bis ich eine Entität habe, ohne HitPointsdie das noch sterben kann.

Ich habe ein Missilein meinem Spiel, das es nicht hat HitPoints, aber es kann ausgewählt werden und es kann sterben. Wenn a Missileausgewählt ist, erkennt meine Benutzeroberfläche, dass es kein Ereignis HitPointshat und daher auch kein DyingEreignis, was später dazu führt, dass die Zeichenschleife versucht, eine "ausgewählte" und tote Rakete zu zeichnen , was zu einem Absturz führt.

Man könnte vermuten , dass Sie nur noch hinzufügen könnten , HitPointsum das Missileund alles wäre in Ordnung, aber meine KI - System sieht für feindlichen Targeting , HitPointsweil diejenigen , die einzigen Dinge sind es beschädigen kann. Ich möchte nicht, dass Raketen abgefeuert werden, und ich möchte auch keine Sonderregel hinzufügen.

Also ... wenn alle Entitäten sterben (oder gelöscht werden können), wo platziere ich das DyingEreignis? Soll ich eine neue Komponente erstellen? Entweder eine Komponente für alle Dinge, die sterben können (fast alles), oder eine Komponente für KI-Ziele? Oder gibt es einen besseren Ort für eine Veranstaltung wie diese?

Ich habe seit unserem Gespräch letzte Nacht ein wenig nachgelesen, weil ich mit dieser speziellen Spielarchitektur absolut unerfahren war (bin). Ein Artikel, den ich las, war Mick Wests herausragender Vortrag / Fallstudie über die Verwendung eines Nur-Komponenten-Systems. Darin beschreibt er einen Versuch, eine schlecht geschriebene Klassenhierarchie loszuwerden und stattdessen einen Entitätsmanager zu verwenden.

Eine Sache, die mir aufgefallen ist: Mick hat Klassen angeklagt ... aber er hat nicht wirklich gute Beweise vorgelegt. Er sagte, dass ihr Team mit schlechtem Code angefangen, guten Code geschrieben und ihre Probleme gelöst habe. Das hätte genauso gut sein können: "Wir hatten ein schreckliches Entity-Management-System und haben es durch eine gute Klassenhierarchie ersetzt, und die Dinge haben sich verbessert." Mein Punkt ist, dass schlechter Code schlecht ist, guter Code gut ist und jede Architektur jede Rolle einnehmen kann.

Ich denke, das Problem mit Ihrem System ist, dass es nicht die Ziele erreicht, die Mick brauchte: Kapselung, keine enge Kopplung, einfache Komponenten, die frei hinzugefügt werden können.

Wenn Sie sich darauf verlassen Hitpoints, zu viel zu tun, stoßen Sie auf Probleme. Sie bilden den Kern des Ziels Ihrer KI. Abhängig von ihrem Wert lösen sie ein Ereignis aus. Dieses Ereignis wirkt sich auf Ihre Benutzeroberfläche aus. Ihre Benutzeroberfläche wirkt sich auf Ihr Rendering aus, das Hitpointserneut prüft , wie gezeichnet wird. Du hast Spaghetti.

Was passiert ist, dass Sie trotz der Verwendung eines Nur-Komponenten-Systems immer noch spröde, voneinander abhängige Systeme haben. Sie haben keine Kapselung. Sie können Objekten keine neuen Funktionen hinzufügen, ohne die Managersysteme zu beschädigen. Sie müssen Entitäten (nur ID-Wert) redundanten Code hinzufügen, damit nicht verwandte Funktionen funktionieren. Welches ist laut Mick das ursprüngliche Problem, das Sie vermeiden wollten:

Die Objekte waren in der Regel schwergewichtig. Objekte hatten unnötige Daten und Funktionen. Manchmal verlangsamte die unnötige Funktionalität das Spiel. Die Funktionalität wurde manchmal in verschiedenen Zweigen des Baumes dupliziert.

Ich mag Ihre TargetableKomponente, ich denke, das ist ein Schritt in die richtige Richtung. Aber Sie wahrscheinlich auch brauchen Selectable, Dying, Render... alles als wahr einzweckmaschinen Komponente. Es wird schwierig sein, diese Strenge beizubehalten, wenn diese Systeme miteinander sprechen müssen (und ein realer Kompromiss unvermeidlich ist, sagt Mick), aber die Alternative besteht darin, alles zu verlieren, was Ihr Entitätssystem Ihnen versprochen hat.

Als vorübergehende Maßnahme habe ich eine TargetableKomponente erstellt, die ich allen Zielobjekten hinzugefügt HitPointsund dann der Rakete hinzugefügt habe. Meine KI zielt jetzt nur auf TargetableEntitäten ab, und meine Benutzeroberfläche kann die Todesereignisse für mich abhören Missile. Das fühlt sich wie ein halbes Maß an. Die nächste Entität, die kommt und ausgewählt und gelöscht werden kann, muss ebenfalls vorhanden sein HitPoints, was falsch sein kann.

Vielleicht brauche ich langfristig eine Entitätsklasse, die dies speichern kann? Oder vielleicht sollte jede Komponente ein Todesereignis haben.