Wie kann ich eine deterministische Physiksimulation durchführen?

Ich erstelle ein Physikspiel mit starren Körpern, in dem Spieler Teile und Teile bewegen, um ein Puzzle / eine Karte zu lösen. Ein äußerst wichtiger Aspekt des Spiels ist, dass beim Starten einer Simulation diese überall gleich abläuft , unabhängig von Betriebssystem, Prozessor usw.

Es gibt Raum für viel Komplexität, und Simulationen können über einen langen Zeitraum ausgeführt werden. Daher ist es wichtig, dass die Physik-Engine in Bezug auf ihre Gleitkommaoperationen vollständig deterministisch ist "scheitern" an einem anderen.

Wie kann ich diesen Determinismus in meinem Spiel erreichen? Ich bin bereit, eine Vielzahl von Frameworks und Sprachen zu verwenden, einschließlich Javascript, C ++, Java, Python und C #.

Box2D (C ++) und seine Entsprechungen in anderen Sprachen haben mich in Versuchung geführt, da es meine Bedürfnisse zu erfüllen scheint, aber es fehlt ein Gleitkomma-Determinismus, insbesondere bei trigonometrischen Funktionen.

Die beste Option, die ich bisher gesehen habe, war das Java-Äquivalent (JBox2D) von Box2D. Es scheint einen Versuch zu geben, Fließkomma-Determinismus zu verwenden, StrictMathanstatt Mathfür viele Operationen, aber es ist unklar, ob diese Engine alles garantieren wird, was ich brauche, da ich das Spiel noch nicht erstellt habe.

Ist es möglich, einen vorhandenen Motor zu verwenden oder zu modifizieren, um ihn meinen Bedürfnissen anzupassen? Oder muss ich selbst einen Motor bauen?

BEARBEITEN: Überspringen Sie den Rest dieses Beitrags, wenn Sie sich nicht darum kümmern, warum jemand eine solche Präzision benötigt. Einzelpersonen in Kommentaren und Antworten scheinen zu glauben, ich suche nach etwas, das ich nicht sollte, und als solches erkläre ich weiter, wie das Spiel funktionieren soll.

Der Spieler erhält ein Puzzle oder Level, das Hindernisse und ein Ziel enthält. Eine Simulation läuft zunächst nicht. Sie können dann Teile oder Werkzeuge verwenden, um eine Maschine zu bauen. Sobald sie auf Start drücken, beginnt die Simulation und sie können ihre Maschine nicht mehr bearbeiten. Wenn die Maschine die Karte löst, hat der Spieler das Level geschlagen. Andernfalls müssen sie die Stopp-Taste drücken, den Computer wechseln und es erneut versuchen.

Der Grund, warum alles deterministisch sein muss, ist, dass ich vorhabe, Code zu erstellen, der jede Maschine (eine Reihe von Teilen und Werkzeugen, mit denen versucht wird, eine Ebene zu lösen) einer XML- oder JSON-Datei zuordnet, indem Position, Größe und Drehung jedes Teils aufgezeichnet werden. Es ist dann für Spieler möglich, Lösungen (die durch diese Dateien dargestellt werden) gemeinsam zu nutzen, um sie zu überprüfen, voneinander zu lernen, Wettbewerbe abzuhalten, zusammenzuarbeiten usw. Bei den meisten Lösungen handelt es sich natürlich um einfache oder schnelle Lösungen diejenigen, werden nicht von einem Mangel an Determinismus betroffen sein. Aber die langsamen oder komplexen Designs, die wirklich schwierige Levels lösen, sind wahrscheinlich die interessantesten und die es wert sind, geteilt zu werden.

Zum deterministischen Umgang mit Gleitkommazahlen

Fließkomma ist deterministisch. Nun, das sollte es sein. Es ist kompliziert.

Es gibt reichlich Literatur zu Fließkommazahlen:

• Was jeder Informatiker über Gleitkomma-Arithmetik wissen sollte
• DER NEUE IEEE-754-STANDARD FÜR SCHWIMMENDE PUNKTARITHMETIK
• IEEE 754-2008 Revision

Und wie problematisch sie sind:

