Vererbung (Entity und co.)

[HierGibtEsDrachen]

Laut Klassen XML Kommentar ist eine Entity ein selbständiges Objekt im Spiel, als solche braucht sie ohnehin eine Update Funktion. Wer sich wegen Performance sorgen macht:
Perf.zip
Physikalischen Berechnungen z.Z. noch [xxx]Component in Basics, sollten eine eigene Basisklasse erhalten.

Die Component Klasse sollte überdacht werden, da sie momentan als Statespace verwendet wird und somit definiert was eine Entity ist bzw. kann.
Des weiteren sollte es eine generelle Unterscheidung von beweglichen und unbeweglichen Entities geben und bewegliche Entities sollten alle dafür notwendigen Parameter in der Basisklasse halten. Sich bewegen zu können ist eine grundlegende Funktion und sollte auch als solche implementiert werden. Sowie die dazugehörige Kollision #202.

Ein Ofen der Eisen schmelzen kann und dafür z.b. 1 Stunde benötigt oder auch ein elektrischer Schaltkreis (jaja Zukunftsmusik) stellt hingegen eine Sonderfunktion dar.
Wie weit die Standartimplementierung der Bewegung gehen soll ist allerdings ein anderes Thema.
Gerader Stoß oder auch Schiefer Stoß etc..
Einleitung der Bewegung über Kräfte und Momente?

[ManuelHu]

Mal zu den EntityComponents meinen Senf:

• BodyComponent macht ohne PositionComponent keinen Sinn (und ich würde fast sagen umgekehrt sind die Use-Cases beschränkt)
• ControllableComponent, HeadComponent, sind definitiv eigene Komponenten (Hund vs. Spieler)
• InventoryComponent und ToolbarComponent würde ich auch getrennt lassen (ein Last-Esel hat ein Inventar, aber keine Toolbar)
• Bei der RenderComponent könnte man fast sagen, Entities ohne 3D-Model gibt es nicht??

Evtl. macht es Sinn ein paar der EntityComponents aus der Basics in OctoAwesome.dll zu verschieben.

Aus den Basics kann die MassComponent weg (nicht verwendet). Die Kollision würde evtl. im "Core" Sinn machen.

Auf Körper wirken derzeit Kräfte (z.B. Gravitation) und Powers (die aufgebrachte Leistung), soweit ich weiß.

[jvbsl]

Dein Performancetest ist ziemlich nichts sagend, die Methode ist nicht virtual braucht somit keine vererbbare vtable was ja bei calls gerne viel Perf kostet, zusätzlich ist deine Methode noch leer, was dafür sorgt, dass C# die Methode im Release gleich gar nicht aufruft, so als gäbe es diesen call gar nicht, dann ist das ganze natürlich höchst performant.(Wurde sogar von marcus getestet)

Außerdem bin ich doch eindeutig eine Entität, aber ich mach ja auch nichts, das sagen zumindest immer alle ausm TeamSpeak.
Entities müssen nicht unbedingt etwas tun, ich meine hier geht es ja auch einfach evtl. um das EntityComponent System(was man aber mMn tatsächlich überarbeiten sollte), wobei kleine Pflanzen wie graß dazu zählen könnte, weil man die nur bedingt als normale Blöcke rendern will und auf entfernung sehr speziell(LOD z.b.) behandelt, oder auch ausblendet,

Edit: RenderComponent ohne Model kann vieles sein, was dynamisch z.B. Vertices erzeugt, oder einfach direkt vertices rendert, whatever, da braucht man nicht den bloat von Model reinhauen(auch wenn ich da grad tatsächlich am optimieren bin)

[HierGibtEsDrachen]

Ja Meister ...
Auf was ich eigentlich hinaus wollte ist das der bool Check weniger kostet als die TypeOf() Methode?

[jvbsl]

