spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Wie wars gestern abend eigentlich?

Nimelrian und DeKugelschieber waren allein.

Sonst gab es keine Rückmeldungen? Ok, das is hart... Han jetzt ne Woche Urlaub, werde also auf jeden Fall endlich mal wieder richtig Zeit finden

So, heute wieder 20:30?

Wenn wir heute nicht zu viele Themen haben könnte man ja mal direkt Tickets verteilen oder gucken wer jetzt was konkretes macht.

Nachdem ich mir jetzt nochmal ein paar Stunden das Projekt angeschaut und ein wenig versucht habe daran zu arbeiten, bin ich auf ein etwas größeres Verständnisproblem gestoßen.

Vorweg: Ich bin mir bewusst, dass das meiste noch DummyCode für die ersten Ergebnisse darstellt, nur muss irgendwann einmal eine gesunde und verständliche Basis geschaffen werden.

Es geht dabei um die beiden getrennten Bereiche Visualisierung und Simulation.
Ich verstehe, dass man diese trennt, allerdings bin ich mit der momentanen Aufteilung noch nicht ganz einverstanden, oder ich verstehe etwas grundlegendes nicht.

Unter der Visualisierung verstehe ich -> den gegebenen Stand auf dem Bildschirm darstellen. Von mir aus kleinere Interpolation für das genaue Pixelmovement usw.
Soweit ist das auch durch die ersten Klassen bereits abgebildet.
Die Simulation hingegen sollte lediglich mit fixen Werten (Tiles (Bleiben wir mal bei der Bewegung)) arbeiten. Das ist auch so vorhanden. Allerdings wird die Simulation nur alle 500ms geupdatet. Das ist bisher so fest.

Wenn ich nun nach meinem Verständnis vorgehen würde, würde ich der Simulation den Befehl geben "Bewege die Figur dahin" und die Simulation:
1. sucht mir den kürzesten Weg (Pathfinding)
2. simuliert mir die benötigte Zeit zum Ende

D.h. die Simulation updatet die Position von Zeit zu Zeit, wenn ein neues Tile erreicht wurde. Die Visualisierung würde hier das Feintuning vornehmen und die Figur pixelgenau bewegen.
Nur mit dem momentanen System ist das nicht möglich (oder nicht sonderlich anschaulich), da eben nur alle 500ms geupdatet wird.

Ich würde hier vorschlagen, noch eine weitere Abstraktionsschicht einzuführen. Eine Schicht, die Befehle, die über Zeiträume hinweg ausführen soll, umsetzen kann, ohne die Simulation im Hintergrund zu stören.

Wir bleiben mal beim Movement:
Die Simulation sagt "Bewege die Figur da hin". Damit ist die Simulation raus, weil sie die bestmögliche Reaktion gefunden hat.
-> Jetzt springt die "Zwischenschicht" ein. Diese Schicht sorgt nun dafür, dass die Figur anhand der gegebenen Umstände (Hindernisse, Bewegungsgeschwindigkeit, etc.) an ihrem Ziel ankommt und informiert die Simulation über Erfolg oder etwaige Probleme. Dadurch wird sie am Ende wieder für einen Simulationsschritt "registriert".
-> Ganz oben kommt dann eben die Visualisierung, die zwischen den verschiedenen Tiles die Schritte interpoliert.

Ich hoffe das ist soweit verständlich.
Vll trifft man sich diese Woche nochmal und bespricht diesen Punkt

mfg

Irgendwie sowas in der Art wird nötig werden.
Ich hatte gedacht die Simulation sagt einfach "du als nächstes auf das Feld", die Visualisierung hat dann 500ms Zeit dorthin zu interpolieren.

Das wird wohl noch etwas tricky zu synchronisieren, bzw. man müsste dann evt. "hart" updaten (was doof aussieht). Quasi die gleichen Probleme wie im Multiplayer?
Für den Anfang reichts wenn die Figuren springen hatten wir gesagt. Ob eine ganze Schicht nötig ist, kannst du ja entscheiden

Naja, die Bewegung ist nur ein Beispiel. Ein anderes wäre das Combat System. Wenn das nur alle 500ms geupdatet wird, ist das auch dämlich.

Ich schau mal, was ich mir so ausdenken kann, vll hat ja sonst irgendwer noch ne Idee dazu

EDIT: Meiner Meinung nach gibt es 2 Alternativen.
1. Ein globales Update aller Entitys, sodass Movement, Combat, usw. immer mit geupdatet werden.
2. Eine Art Manager, bei der sich die Entitys registrieren, wenn sie denken, sie benötigen in nächster Zeit ein Update. Wenn sie keins mehr brauchen, werden sie aus dem Manager gekickt.

