[Thesis] Sind Tiles Entitäten

[AMatutat]

Die DoorTiles sollen um eine open() und close() Methode erweitert werde. Wenn eine Tür offen ist, kann man durchgehen und wenn sie zu ist dann nicht.

Entsprechend mit Texturen

Time:4

[AHeinisch]

Müssen Türen nicht jetzt eigentlich auch als Entity gebaut werden ? wäre dies nicht ggfls. stimig mit dem ECS?

[AMatutat]

Klingt beim erste lesen riichtig, stellt sich die Frage: Wenn DoorTile eine Entity ist, ist dann jedes Tile eine Entity?

Oder anders: Man kann bestimmt argumentieren und begründen warum ein Tile eine Entity sein sollte. Die Frage ist: Bringt uns das was? Ich sehe nämlich ganz viele böse Schlüsse die sich daraus ziehen würden. Tiles mit Inventaren undso....

[AHeinisch]

Klingt beim erste lesen riichtig, stellt sich die Frage: Wenn DoorTile eine Entity ist, ist dann jedes Tile eine Entity?

Na ja ist, die Frage wird das TürFeld zur Entität ja dann müssen alle Felder zu Entitäten geändert werden.

Wird nur die Tür an sich, die auf einem Boden steht, eine Entität dann haben wir keinen Zwang, das Level komplett auf Entitäten abzuwandeln. Und ja ein Tile mit Inventar klingt blöd, aber eine Truhe mit einem SkillComponent klingt auch blöd, da wir keine Mimik vorgesehen haben.

Wir haben jetzt beim Item darüber diskutiert, ob ein Item nicht immer eine Entität sein sollte, dabei ist eine Tür etwas was durchgehend im Dungeon existiert. Etwas, was aktiv interagiert wird der spieler ggfls. mit interagiert etc.

Ob alle Tiles eine Entität werden sollen nein das würde ich ablehnen aber die Tür da wäre ich dafür diese nicht als Tile zu sehen oder es so sehen auf der Türtile steht die eigentliche Tür

[cagix]

Türen sind für mich eigentlich zunächst Elemente wie Wände oder Fußboden. Das spräche gegen Entität.

Andererseits: Im Gegensatz zu Wänden und Fußboden könnten Türen ein Eigenleben haben: Man kann sie öffnen, man kann sie schließen, man kann sie wegsprengen. Das würde für mich nahelegen, dass das eher Entitäten sind und über Systeme gehandhabt werden sollten?

Aber tatsächlich: Ist dann noch die Sonderbehandlung von Wänden und Fußboden gerechtfertigt? Die Frage ist, was das konkret bedeuten würde. Vielleicht würde einiges einfacher, beispielsweise könnte die Betretbarkeit über das Hitbox-System mit erledigt werden? Aber vielleicht würde auch vieles laufzeittechnisch komplexer, weil alle Systeme ja immer wieder über alle Entitäten iterieren müssen und entsprechend hier über die vielen Felder dann mit.

@AHeinisch Klassen von Entitäten sind im ECS nicht vorgesehen, oder? Also dass nicht alle Entitäten gleichberechtigt in einer großen Liste in Game rumgammeln, sondern dass Game verschiedene Entitäten-Listen pflegt ("Wände", "Monster", "Items", ...)?

[cagix]

Wir haben jetzt beim Item darüber diskutiert, ob ein Item nicht immer eine Entität sein sollte, dabei ist eine Tür etwas was durchgehend im Dungeon existiert. Etwas, was aktiv interagiert wird der spieler ggfls. mit interagiert etc.

Das würde sehr dafür sprechen, dass Türen eben (ortsfeste) Entitäten sind.

Ob alle Tiles eine Entität werden sollen nein das würde ich ablehnen aber die Tür da wäre ich dafür diese nicht als Tile zu sehen oder es so sehen auf der Türtile steht die eigentliche Tür

Weiss nicht. Ein Tile ist eine ortsfeste Entität mit bestimmten Eigenschaften. Als Spieler kann ich damit ja interagieren: Ich kann draufgehen, ich kann die Eigenschaften untersuchen, die Dinger werden "animiert", ...

[AHeinisch]

Aber tatsächlich: Ist dann noch die Sonderbehandlung von Wänden und Fußboden gerechtfertigt? Die Frage ist, was das konkret bedeuten würde. Vielleicht würde einiges einfacher, beispielsweise könnte die Betretbarkeit über das Hitbox-System mit erledigt werden? Aber vielleicht würde auch vieles laufzeittechnisch komplexer, weil alle Systeme ja immer wieder über alle Entitäten iterieren müssen und entsprechend hier über die vielen Felder dann mit.