• Konsistenz der Gleitkommaergebnisse oder Warum gibt meine Anwendung nicht immer die gleiche Antwort? .
• Plattformübergreifende Probleme mit Gleitkomma-Arithmetik in C ++ .
• Die Fallstricke bei der Überprüfung von Gleitkommaberechnungen .
• Ist Gleitkomma-Mathematik deterministisch? .
• Was könnte ein deterministischer Prozess verursacht Gleitkomma - Fehler zu erzeugen .
• Konsistenz: wie der Zweck der IEEE Floating - Point zu besiegen .

Für abstrakte. Zumindest in einem einzelnen Thread sollten dieselben Vorgänge mit denselben Daten in derselben Reihenfolge deterministisch sein. Wir können also damit beginnen, uns Gedanken über Eingaben zu machen und die Reihenfolge zu ändern.

Eine solche Eingabe, die Probleme verursacht, ist die Zeit.

Zunächst sollten Sie immer den gleichen Zeitschritt berechnen. Ich sage nicht, um die Zeit nicht zu messen, ich sage, dass Sie keine Zeit an die Physiksimulation weitergeben werden, da zeitliche Schwankungen eine Rauschquelle in der Simulation sind.

Warum messen Sie die Zeit, wenn Sie sie nicht an die Physiksimulation weitergeben? Sie möchten die verstrichene Zeit messen, um zu wissen, wann ein Simulationsschritt aufgerufen werden soll, und - vorausgesetzt, Sie verwenden Schlaf - wie viel Zeit zum Schlafen.

Somit:

• Zeit messen: Ja
• Zeit in der Simulation verwenden: Nein

Nun, Anweisung neu anordnen.

Der Compiler könnte entscheiden, dass dies f * a + bdasselbe ist b + f * a, jedoch kann dies zu einem anderen Ergebnis führen. Es könnte auch kompiliert werden, um fmadd zu erstellen , oder es könnte entscheiden, dass mehrere Zeilen, die zusammen auftreten, mit SIMD oder einer anderen Optimierung, die mir derzeit nicht in den Sinn kommt , geschrieben werden . Und denken Sie daran, wir möchten, dass die gleichen Vorgänge in der gleichen Reihenfolge ausgeführt werden. Es liegt nahe, dass wir steuern möchten, welche Vorgänge ausgeführt werden.

Und nein, mit double werden Sie nicht gerettet.

Sie müssen sich Gedanken über den Compiler und seine Konfiguration machen, insbesondere um Gleitkommazahlen im Netzwerk zu synchronisieren. Sie müssen die Builds dazu bringen, zuzustimmen, dasselbe zu tun.

Eine Schreibanordnung wäre wohl ideal. Auf diese Weise entscheiden Sie, welche Operation durchgeführt werden soll. Dies könnte jedoch ein Problem für die Unterstützung mehrerer Plattformen sein.

Somit:

• Ern ... Hmm ... Verwenden Sie einen Compiler, mit dem Sie den Umgang mit Gleitkommazahlen konfigurieren können . Zum Beispiel siehe / fp (Festlegen des Gleitkomma-Verhaltens) .

Der Fall für Festkommazahlen

Aufgrund der Art und Weise, wie Floats im Speicher dargestellt werden, werden große Werte an Genauigkeit verlieren. Es liegt nahe, Ihre Werte klein zu halten (Clamp), um das Problem zu mindern. Somit keine großen Geschwindigkeiten und keine großen Räume. Dies bedeutet auch, dass Sie diskrete Physik verwenden können, da Sie ein geringeres Tunnelungsrisiko haben.

Andererseits häufen sich kleine Fehler an. Also abschneiden. Ich meine, skalieren und auf einen ganzzahligen Typ umwandeln. Auf diese Weise wissen Sie, dass sich nichts aufbaut. Es wird Operationen geben, die Sie mit dem Integer-Typ durchführen können. Wenn Sie zum Gleitkomma zurückkehren müssen, können Sie die Skalierung umwandeln und rückgängig machen.

Beachten Sie, dass ich Skala sage. Die Idee ist, dass 1 Einheit tatsächlich als Zweierpotenz dargestellt wird (zum Beispiel 16384). Was auch immer es ist, mach es zu einer Konstanten und benutze es. Sie verwenden es grundsätzlich als Festkommazahl. In der Tat, wenn Sie richtige Festkommazahlen aus einer zuverlässigen Bibliothek viel besser verwenden können.

Ich sage abgeschnitten. In Bezug auf das Rundungsproblem bedeutet dies, dass Sie dem letzten Teil des Wertes, den Sie nach der Besetzung erhalten haben, nicht vertrauen können. Also, bevor die Besetzungsskala ein bisschen mehr als Sie brauchen, und kürzen Sie es danach.

