search

OctoAwesome / octoawesome

This is the code repository for the OctoAwesome project - a collection of daily, 20 minute long game development tutorial videos, iterating over the same piece of code
http://octoawesome.net/
MIT License
108 stars 31 forks source link

Rendern als Component #188

Open fnawratil opened 7 years ago

fnawratil commented 7 years ago

Ich hab mal aufgrund des neuen Component-System einen Vorschlag bezüglich des Renderings:

Im Moment haben wir ja Entities welche EntityComponents besitzen. Diese EntityComponents sind eigentlich nur Informationsträger, und kommen in den SimulationComponents zum Einsatz, welche für jede Entity je nach vorhandenen EntityComponents simulieren.

Beim Basteln eines HealthComponent bin ich dann auf folgendes Problem gestoßen: Jegliches Rendering passiert bei uns im Client, welcher jedoch keinen direkten Zugriff auf die Extensions hat. Damit sind wir auch nicht in der Lage irgendwas aus Extensions zu rendern (z.B. die Health-Bar).

Mein Vorschlag ist daher, dass es ein "RenderSimulationComponent" sowie z.B. ein "HUDEntityComponent" gibt. Im Client selbst sind nur mehr die Menüs vorhanden, der komplette GameScreen wird vom "RenderSimulationComponent" gerendert. "HUDEntityComponents" können z.B. Controls bereitstellen, welche auf den GameScreen gezeichnet werden.

Dies erlaubt es uns nicht nur einfach in Extensions zu rendern, sondern im Falle des Server-Betriebs auch einfach das "RenderSimulationComponent" zu deaktivieren, und somit die Simulation wie gehabt, nur ohne Rendering zu verwenden.

Mich würde mal interessieren was Ihr davon haltet...

Grüße, rave

jvbsl commented 7 years ago

dabei finde ich sollte aber betont werden, dass es wichtig ist, dass die Entities nur die Informationen zum Rendern bereitstellen, jedoch nicht selbst das Rendern übernehmen, für Controls können wir da vlt. noch eine Ausnahme machen, für alles andere was InGame passiert wär es aber von nachteil, da ich gerne die Möglichkeit hätte so viel wie möglich zu batchen.

tomwendel commented 7 years ago

Ich schließe mich an.

Entities stellen das Datenmodell da und ein komponentenbasiertes Render-System sorgt dann für die Darstellung. Das Problem endet aber nicht bei UI Komponenten, sondern betrifft ja auch das Rendering von Entities. Nachher wollen wir vielleicht, dass Entities beim Rendern auch Hüte tragen können. Es macht also Sinn auch das komplette visuelle System mit Komponenten auszustatten.

Von: jvbsl [mailto:notifications@github.com] Gesendet: Freitag, 30. Dezember 2016 20:22 An: OctoAwesome/octoawesome Cc: Subscribed Betreff: Re: [OctoAwesome/octoawesome] Rendern als Component (#188)

dabei finde ich sollte aber betont werden, dass es wichtig ist, dass die Entities nur die Informationen zum Rendern bereitstellen, jedoch nicht selbst das Rendern übernehmen, für Controls können wir da vlt. noch eine Ausnahme machen, für alles andere was InGame passiert wär es aber von nachteil, da ich gerne die Möglichkeit hätte so viel wie möglich zu batchen.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/OctoAwesome/octoawesome/issues/188#issuecomment-269811570, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ACTLZPqyJFTlAzS0t6gwEQWBo0eqxoiwks5rNVnzgaJpZM4LYWGq.

XYZLassi commented 7 years ago

Also ist alles richtig. Aber jetzt nach dem wie auch die ersten Entities rendern müsste das ganze Entitysystem mit dem Rendering überarbeitet werden (also angepasst werden). Also wenn sollte einer oder zwei das auf einmal anpacken, weil das könnte doch etwas größer werden. Das betrifft dann auch das beschrieben von Entities, für Hüte

Ich finde auch es sollte mehr getrennt werden HudEntityComoponent find ich jetzt nicht sehr tolle. Es wär ja sinnvoll dann genau so wie bei der Simulation eigene Komponenten zu entwickeln die bestimmte Entitycomponenten rendern könne.

Wegen den Controlls fänd ich eine Deklaration unabhängig von MonoGameUI recht geil, ich sag mal ähnlich wie Xaml bei WPF, wobei das recht kompliziert werden sollte.

Gallimathias commented 7 years ago

Ich hatte es ja bereits erwähnt, mir würde in dem zuge ja ein Framework design bzw. eine Framework architektur gefallen. Die Extensions stellen alle Informationen bereit. Das Framework, also Octo Core übernimmt die Aufbereitung und der client ist eigentlich doof, weil der rendert stur was das Framework ihm zum knappern gibt.

unbenannt

tomwendel commented 7 years ago

Jepp :)

Tiny Keyboard, tiny Message

Von: Gallimathiasmailto:notifications@github.com Gesendet: ‎31.‎12.‎2016 14:16 An: OctoAwesome/octoawesomemailto:octoawesome@noreply.github.com Cc: Tom Wendelmailto:tom.wendel@rabbitcode.de; Commentmailto:comment@noreply.github.com Betreff: Re: [OctoAwesome/octoawesome] Rendern als Component (#188)

Ich hatte es ja bereits erw?hnt, mir würde in dem zuge ja ein Framework design bzw. eine Framework architektur gefallen. Die Extensions stellen alle Informationen bereit. Das Framework, also Octo Core übernimmt die Aufbereitung und der client ist eigentlich doof, weil der rendert stur was das Framework ihm zum knappern gibt.

[unbenannt]https://cloud.githubusercontent.com/assets/16351673/21577667/89ed1274-cf63-11e6-83af-00647b4de586.PNG

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/OctoAwesome/octoawesome/issues/188#issuecomment-269864585, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ACTLZNBwP19LWyfALw6ZlcI331SYAIOdks5rNlWcgaJpZM4LYWGq.