Endlich erkennts mal jemand :P
naja typeof sollte generell weggelassen werden, mir ist im Moment leider auch nicht wirklich klar auf welche Stelle du ansprichst. Bedenke, dass viele Leute hier viel Code gar nicht oder vor Ewigkeiten gesehen haben.
Wenn ichs richtig verstanden habe dürfte das ein Grundsätzliches Problem des aktuellen Komponenten systems sein? Was somit später ja wegfallen würde. Ich meine von irgendwelchen Heap Objekten zwei unterschiedliche Listen zu halten alle Updateables alle Renderables etc. in einer Liste ist ja auch nur ne Referenz und ansonsten kann man zu Jederzeit über ein gescheites Komponentensystem diese Informationen auslesen ohne groß typüberprüfungen o.ä.

[HierGibtEsDrachen]

kann mir mal einer sagen was damit gemeint ist? was ist denn schön :D
oder warum das unschön ist, also wie du es dir vorgestellt hast.
`
if (e.Id == 0)

            return;

        //TODO:Sehr unschön     <-----------------------           

        if (e.Components.ContainsComponent<BoxCollisionComponent>())

            CheckBoxCollision(gameTime,e,movecomp,poscomp);

`

[HierGibtEsDrachen]

Also hab es mir mal die letzten paar Tage genauer angeschaut. Ich würde mich dran versuchen, und das Entity-,Component- und Extensionsystem genauer durch denken um zu definieren wie es sein sollte bzw. wie es umgesetzt werden könnte. Kann aber jetzt schon sagen, dass die Änderungen umfangreich sein werden. Deswegen mach ich mal eine PP über die ihr euch dann drüber machen könnt.

[HierGibtEsDrachen]

Hätte mal paar fragen. Ist es möglich die UI auch dynamisch zu erstellen? Da durch Extensions unbekannte Elemente im Spiel auftauchen, sollte die UI die entsprechenden Screens für die Interaktionen dynamisch erzeugen können. Ein bisschen Richtung WPF wäre ganz gut xD
Hier schon mal ein Beispiel: Die ToolbarComponente verschwindet aus Octoawesom.dll und wandert komplett in Basiscs.dll. Ja ich weiß es wurden Stimmen laute das eher Komponenten in die Octoawesom.dll geschoben werden sollten, aber wenn wir das Anfangen können wir es mit den Extensions auch gleich bleiben lassen und brauchen keine Komponenten.
Hab mir dazu ein paar Interfances überlegt die es dem Client und Server ermöglichen sollen mit Komponenten besser umgehen zu können.

@jvbsl, was hälst du davon die Entitys Instanziert zu rendern. Weiß jetzt zwar nicht was im Model.Draw() genau passiert aber glaub das Zeichnet ja einfach nur ein Model? Mit einem IDrawable Interface für Entitys würde das erleichtern und deine LOD Überlegungen auch möglich machen. Kann das Model auch anders gerendern werden als über Model.Draw() indem man z.B. den Buffer rauszieht und direkt mit dem Buffer arbeitet?

Da ihr grade sowieso an der Simulation bastelt. Ist es möglich und haltet ihr es für sinnvoll (also ich schon) die Simulation.cs aus Octoawesome.dll in die Runtime.dll zu schieben.
Ich bin der Meinung, dass wenn eine Extension die Simulation kennt hat man etwas falsch gemacht.

[ManuelHu]

Da ihr grade sowieso an der Simulation bastelt. Ist es möglich und haltet ihr es für sinnvoll (also ich schon) die Simulation.cs aus Octoawesome.dll in die Runtime.dll zu schieben.
Ich bin der Meinung, dass wenn eine Extension die Simulation kennt hat man etwas falsch gemacht.

Kann man schon so sehen - Aber wie sollte eine Erweiterung, sie z.B. Wauzi-Spawneggs implementiert, diesen injizieren? - Derzeit wäre das dann nicht mehr möglich.