Somit:

• Werte klein halten: Ja
• Sorgfältige Rundung: Ja
• Festkommazahlen wenn möglich: Ja

Warten Sie, warum brauchen Sie Gleitkomma? Könnten Sie nicht nur mit einem Integer-Typ arbeiten? Oh, richtig. Trigonometrie und Bestrahlung. Sie können Tabellen für Trigonometrie und Radikation berechnen und in Ihrer Quelle backen lassen. Sie können auch die Algorithmen implementieren, mit denen sie mit Gleitkommazahlen berechnet werden, außer mit Festkommazahlen. Ja, Sie müssen Speicher, Leistung und Präzision in Einklang bringen. Sie könnten sich jedoch von Gleitkommazahlen fernhalten und deterministisch bleiben.

Wusstest du, dass sie so etwas für die ursprüngliche PlayStation gemacht haben? Bitte treffen Sie meinen Hund, Flecken .

Übrigens sage ich nicht, Fließkomma für Grafiken nicht zu verwenden. Nur für die Physik. Ich meine, klar, die Positionen werden von der Physik abhängen. Wie Sie wissen, muss ein Collider jedoch nicht mit einem Modell übereinstimmen. Wir wollen die Ergebnisse der Kürzung der Modelle nicht sehen.

Also: FESTE PUNKTNUMMERN VERWENDEN.

Um es klar auszudrücken: Wenn Sie einen Compiler verwenden können, mit dem Sie die Funktionsweise von Fließkommazahlen festlegen können und der für Sie ausreicht, können Sie dies tun. Das ist nicht immer eine Option. Außerdem tun wir dies für den Determinismus. Festkommazahlen bedeuten nicht, dass es keine Fehler gibt, schließlich haben sie eine begrenzte Genauigkeit.

Ich denke nicht, dass "Festkommazahlen hart sind" ein guter Grund ist, sie nicht zu verwenden. Und wenn Sie einen guten Grund haben möchten, sie zu verwenden, dann ist es Determinismus, insbesondere Determinismus über Plattformen hinweg.

Siehe auch:

• 3D-Grafik auf mobilen Geräten - Teil 2: Festkomma-Mathematik
• Die vernachlässigte Kunst der Fixpunktarithmetik
• CORDIC-Algorithmus-Simulationscode

Nachtrag : Ich schlage vor, die Größe der Welt klein zu halten. Trotzdem bringen sowohl OP als auch Jibb Smart den Punkt auf den Punkt, dass die Bewegung von den Ursprungs-Floats weniger genau ist. Das wird Auswirkungen auf die Physik haben, die weit früher als der Rand der Welt zu sehen sein wird. Festkommazahlen haben eine feste Genauigkeit und sind überall gleich gut (oder schlecht, wenn Sie es vorziehen). Was gut ist, wenn wir Determinismus wollen. Ich möchte auch erwähnen, dass die Art und Weise, wie wir normalerweise Physik betreiben, die Eigenschaft hat, kleine Variationen zu verstärken. Siehe Der Schmetterlingseffekt - Deterministische Physik in The Incredible Machine und Contraption Maker .

Ein anderer Weg, um Physik zu machen

Ich habe nachgedacht, der Grund, warum sich der kleine Fehler in der Genauigkeit von Gleitkommazahlen verstärkt, ist, dass wir Iterationen mit diesen Zahlen durchführen. In jedem Simulationsschritt nehmen wir die Ergebnisse des letzten Simulationsschritts und bearbeiten sie. Häufen sich Fehler auf Fehler. Das ist dein Schmetterlingseffekt.

Ich glaube nicht, dass wir einen einzelnen Build mit einem einzelnen Thread auf demselben Computer sehen werden, der bei derselben Eingabe unterschiedliche Ausgaben liefert. Aber auf einer anderen Maschine könnte es sein, oder ein anderer Build könnte es.

Es gibt ein Argument, um dort zu testen. Wenn wir genau entscheiden, wie die Dinge funktionieren sollen, und auf der Zielhardware testen können, sollten wir keine Builds veröffentlichen, die ein anderes Verhalten aufweisen.

Es gibt jedoch auch ein Argument dafür, nicht wegzuarbeiten, das so viele Fehler ansammelt. Vielleicht ist dies eine Gelegenheit, Physik auf eine andere Art und Weise zu betreiben.

