spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »xTr1m«

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)

Theoretisch wäre es sich besser, dass auch in einen eigenen Thread zu verlagern, würde aber nur mehr Probleme mit sich bringen, als helfen.

Wie gesagt, ich versuche eben ein kleines Modell zu erschaffen, wie wir im Endeffekt nun vorgehen wollen.
Für mein Empfinden war die Simulation eine Art Befehlsgeber, wie der Befehl dann schließlich umgesetzt wird, dass ist nicht ihr Problem.
Befehl -> Ausführung -> Darstellung

So in etwa habe ich mir das vorgestellt, wobei die Entities immer zwischen Simulation (brauchen was neues zu tun) und eben jener "Zwischenschicht" (haben bereits was zu tun) hin und her geschickt werden.

Das es bestimmte Events gibt, die eine bestimmte Reaktion nach sich ziehen, ist klar. Solche "Events", wie z.B. Feind taucht auf, erzwingt nunmal ein umdenken. Das würde dann eben wieder an die Simulation abgegeben werden, damit ein neuer Befehl erteilt werden kann, der daraufhin ausgeführt wird.
Ich hoffe die Logik was ich so meine ist verständlich.
Für mich ist die "Simulation" einfach das "BigBrain" im Hintergrund, dass sich nicht mit der Ausführung beschäftigen sollte.

Aber gerade weil ich da noch ein wenig Redebedarf sehe, frage ich ja nach, was ihr euch so vorstellt. Aber anscheinend hat da jeder bisher so seinen eigenen Plan, deswegen müssen wir uns baldigst einen Schlachtplan für unser Projekt ausarbeiten

mfg

EDIT: Warum ich bisher überhaupt davon ausgegangen bin, dass da noch was fehlt, ist die Tatsache, dass beim update bisher nur ein "SimStep" mitgeschickt wird und keine TimeElapsed. Wie gesagt ich weiß, es ist dummy, aber irgendwo muss man eben mal anfangen was zu erarbeiten.

Vielleicht wäre es hilfreich die Kommunikation zwischen Vis und Sim noch mal grafisch darzustellen? Ab und zu sind Diagramme ja doch was schönes

Ich hatte das jetzt so wie Frank verstanden: die Sim bekommt ein Event "bitte bewegen zu xy", errechnet den Pfad und fängt an diesen am Entity zu setzten, in dem aktuellesFeld und neuesFeld (oder Richtung) aktuallisiert werden. Die Vis kümmert sich dann darum anhand der delta Zeit zwischen beiden Tiles zu interpolieren. Die Tiles sind in der Sim also nur Koordinaten (im Sinne von ganzzahling) und in der Vis eine "echte" Position.

Du könntest dein Konzept ja auch mal aufmalen anti. Das hilft bei genau solcher Kommunikation.

Vll ist Zwischenschicht auch einfach zu viel gesagt. Eigentlich bedarft es da keiner Schicht, sonderlich lediglich der Update Methode mit timeElapsed, die kontinuierlich (und nicht erst nach 500ms) aufgerufen wird.

Ich sehe keinen Mehrwert darin, wenn das "Brain" (die Simulation), den Worker alles vorkaut, wie es etwas zu lösen hat. Das WIE müssen sich die Worker erarbeiten. Deswegen würde ich auch das Update aus der Simulation komplett raus nehmen. Ich würde dem Worker einen abstrakten Task geben, den er abarbeiten soll, und die Simulation auf die Antworten reagieren lassen ("Bin fertig", "Habe ein Problem", etc.). Task sollte man hier sehr weit fassen. Task kann ein einfacher Move Befehl, als auch "Sammel Holz bis du umfällst" sein.

Durch dieses System könnte man die Simulation tatsächlich komplett autonom in einem separatem Thread laufen lassen (benötigt lediglich read access zum vorhandenen Zustand), und komplexe Task wie z.B. Pathfinding ebenso sehr leicht auslagern.

Um das Move Beispiel nochmal aufzugreifen.

-Die Simulation generiert den Task "Beweg dich nach X/Y".
-Der Worker macht daraus 2x "Move Up" (als Beispiel!)
-Im update wird jetzt die Bewegung da hin simuliert. Natürlich nur Tile genau.
-Die Vis interpoliert aus den vorhandenen Daten (Timestamp des Beginn des Task + sonstige Daten) die korrekte Bildschirmposition
-Ist der Worker an der gewünschten Position, meldet er der Sim "hey, ich bin fertig. Ich brauch was neues". Damit steht er für den nächsten Sim Step wieder zur Verfügung.