Hätte mal paar fragen. Ist es möglich die UI auch dynamisch zu erstellen? Da durch Extensions unbekannte Elemente im Spiel auftauchen, sollte die UI die entsprechenden Screens für die Interaktionen dynamisch erzeugen können. Ein bisschen Richtung WPF wäre ganz gut xD

Hängt davon ab, was du mit dynamisch meinst. Prinzipiell kann ich die UI mit Code verändern und Controls ein/aushängen. XAML/XML wie bei WPF ist nicht möglich und auch nicht in Planung. Es fehlt aber eine API, die Erweiterungen Zugriff auf die UI gewährt. Grundsätzlich ist es auch schwerer: Control injizieren, wenn ja wo (ein Screen kann immer nur ein Control als Child haben). Der Inventardialog ist z.B. aber kein Control, sondern ein Screen der daneben noch an einen vom Nutzer änderbares Tastaurkürzel gebunden ist.

Es gibt seit über einem Jahr die Idee, das UI erweiterbar zu machen, nur ist noch niemand dazugekommen.

EDIT: Screens und Controls sind stinknomrale Klassen, die von einer Basisklasse erben.

[HierGibtEsDrachen]

Bin wohl ein bisschen zu weit vom Denken her...
Wenn durch eine Extension ein Ofen hinzugefügt wird der Ressourcen verarbeiten kann, dann benötige ich dafür eine Art Dialog zwischen dem Player und dem Ofen. Da es aber eine Extenison ist und der Client den Ofen nicht kennt (wie es gerade mit dem Inventar oder der Toolbar ist) wird dafür eine Mechanismus benötigt der einen Entity interactionscreen aufruft. In dem sowohl das Inventar des Players, des Ofens und noch weitere Bedienelemente sind. Dadurch könnte per Drag and Drop Material in den Ofen befördert werden und anschließend müsste nur noch ausgewählt werden was hergestellt werden soll.

[ManuelHu]

Schon klar. Aber so weit sind wir noch lange nicht ;-) Ressourcen haben wir keine und von interaktion mit Entities kann noch keine Rede sein - wir haben ja noch nicht mal eine Kollision. Ui wird definitiv irgendwann erweiterbar sein, ist aber nicht prio 1.

Du hast quasi jetzt aber selbst ein Argument geliefert warum Komponenten zumindest als Basisset in der octoawesome.dll liegen sollen - damit dritterweiterungen von gewissen Standards (hier Inventar) ausgehen können.

[HierGibtEsDrachen]

Interface ^^
Moment Moment, ich Krieg es da schon rein dass die Basiserweiterung nicht in Octoawesome liegen müssen und wenn ich Zaubern muss.
Versteh mich nicht falsch ^^ ich will auch keinen nötigen etwas zu tun, ich wollte es nur wissen.

[HierGibtEsDrachen]

Was haltet ihr von einer IEntityDefinition?

[Gallimathias]

Wenn du einen konkreten Vorschlag einer Implementierung hast dann mache bitte entweder ein neues Issue auf, oder implementiere es einfach selber ^^ @HierGibtEsDrachen

[HierGibtEsDrachen]

Ich wollte wissen ob wir da auch eine (brauchen) / (haben wollen würden). Bin ja wie gesagt am Entity - Component- und Extensionsystem und ein bisschen Refaktorisierung + UI ....
Viel spaß das zu Mergen wenn ihr es einbaut xD

Also sagt mir eure Meinung zu den IEntityDefinitions oder wir lassen es hard gecoded in der IExtension Implementierung. (:

[Gallimathias]

@HierGibtEsDrachen Da ich nicht weiß was deine IEntityDefinition machen soll kann ich dir keine Antwort darauf geben. Ich kann leider nicht in deinen Kopf blicken ;).

Ich sehe dein eingehendes Issue als Frage/Anmerkung. Die Implementierung einer IEntityDefinition ist ein eigenes Thema bzw. Issue. Oder eben ein Teil eines Issues.