Wie Sie vielleicht wissen, gibt es eine kontinuierliche und eine diskrete Physik. Beide arbeiten daran, wie weit jedes Objekt im Zeitschritt vorrücken würde. Die kontinuierliche Physik hat jedoch die Möglichkeit, den Zeitpunkt der Kollision herauszufinden, anstatt verschiedene mögliche Zeitpunkte zu untersuchen, um festzustellen, ob eine Kollision stattgefunden hat.

Daher schlage ich Folgendes vor: Verwenden Sie die Techniken der kontinuierlichen Physik, um herauszufinden, wann die nächste Kollision jedes Objekts mit einem großen Zeitschritt stattfinden wird, der viel größer ist als der eines einzelnen Simulationsschritts. Dann nehmen Sie den nächsten Kollisionszeitpunkt und finden heraus, wo sich in diesem Moment alles befinden wird.

Ja, das ist viel Arbeit in einem einzigen Simulationsschritt. Das bedeutet, dass die Simulation nicht sofort startet ...

... Sie können jedoch die nächsten Simulationsschritte simulieren, ohne jedes Mal die Kollision zu überprüfen, da Sie bereits wissen, wann die nächste Kollision stattfinden wird (oder dass im großen Zeitschritt keine Kollision auftritt). Darüber hinaus sind die in dieser Simulation akkumulierten Fehler irrelevant, da wir, sobald die Simulation den großen Zeitschritt erreicht, nur die zuvor berechneten Positionen platzieren.

Jetzt können wir das Zeitbudget verwenden, das wir verwendet hätten, um jeden Simulationsschritt auf Kollisionen zu überprüfen, um die nächste Kollision nach der gefundenen zu berechnen. Das heißt, wir können voraussimulieren, indem wir den großen Zeitschritt verwenden. Unter der Annahme, dass der Umfang einer Welt begrenzt ist (dies funktioniert nicht für große Spiele), sollte es eine Warteschlange zukünftiger Zustände für die Simulation geben, und dann sollte jeder Frame, den Sie gerade interpolieren, vom letzten Zustand zum nächsten.

Ich würde für Interpolation argumentieren. Da es jedoch Beschleunigungen gibt, können wir nicht einfach alles auf die gleiche Weise interpolieren. Stattdessen müssen wir unter Berücksichtigung der Beschleunigung jedes Objekts interpolieren. In diesem Fall können wir die Position genauso aktualisieren wie für den großen Zeitschritt (was auch bedeutet, dass dies weniger fehleranfällig ist, da wir nicht zwei verschiedene Implementierungen für dieselbe Bewegung verwenden würden).

Hinweis : Wenn wir diese Gleitkommazahlen verwenden, löst dieser Ansatz nicht das Problem, dass sich Objekte unterschiedlich verhalten, je weiter sie vom Ursprung entfernt sind. Es ist zwar richtig, dass die Präzision verloren geht, je weiter Sie sich vom Ursprung entfernen, aber das ist immer noch deterministisch. In der Tat, das ist der Grund, warum ich das ursprünglich nicht erwähnt habe.

Nachtrag

Vom OP im Kommentar :

Die Idee ist, dass die Spieler ihre Maschinen in einem bestimmten Format (wie xml oder json) speichern können, so dass die Position und Rotation der einzelnen Teile aufgezeichnet werden. Diese XML- oder JSON-Datei wird dann verwendet, um das Gerät auf dem Computer eines anderen Players zu reproduzieren.

Also kein Binärformat, oder? Das bedeutet, dass wir uns auch Sorgen machen müssen, ob die wiederhergestellten Gleitkommazahlen mit dem Original übereinstimmen oder nicht. Siehe: Überarbeitete Float-Präzision: Portabilität mit neun Stellen

Ich arbeite für ein Unternehmen, das ein bekanntes Echtzeit-Strategiespiel herstellt, und ich kann Ihnen sagen, dass Gleitkommadeterminismus möglich ist.

Die Verwendung unterschiedlicher Compiler oder desselben Compilers mit unterschiedlichen Einstellungen oder sogar unterschiedlicher Versionen desselben Compilers kann den Determinismus aufheben.

Wenn Sie ein Crossplay zwischen Plattformen oder Spielversionen benötigen, müssen Sie, wie ich finde, auf Fixed Point umsteigen - das einzige mögliche Crossplay, das mir bei Floating Point bekannt ist, ist zwischen PC und XBox1, aber das ist ziemlich verrückt.