Ja, das ist ein Problem, welches existiert. Also es gibt verschiedene Ansätze, die mir bekannt sind und wenn gewollt, kann ich da nochmal weiter schauen.

• Level ist eine Entität
  • Level hat das Layout und wird durch ein Mesh, dargestellt welches die Tiles "gruppiert" und die Texturen dann auf dem Mesh verwaltet werden
• Entitäten müssen nur von bestimmten Systemen kontrolliert werden, wenn sie "verändert" wurden.
• Das ECS optimiert für die Systeme die Liste durch z.b. Listen mit "referenzIDs" bei uns einen zusätzlichen Zugriff auf die Entität
  • Die Listen müssen immer upgedatet werden, wenn die Hauptliste sich ändert bzw. wenn eine Komponente neu hinzugefügt wird
  • Das ECS übergibt dem jeweiligen System eine Entität anhand einer Komponente
  • Das System sorgt für eine O^n Loop über die Entitäten und nicht jedes System loopt selbst über die Entitäten #386 ist ja bereits das Abgeben der ersten primären Iteration
• Hierarchie zwischen Entitäten entweder mit Vererbung von Komponenten Werten oder eben nicht (als Beispiel um nicht immer Unity zu nennen https://developer.valvesoftware.com/wiki/Entity_Hierarchy_(parenting))
  • Level Entität hat alle Tiles als Kinder
  • Level enthält auch alle Entitäten, die existieren ggfls. Durch eine Ebene

Weiss nicht. Ein Tile ist eine ortsfeste Entität mit bestimmten Eigenschaften. Als Spieler kann ich damit ja interagieren: Ich kann draufgehen, ich kann die Eigenschaften untersuchen, die Dinger werden "animiert", ...

offtopic zum Türthema: Also vielleicht lohnt es sich das Level an sich, als Entität umzuwandeln, welche eine LevelComponent hat welche dann das Level Mesh/Level Layout rendert. Alle Tiles bis auf das Türtile haben nur eine Animation und ein, ob sie betretbar sind. Welches nicht wirklich dafür spricht, dass sie eigene Entitäten benötigen. Außerdem kann, solange sie noch als ein Level gesehen werden, eine Optimierung in der Anzahl gemacht werden, wie z.b. alle Wände so zusammenfassen, dass sie so wenige "einzelne Tiles" haben wie möglich.

Edit: Beispiel, wie eine Optimierung passieren könnte: https://www.factorio.com/blog/post/fff-176

[cagix]

• Level ist eine Entität
  • Level hat das Layout und wird durch ein Mesh, dargestellt welches die Tiles "gruppiert" und die Texturen dann auf dem Mesh verwaltet werden

offtopic zum Türthema: Also vielleicht lohnt es sich das Level an sich, als Entität umzuwandeln, welche eine LevelComponent hat welche dann das Level Mesh/Level Layout rendert. Alle Tiles bis auf das Türtile haben nur eine Animation und ein, ob sie betretbar sind. Welches nicht wirklich dafür spricht, dass sie eigene Entitäten benötigen. Außerdem kann, solange sie noch als ein Level gesehen werden, eine Optimierung in der Anzahl gemacht werden, wie z.b. alle Wände so zusammenfassen, dass sie so wenige "einzelne Tiles" haben wie möglich

Spannend. Das ist vermutlich sehr "schlank" umzusetzen für uns, also ohne riesige Umbauten?

• Entitäten müssen nur von bestimmten Systemen kontrolliert werden, wenn sie "verändert" wurden.
• Das ECS optimiert für die Systeme die Liste durch z.b. Listen mit "referenzIDs" bei uns einen zusätzlichen Zugriff auf die Entität
  • Die Listen müssen immer upgedatet werden, wenn die Hauptliste sich ändert bzw. wenn eine Komponente neu hinzugefügt wird

Das wäre ja meine Idee von oben, dass das Game verschiedene Listen mit unterschiedlichen Entitäts-"Klassen" führt. Dadurch müssen die "normalen" Systeme nicht immer durch alle Tiles und Türen und so iterieren (also kein Laufzeitimpact) und wir hätten trotzdem eine ECS-konforme Umsetzung. Natürlich müsste Game dann gut aufpassen bei Updates der Listen, so "hemdsärmeliges" Herausgeben der Listen und Modifizieren der Listen außerhalb von Games geht dann nicht mehr (geht eigentlich auch so nicht, aber gut - wobei, das hatten wir ja eigentlich mal behoben, zumindest kann ich mich an eine längere Diskussion erinnern).

[AHeinisch]

Also hier einmal zusammengefasst, was für was spricht.

Was ist das Level?

• Ein unter den Entitäten sich nicht änderndes Spielfeld
  • Spielfeld ist dargestellt durch bestimmte, Tiles welche sich im Normalfall nicht ändern
• Die Tiles bilden einen Graphen, welcher für das Pathfinding benutzt wird

Können alle Tiles zu Entitäten gemacht werden und was kann dabei passieren?

• pro
  • alles, was im eigentlichen Spiel passiert liegt, auch im ECS (mehr an dem Gedanken des ECS ausgerichtet)
  • ein Zugriff auf die einzelnen Tiles findet über das ECS statt und nicht mehr über ein ECS fremdes Objekt
  • Der Zustand des Door tiles kann besser abgebildet werden(Siehe sind alle Tiles aktuell wirklich Tiles)
  • theoretisch kann besser kontrolliert werden ob eine kollision zwischen Tile und anderer Entität stattfindet
• contra
  • ECS wird massiv gefluttet mit neuen Entitäten (Auch mit #517 )
  • benötigt eine Reihenfolge der Entitäten (Da sonst vielleicht die Tiles nach dem Helden gezeichnet werden)
  • Level kann nicht durch meshing optimiert werden (zusammen legen von benachbarten Tiles zu einem)
  • Der Spritebatch kann nicht über den gesamten Level draw offen bleiben und muss jedes Mal neu aufgemacht werden (Performance Problem)

sind alle Tiles aktuell wirklich Tiles?

Aktuell haben wir Tiles welche wirklich nur kacheln für den Hintergrund sind mit der erweiterung ob sie betretbar sind. Wir haben aber auch 2 Tiles welche nicht wirklich Tiles sind dazu gehören Exittile und Doortile. Ein Exittile ist ein floortile nur mit zusätzlich einer Leiter drauf und existiert noch von vorherigen Framework. Sowie die Doortile welche ein Teleporter zu einen neuen Level ist. Diese beiden Tiles passen nicht wirklich in das aktuelle konzept und söllten meiner Meinung ohne großen Aufwand von Tile zu Entität konvertiert werden können. Dies würde ermöglichen, dass z.b. zusätzliches Verhalten beim Verlassen einer Ebene oder eines Raumes gemacht werden kann. Also würde ich eher aus den beiden Sonderfällen eine eigene Entität machen da sie ja eindeutig nicht nur statisch sind und nur als Fest statisches Level sind. Das Argument, dass dann ja alle Tiles an sich Entitäten sind, kann man nennen hier wäre aber die Frage wollen wir, Das Spiel später performanter machen. Dann wäre es besser zwar das Level zu einer Entität zu machen, aber nicht jedes eigentliche Tile.

TLDR: Ja sind sie, aber aus Performancegründen wird es meist nicht gemacht. Z.b. Minecraft gibt es zwar einzelne Blöcke, aber in der Welt platziert werden sie zu einem Mesh hinzugefügt.

[cagix]

@AHeinisch @AMatutat Im Prinzip sollten wir also alles als Entitäten modellieren, könnten aber in Lauzeitprobleme reinlaufen.

Ab wieviel Entitäten wird es denn kritisch? Sind wir da von der Größenordnung her in der Nähe? Oder ist das eher kein Problem im Moment?

offtopic zum Türthema: Also vielleicht lohnt es sich das Level an sich, als Entität umzuwandeln, welche eine LevelComponent hat welche dann das Level Mesh/Level Layout rendert. Alle Tiles bis auf das Türtile haben nur eine Animation und ein, ob sie betretbar sind. Welches nicht wirklich dafür spricht, dass sie eigene Entitäten benötigen. Außerdem kann, solange sie noch als ein Level gesehen werden, eine Optimierung in der Anzahl gemacht werden, wie z.b. alle Wände so zusammenfassen, dass sie so wenige "einzelne Tiles" haben wie möglich.

Den Gedanken von oben würde ich gern weiter diskutieren: Das Level ist eine Entität mit einer LevelComponent für alle statischen Tiles. Zusätzlich modelliert man die "beweglichen"/interagierbaren Tiles (Doors, Exit, ...) als eigene Entitäten mit Interaktion.

Das wäre ein Kompromiss in Bezug auf die Laufzeit (es kommen nur wenige neue Entitäten ins Spiel) und gleichzeitig könnte man Sachen wie "ich darf die Wand nicht betreten" oder "ich kann eine Tür aufmachen" über ECS umsetzen. Oder?

[AMatutat]

@AHeinisch und ich haben heute nochmal darüber gesprochen und aktuell scheint der Aufwand-Reward Faktor nicht zu passen. Wir müssten viele unserer Systeme überarbeiten und würden einfaches Handling vom Level und Level-Coordinaten verlieren.

Das ist jetzt erstmal ein later, ich sehe aber auch ein potenzielles thesis.

[cagix]

@AMatutat die label passen nicht, oder? thesis fehlt noch, und struct:dsl passt nicht?