Natürlich hat die Sim auch das Recht Worker ihren momentanen Task abzunehmen und direkt etwas neues aufzutragen. Aber das ist wieder ein anderes Thema

PS: Ich weiß, mein paint Künste sind nicht sonderlich toll, aber ich hoffe man erkennt jetzt endlich, was ich sagen will.

Wenn ich das richtig interpretiere, würde dein Vorschlag ungefähr so mit dem aktuellen system passen:

1) User will Einheit X nach A bewegen, und macht die UI geste
2) Simulation erhält vom Programm den Auftrag "Einheit X soll sich nach A bewegen"
3) Simulation erzeugt den "Bewege Einheit" Task mit Parameter A, und weist ihn Einheit X zu.
4) Der Task wird beim updaten dann pathfinding usw. machen und seine Einheit manipulieren

Das "updaten der Tasks" ist dann dieser Zwischenschritt den du meintest, und welcher noch genauer spezifiziert werden sollte. Sind wir nun auf der gleichen Ebene?

Jep, korrekt

Dann kann doch das "Task updaten" eigentlich erstmals teils der Simulations-schleife sein. Damit haben wir quasi ne Struktur "Task" erzeugt, die auch ne methode "Update" hat, welche jede iteration aufgerufen wird.

Wenn wir nicht unbedingt vor haben, tasks extern in einem anderen Thread zu bearbeiten, dann gehört das in dem Simulations-thread rein.

Da beides (entity und task updates) nun theoretisch im simulations thread geschehen, ist das thema ja geklärt. Es gibt auch schon seit einer Weile ein issue für ein Task/Job system. Das ist dein gewollter "Zwischenschritt". https://github.com/Nimelrian/Project-Onyx/issues/11

Es gibt ja auch schon ein wenig Implementation zu den Issues fürs Tasksystem
Verstehe ich das richtig, dass wir quasi Tasks haben die wissen wie sie zu erledigen sind? Heißt anstatt die ganze Logik für alle möglichen Aktionen in das Entity (bzw. noch mal separat) zu packen, implementieren wir die Tasks als Strategie, so dass diese geupdated werden können (per Tick).

Das was hier als Zwischenschicht kommuniziert wurde gehört doch im Grunde direkt in die Visualisierung. Klingt für mich momentan zumindest so.

Ne, das gehört schon zur Simulation. Ein Bewegungs-Task im sinne von anti-freak ist genau die Strategie, die anhand von dem Spielzustand (Entitätposition, ihr typ, ihre vorlieben, Feinde in der Gegend, usw.) das nächstbeste Tile ermittelt, wohin sie sich bewegen soll, und dann ändert der Task die Entität. Alles in Simulationsschritten, denn diese komplexe Logik hat bei Visualisierung nichts zu suchen, die soll nur den aktuellen Zustand abbilden.

Zitat von »BVBFan«

Interessante Kolmmne auf Gamestar.de : http://www.gamestar.de/kolumnen/3232969/…in_spielen.html
Es geht um Retrografik in Spielen. Auch Dwarf Fortress ist ein Thema.

Zitat: "Warum setzen sich nicht mal ein paar Entwickler zusammen und legen so großartige Spiele wie Dwarf Fortress mit annähernd aktueller Grafik neu auf?"

Naja, wenn man mal die Spiellogik von Dwarf Fortress mit der von GTA5 vergleicht, würde ich behaupten, dass obwohl GTA5 ein umfangreiches Spiel ist, in DF noch wesentlich mehr, wesentlich komplexere Dinge geschehen. Und es geht halt schnell, das per Text zu beschreiben und sich das in der Phantasie vorzustellen, aber wollte man das alles Modellieren und Animieren, dürfte der Aufwand um Größenordnungen höher sein als GTA5. Ich denke, dass eine hübsche 3D Darstellung von allem was in DF passiert sehr sehr utopisch ist. Und für "ein paar Entwickler" ist es erst recht unmöglich.

Zitat von »xTr1m«

Ne, das gehört schon zur Simulation. Ein Bewegungs-Task im sinne von anti-freak ist genau die Strategie, die anhand von dem Spielzustand (Entitätposition, ihr typ, ihre vorlieben, Feinde in der Gegend, usw.) das nächstbeste Tile ermittelt, wohin sie sich bewegen soll, und dann ändert der Task die Entität. Alles in Simulationsschritten, denn diese komplexe Logik hat bei Visualisierung nichts zu suchen, die soll nur den aktuellen Zustand abbilden.

So meite ichs. Jut dann hab ich das richtig verstanden, ist nur schwierig sich darüber per Text zu unterhalten glaube ich