Sie müssen entweder eine Physik-Engine finden, die vollständig deterministisch ist, oder eine Open-Source-Engine nehmen und deterministisch machen, oder Ihre eigene Engine rollen. Ich habe das Gefühl, dass Unity of all things eine deterministische Physik-Engine hinzugefügt hat, aber ich bin mir nicht sicher, ob sie nur auf derselben Maschine oder auf allen Maschinen deterministisch ist.

Wenn Sie versuchen, Ihre eigenen Sachen zu rollen, können ein paar Dinge helfen:

• IEE754-Floats sind deterministisch, wenn Sie nichts zu fruchtiges tun (google "IEE754-Determinismus" für weitere Informationen darüber, was abgedeckt wird oder nicht)
• Sie müssen sicherstellen, dass für jeden Client der Rundungsmodus und die Genauigkeit identisch festgelegt sind (verwenden Sie controlfp, um sie festzulegen).
• Rundungsmodus und Genauigkeit können von bestimmten Mathematikbibliotheken geändert werden. Wenn Sie also geschlossene Bibliotheken verwenden, möchten Sie diese möglicherweise nach dem Tätigen von Aufrufen überprüfen (erneut mit controlfp).
• Einige SIMD-Anweisungen sind deterministisch, viele nicht. Seien Sie vorsichtig
• Wie oben erwähnt, benötigen Sie zur Sicherstellung des Determinismus auch dieselbe Plattform, dieselbe exakte Version desselben Compilers, der dieselbe Konfiguration mit denselben Compilereinstellungen kompiliert
• Bauen Sie einige Tools ein, um Status-Desynchronisierungen zu erkennen und zu diagnostizieren - z. B. CRC des Spielstatus in jedem Frame, um zu erkennen, wann eine Desynchronisierung auftritt, und verfügen Sie über einen ausführlichen Protokollierungsmodus, den Sie aktivieren können, wenn Änderungen am Spielstatus mühsam in einer Datei protokolliert werden. Nehmen Sie dann 2 Dateien aus Simulationen, die nicht mehr miteinander synchronisiert sind, und vergleichen Sie sie in einem Diff-Tool, um festzustellen, wo ein Fehler aufgetreten ist
• Initialisieren Sie alle Variablen im Spielstatus, der Hauptquelle für Desyncs
• Die gesamte Spielsimulation muss jedes Mal in genau der gleichen Reihenfolge ablaufen, um Desyncs zu vermeiden. Es ist unglaublich einfach, dies falsch zu verstehen. Es ist ratsam, Ihre Spielsimulation so zu strukturieren, dass dies minimiert wird. Ich bin wirklich kein Typ für Software-Designmuster, aber in diesem Fall ist es wahrscheinlich eine gute Idee - Sie könnten eine Art Muster in Betracht ziehen, bei dem die Spielsimulation wie eine sichere Box wirkt und der einzige Weg, den Spielstatus zu ändern, das Einfügen ist "Nachrichten" oder "Befehle", bei denen nur konstanten Zugriff auf Objekte außerhalb des Spielstatus gewährt wird (z. B. Rendern, Vernetzen usw.). Wenn Sie die Simulation für ein Multiplayer-Spiel vernetzen, müssen Sie diese Befehle über das Netzwerk senden, oder wenn Sie dieselbe Simulation wiederholen, müssen Sie den Befehlsstrom beim ersten Mal aufzeichnen.

Ich bin nicht sicher, ob dies die Art der Antwort ist, die Sie suchen, aber eine Alternative könnte sein, die Berechnungen auf einem zentralen Server auszuführen. Lassen Sie die Clients die Konfiguration an Ihren Server senden, die Simulation ausführen (oder eine zwischengespeicherte Konfiguration abrufen) und die Ergebnisse zurücksenden, die dann vom Client interpretiert und in Grafiken verarbeitet werden.

Dies schließt natürlich alle Pläne aus, die Sie möglicherweise haben, um den Client im Offlinemodus auszuführen, und je nachdem, wie rechenintensiv die Simulationen sind, benötigen Sie möglicherweise einen sehr leistungsstarken Server. Oder mehrere, aber dann haben Sie die Möglichkeit, sicherzustellen, dass sie dieselbe Hard- und Softwarekonfiguration haben. Eine Echtzeitsimulation mag schwierig, aber nicht unmöglich sein (denken Sie an Live-Videostreams - sie funktionieren, aber mit einer leichten Verzögerung).