1. Hat den Vorteil es ist sehr leicht zu implementieren und benötigt keine weiteren Vorkehrungen.
2. Hat einen eventuellen Performance Gewinn, ist aber nicht ganz so einfach zu Handlen, da Entities auch zerstört werden können, wenn sie sich registriert haben. Hätte weitere Aufräum- und Validierungsarbeiten zur Folge.

Zuallererst, 500ms ist auch nicht in Stein gemeiselt, sondern auch dummy code, welches den Aspekt "Simulation macht hoch komplexe Aufgaben und braucht viel rechenleistung - Visualisierung ist flüssig und ruckelt nicht" übertrieben demonstriert.

Man kann auch die Schritte nach 100ms oder 50ms reduzieren, je nach dem wie wir unsere Zeiteinheit definieren wollen. Bei dwarf fortress gibts eine Simulationsrate von gefühlte 6-10 steps die Sekunde, wenn man sich die videos anguckt. Das sind 100ms-166ms.

Idealerweise sollen alle Aufgaben, die die Simulation erledigen soll, innerhalb dieser Zeitspanne geschehen, und 100ms ist allein schon sehr viel Zeit. Um eine gewisse synchronität zwischen Vis und Sim zu gewährleisten, habe ich erstmals vorgeschlagen, dass Simulationsschritte konstant lange dauern, und die überbliebene Zeit geschlafen wird.

Zitat

2. Eine Art Manager, bei der sich die Entitys registrieren, wenn sie denken, sie benötigen in nächster Zeit ein Update. Wenn sie keins mehr brauchen, werden sie aus dem Manager gekickt.

Das ist geplant und hatte ich vor demnächst so einzubauen.

Zitat

Ich würde hier vorschlagen, noch eine weitere Abstraktionsschicht einzuführen. Eine Schicht, die Befehle, die über Zeiträume hinweg ausführen soll, umsetzen kann, ohne die Simulation im Hintergrund zu stören.

Wir bleiben mal beim Movement:
Die Simulation sagt "Bewege die Figur da hin". Damit ist die Simulation raus, weil sie die bestmögliche Reaktion gefunden hat.
-> Jetzt springt die "Zwischenschicht" ein. Diese Schicht sorgt nun dafür, dass die Figur anhand der gegebenen Umstände (Hindernisse, Bewegungsgeschwindigkeit, etc.) an ihrem Ziel ankommt und informiert die Simulation über Erfolg oder etwaige Probleme. Dadurch wird sie am Ende wieder für einen Simulationsschritt "registriert".
-> Ganz oben kommt dann eben die Visualisierung, die zwischen den verschiedenen Tiles die Schritte interpoliert.

Da muss ich fragen, ist diese Zwischenschicht dann auch eine art Simulation, die auch in einem Thread existiert, und auch regelmäßig tickt? Wo ist dann der Unterschied zur aktuellen Simulationsinfrastruktur? Denn genau für sowas kann doch die Simulation jeden Schritt erledigen. Ich bleibe bei deinem Bespiel und erkläre wie man es machen könnte:
1) Das Spiel schickt der Simulation das Kommando, dass eine Entity sich nach Position XY bewegen soll (asynchron, sprich der Befehl wird erst beim nächsten Simulationstick bearbeitet).
2) Die Simulation wertet den Befehl aus, versetzt die Einheit in dem "Moving" Zustand
3) Bei jedem Simulationsschritt passiert in der Update der SimEntity folgendes:
- die Einheit wird je nach berechneter Bewegungsrichtung und -geschwindigkeit versetzt
- ist das Ziel erreicht, dann geht die Einheit in dem "Idle" Zustand, oder
- die direkte Umgebung (Hindernisse, usw.) werden evaluiert und daraus werden die nächste Bewegungsrichtung und -geschwindigkeit ermittelt (Pathfinding)

Wie dann auch eben implementiert, kann Vis anhand von der Bewegungsrichtung und -geschwindigkeit und der Simulationsrate die Tatsächliche Position präzise ermitteln.

Da sich die Welt ständig zwischen Simulatonsschritten ändert, müssen sich Einheiten dazu anpassen, sprich: Ihre Bewegung kann nicht 1x im Voraus berechnet werden, sondern kann sich je nach Umständen immer ändern. Bestes Beispiel: Ein Feind sieht die Entität und läuft auf ihr zu, spätestens bei direkter Nachbarschaft ist Schluss mit Bewegen.

Es wird dann noch viel viel mehr Logik zur Einheiten-Simulation kommen, weswegen ich die "Bewegung" nur als eine von vielen sehe. Sie auszulagern würde, gegeben mein Beispiel mit dem Feind oder die sich ständig verändernde Umgebung, die Sachen verkomplizieren.