Ich werde einen kontraintuitiven Vorschlag machen, der, obwohl er nicht 100% zuverlässig ist, die meiste Zeit gut funktionieren sollte und sehr einfach zu implementieren ist.

Präzision reduzieren.

Verwenden Sie eine festgelegte konstante Zeitschrittgröße, führen Sie die Physik über jeden Zeitschritt in einem standardmäßigen Gleitkomma mit doppelter Genauigkeit durch und quantisieren Sie dann die Auflösung aller Variablen nach jedem Schritt auf einfache Genauigkeit (oder etwas noch Schlimmeres). Dann werden die meisten möglichen Abweichungen, die durch die Gleitkomma-Neuordnung möglicherweise entstehen (im Vergleich zu einer Referenzfahrt desselben Programms), abgeschnitten, da diese Abweichungen in Ziffern auftreten, die in der reduzierten Genauigkeit nicht einmal vorhanden sind. Daher besteht für die Abweichung nicht die Möglichkeit eines Lyapunov-Aufbaus (Schmetterlingseffekt), der sich irgendwann bemerkbar machen würde.

Natürlich ist die Simulation etwas ungenauer als sie sein könnte (im Vergleich zur realen Physik), aber das ist nicht wirklich bemerkenswert, solange alle Ihre Programmläufe auf die gleiche Weise ungenau sind .

Technisch gesehen ist es natürlich möglich, dass eine Neuordnung zu einer Abweichung führt, die bis zu einer höherwertigen Ziffer reicht. Wenn die Abweichungen jedoch tatsächlich nur durch Schwebungen verursacht werden und Ihre Werte kontinuierliche physikalische Größen darstellen, ist dies äußerst unwahrscheinlich. Beachten Sie, dass es doublezwischen zwei Werten eine halbe Milliarde singlegibt, sodass erwartet werden kann, dass die meisten Zeitschritte in den meisten Simulationen zwischen den Simulationsläufen genau gleich sind. Die wenigen Fälle, in denen es eine Abweichung durch Quantisierung schafft, sind hoffentlich Simulationen, die nicht so lange dauern (zumindest nicht mit chaotischer Dynamik).

Ich würde Ihnen auch empfehlen, das Gegenteil von dem zu erwägen, wonach Sie fragen: Nehmen Sie die Unsicherheit in Kauf ! Wenn das Verhalten leicht nicht deterministisch ist, ist dies tatsächlich näher an tatsächlichen physikalischen Experimenten. Warum also nicht die Startparameter für jeden Simulationslauf absichtlich nach dem Zufallsprinzip ordnen und es zur Voraussetzung machen, dass die Simulation über mehrere Versuche hinweg durchgehend erfolgreich ist ? Das wird viel mehr über die Physik und darüber lehren, wie die Maschinen so konstruiert werden, dass sie robust / linear genug sind, anstatt überempfindliche Maschinen, die nur in einer Simulation realistisch sind.

Erstelle deine eigene Klasse zum Speichern von Zahlen!

Sie können ein deterministisches Verhalten erzwingen, wenn Sie genau wissen, wie die Berechnungen ausgeführt werden. Wenn Sie sich beispielsweise nur mit Multiplikation, Division, Addition und Subtraktion befassen, ist es ausreichend, alle Zahlen nur als rationale Zahl darzustellen. Zu diesem Zweck wäre eine einfache Rational-Klasse in Ordnung.

Wenn Sie sich jedoch mit komplizierteren Berechnungen befassen möchten (beispielsweise mit trigonometrischen Funktionen), müssen Sie solche Funktionen selbst schreiben. Wenn Sie in der Lage sein möchten, den Sinus einer Zahl zu nehmen, müssen Sie in der Lage sein, eine Funktion zu schreiben, die sich dem Sinus einer Zahl annähert, während Sie nur die oben genannten Operationen verwenden. Dies ist alles machbar, und meiner Meinung nach werden viele der haarigen Details in anderen Antworten umgangen. Der Nachteil ist, dass Sie sich stattdessen mit etwas Mathe auseinandersetzen müssen.

Hier gibt es einige terminologische Unklarheiten. Ein physikalisches System kann vollständig deterministisch sein, es kann jedoch nicht für einen nützlichen Zeitraum modelliert werden, da sein Verhalten gegenüber den Anfangsbedingungen äußerst empfindlich ist und eine geringfügige Änderung der Anfangsbedingungen zu völlig unterschiedlichen Verhaltensweisen führt.

Hier ist ein Video eines realen Geräts, dessen Verhalten absichtlich nicht vorhersehbar ist, außer im statistischen Sinne:

https://www.youtube.com/watch?v=EvHiee7gs9Y

Es ist einfach, einfache mathematische Systeme zu konstruieren (nur mit Addition und Multiplikation), bei denen das Ergebnis nach N Schritten von der N-ten Dezimalstelle der Startbedingungen abhängt. Es ist nahezu unmöglich, Software für die konsistente Modellierung eines solchen Systems auf jeder Computerhardware und -software zu schreiben - selbst wenn Sie ein ausreichendes Budget haben, um die Anwendung auf jeder wahrscheinlichen Kombination von Hardware und Software zu testen .

Der beste Weg, dies zu beheben, besteht darin, das Problem an der Quelle anzugreifen: Machen Sie die Physik Ihres Spiels so deterministisch, wie es sein muss, um reproduzierbare Ergebnisse zu erzielen.

Die Alternative besteht darin, zu versuchen, es deterministisch zu machen, indem die Computersoftware so angepasst wird, dass etwas modelliert wird, das nicht den Vorgaben der Physik entspricht. Das Problem ist, dass Sie im Vergleich zu einer expliziten Änderung der Physik mehrere Komplexitätsebenen in das System eingeführt haben.

Angenommen, Ihr Spiel beinhaltet Kollisionen der starren Körper. Selbst wenn Sie Reibung ignorieren, ist die exakte Modellierung von Kollisionen zwischen beliebig geformten Objekten, die sich möglicherweise drehen, während sie sich bewegen, in der Praxis unmöglich. Aber wenn Sie die Situation so ändern, dass die einzigen Objekte nicht rotierende rechteckige Steine ​​sind, wird das Leben sehr viel einfacher. Wenn die Objekte in Ihrem Spiel nicht wie Ziegel aussehen, verbergen Sie diese Tatsache mit einigen "nicht-physischen" Grafiken - zum Beispiel verstecken Sie buchstäblich den Moment der Kollision hinter Rauch oder Flammen oder einer Cartoon-Text-Blase "Autsch". oder Wasauchimmer.

Der Spieler muss die Spielphysik entdecken , indem er das Spiel spielt. Es spielt keine Rolle, ob es nicht "völlig realistisch" ist, solange es sich selbst widerspiegelt und der Erfahrung des gesunden Menschenverstands ähnlich genug ist, um plausibel zu sein.

Wenn Sie dafür sorgen, dass sich die Physik selbst stabil verhält, kann auch ein Computermodell stabile Ergebnisse liefern, zumindest in dem Sinne, dass Rundungsfehler irrelevant sind.

Verwenden Sie die doppelte Gleitkommapräzision anstelle der einfachen Gleitkommapräzision . Obwohl es nicht perfekt ist, ist es genau genug, um in Ihrer Physik als deterministisch angesehen zu werden. Sie können eine Rakete mit doppelter Gleitkommapräzision zum Mond schicken, aber nicht mit einfacher Gleitkommapräzision.

Wenn Sie wirklich perfekten Determinismus brauchen, verwenden Sie Festkomma-Mathematik . Dies führt zu einer geringeren Genauigkeit (vorausgesetzt, Sie verwenden die gleiche Anzahl von Bits), aber zu deterministischen Ergebnissen. Ich kenne keine Physik-Engines, die Festkomma-Mathematik verwenden, daher müssen Sie möglicherweise Ihre eigene schreiben, wenn Sie diesen Weg gehen möchten. (Etwas, von dem ich abraten würde.)

Verwenden Sie das Memento-Muster .

Speichern Sie in Ihrem ersten Lauf die Positionsdaten für jeden Frame oder die von Ihnen benötigten Benchmarks. Wenn dies zu unperformant ist, machen Sie es nur alle n Frames.

Folgen Sie dann beim Reproduzieren der Simulation der beliebigen Physik, aktualisieren Sie jedoch die Positionsdaten alle n Frames.

Übermäßig vereinfachter Pseudocode:

function Update():
    if(firstRun) then (SaveData(frame, position));
    else if(reproducedRun) then (this.position = GetData(frame));