決定論的な物理シミュレーションを実行するにはどうすればよいですか？

私は、プレイヤーがパズルやマップを解くためにピースやパーツを動かす剛体を含む物理ゲームを作成しています。ゲームの非常に重要な側面は、プレイヤーがシミュレーションを開始すると、オペレーティングシステム、プロセッサなどに関係なく、どこでも同じように実行されることです。

多くの複雑さの余地があり、シミュレーションが長時間実行される可能性があるため、物理エンジンがその浮動小数点演算に関して完全に決定的であることが重要です。別の「失敗」。

ゲームでこの決定論を実現するにはどうすればよいですか？Javascript、C ++、Java、Python、C＃など、さまざまなフレームワークと言語を使用したいと思っています。

Box2D（C ++）と他の言語の同等物に惹かれましたが、それは私のニーズを満たすようですが、特に三角関数の場合、浮動小数点の決定論に欠けています。

私が今まで見た中で最良の選択肢は、Box2DのJava同等物（JBox2D）です。多くの操作でStrictMathはなく浮動小数点の決定論を試みているMathようですが、ゲームをまだ作成していないので、このエンジンが必要なすべてを保証するかどうかは不明です。

ニーズに合わせて既存のエンジンを使用または変更することはできますか？または、自分でエンジンを構築する必要がありますか？

編集：誰かがそのような精度を必要とする理由を気にしない場合は、この投稿の残りをスキップしてください。コメントと回答の個人は、私がすべきでないことを求めていると信じているようです。そのため、ゲームがどのように機能するかについてさらに説明します。

プレーヤーには、障害物と目標が含まれるパズルまたはレベルが与えられます。最初は、シミュレーションは実行されていません。その後、提供されたピースまたはツールを使用してマシンを構築できます。スタートを押すと、シミュレーションが開始され、マシンを編集できなくなります。マシンがマップを解決した場合、プレイヤーはレベルをクリアしています。それ以外の場合は、停止ボタンを押してマシンを変更し、再試行する必要があります。

すべてを決定論的にする必要がある理由は、各ピースの位置、サイズ、回転を記録することにより、すべてのマシン（レベルを解決しようとするピースとツールのセット）をxmlファイルまたはjsonファイルにマッピングするコードを作成するためです。その後、プレイヤーはソルブ（これらのファイルで表されます）を共有して、ソルブの検証、相互の学習、競技会の開催、コラボレーションなどを行えるようになります。もちろん、ほとんどのソルブ、特にシンプルまたはクイック決定論の欠如の影響を受けません。しかし、本当に難しいレベルを解決する低速または複雑な設計は、おそらく最も興味深いものであり、共有する価値があると思われる設計です。

決定論的な方法での浮動小数点数の処理について

浮動小数点は決定的です。まあ、あるべきです。それは複雑です。

浮動小数点数に関する多くの文献があります。

• すべてのコンピューター科学者が浮動小数点演算について知っておくべきこと
• 浮動小数点演算用の新しいIEEE-754標準
• IEEE 754-2008リビジョン

そして、それらがどのように問題があるのか​​：

• 浮動小数点の結果の一貫性、またはアプリケーションが常に同じ答えを返さないのはなぜですか？。
• C ++の浮動小数点演算に関するクロスプラットフォームの問題。
• 浮動小数点計算の検証の落とし穴。
• 浮動小数点演算は決定論的ですか？。
• 決定論的プロセスが浮動小数点エラーを生成する原因となるもの。
• 一貫性：IEEE浮動小数点の目的を無効にする方法。

抽象的に。少なくとも、単一のスレッドでは、同じ操作が同じデータで行われ、同じ順序で発生するため、確定的である必要があります。したがって、入力を心配して、順序を変更することから始めることができます。

問題を引き起こすこのような入力の1つは時間です。

まず、常に同じタイムステップを計算する必要があります。時間を測定しないと言っているのではなく、時間の変動がシミュレーションのノイズの原因であるため、物理シミュレーションに時間を渡さないと言っています。

物理シミュレーションに渡さないのに、なぜ時間を測定するのですか？シミュレーションステップをいつ呼び出すべきかを知るために経過時間を測定し、スリープを使用していると仮定して、スリープ時間を測定します。

副<文>この[前述の事実の]結果として、それ故に、従って、だから◆【同】consequently; therefore <文>このような方法で、このようにして、こんなふうに、上に述べたように◆【同】in this manner <文>そのような程度まで<文> AひいてはB◆【用法】A and thus B <文>例えば◆【同】for example; as an example：

• 時間を測定：はい
• シミュレーションで時間を使用：いいえ

さて、命令の並べ替え。

コンパイラf * a + bは、それがと同じであると判断するb + f * a可能性がありますが、結果が異なる場合があります。また、fmaddにコンパイルすることもできますし、一緒に発生するそのような複数の行を取得してSIMDで記述することもできます。また、同じ操作を同じ順序で実行したいので、どの操作が実行されるかを制御したいのは当然です。

いいえ、doubleを使用しても節約にはなりません。

特に、ネットワーク全体で浮動小数点数を同期するには、コンパイラとその構成について心配する必要があります。同じことをすることに同意するビルドを取得する必要があります。

おそらく、アセンブリを記述することが理想的です。そのようにして、どの操作を行うかを決定します。ただし、複数のプラットフォームをサポートするには問題になる可能性があります。

副<文>この[前述の事実の]結果として、それ故に、従って、だから◆【同】consequently; therefore <文>このような方法で、このようにして、こんなふうに、上に述べたように◆【同】in this manner <文>そのような程度まで<文> AひいてはB◆【用法】A and thus B <文>例えば◆【同】for example; as an example：

• Ern ...うーん... 浮動小数点数の処理方法を設定できるコンパイラを使用します。たとえば、/ fp（浮動小数点の動作を指定）を 参照してください。

固定小数点数の場合

メモリでの浮動小数点の表現方法により、大きな値は精度を失います。値を小さく保つ（クランプする）ことで問題が軽減されるのは理にかなっています。したがって、大きな速度と大きな部屋はありません。これは、トンネリングのリスクが少ないため、個別の物理を使用できることも意味します。

一方、小さなエラーは累積します。だから、切り捨てます。つまり、スケーリングして整数型にキャストします。そうすれば、何も構築されていないことがわかります。整数型にとどまることができる操作があります。浮動小数点に戻る必要があるときは、スケーリングをキャストして元に戻します。

スケールと言います。アイデアは、1ユニットが実際には2の累乗（たとえば16384）として表されるということです。それが何であれ、それを定数にして使用します。基本的に固定小数点数として使用しています。実際、信頼できるライブラリの適切な固定小数点数をはるかにうまく使用できる場合。

私は切り捨てと言っています。丸めの問題については、キャスト後に取得した値の最後のビットを信頼できないことを意味します。したがって、キャストスケールの前に、必要以上に1つ多くを取得し、後でそれを切り捨てます。

副<文>この[前述の事実の]結果として、それ故に、従って、だから◆【同】consequently; therefore <文>このような方法で、このようにして、こんなふうに、上に述べたように◆【同】in this manner <文>そのような程度まで<文> AひいてはB◆【用法】A and thus B <文>例えば◆【同】for example; as an example：

• 値を小さく保つ：はい
• 慎重な丸め：はい
• 可能な場合は固定小数点数：はい

待って、なぜ浮動小数点が必要なのですか？整数型だけで作業することはできませんか？ああ、そう。三角法と放射。三角法と放射のテーブルを計算し、ソースに焼き付けることができます。または、代わりに固定小数点数を使用する場合を除き、浮動小数点数を使用してそれらを計算するために使用されるアルゴリズムを実装できます。はい、メモリ、パフォーマンス、精度のバランスを取る必要があります。それでも、浮動小数点数を避けて、決定論的であり続けることができます。

オリジナルのPlayStationでそのようなことを行ったことをご存知ですか 私の犬に会ってください、パッチ。

ところで、グラフィックに浮動小数点を使用しないと言っているのではありません。物理学のためだけに。確かに、位置は物理学に依存します。ただし、ご存じのとおり、コライダーはモデルと一致する必要はありません。モデルの切り捨ての結果を見たくありません。

したがって、固定小数点数を使用します。

明確にするために、浮動小数点の動作を指定できるコンパイラを使用でき、それで十分であれば、それを実行できます。それは常にオプションではありません。また、決定論のためにこれを行っています。固定小数点数は、精度に制限があるため、エラーがないという意味ではありません。

「固定小数点数が難しい」ことは、それらを使用しない正当な理由だとは思いません。そして、それらを使用する正当な理由が必要な場合、それは決定論、特にプラットフォーム間の決定論です。

こちらもご覧ください：

• モバイルデバイスの3Dグラフィックス-パート2：固定小数点演算
• 固定小数点演算の軽視された技術
• CORDICアルゴリズムシミュレーションコード

補遺：世界のサイズを小さく保つことを提案しています。そうは言っても、OPとJibb Smartの両方は、原点フロートから離れると精度が低下するという点を示します。それは物理学に影響を与え、世界の端よりもはるかに早く見られるでしょう。固定小数点数は、精度が固定されており、どこでも同じように優れています（必要に応じて、悪い場合もあります）。決定論が必要な場合、これは良いことです。また、私たちが通常物理学を行う方法には、小さな変動を増幅する性質があることにも言及したいと思います。バタフライエフェクト-信じられないほどの機械とからくりメーカーの決定論的物理学を参照してください。

物理学を行う別の方法

私は、浮動小数点数の精度の小さな誤差が増幅する理由は、私たちがそれらの数で反復を行っているためだと考えてきました。各シミュレーションステップでは、最後のシミュレーションステップの結果を取得し、それらの処理を行います。エラーの上にエラーを蓄積する。それがあなたのバタフライ効果です。

同じマシンで単一のスレッドを使用する単一のビルドが、同じ入力によって異なる出力を生成するとは思わない。しかし、別のマシンで、または異なるビルドで可能です。

そこでテストするための議論があります。物事がどのように機能するかを正確に決定し、ターゲットハードウェアでテストできる場合、異なる動作をするビルドを出すべきではありません。

ただし、多くのエラーを蓄積する離れて作業しないことについての議論もあります。おそらくこれは、異なる方法で物理学を行う機会です。

ご存知かもしれませんが、連続物理学と離散物理学があり、どちらも各オブジェクトがタイムステップでどれだけ進むかについて機能します。ただし、連続物理学には、さまざまな可能性のある瞬間を調べて衝突が発生したかどうかを調べるのではなく、衝突の瞬間を把握する手段があります。

したがって、私は次のことを提案しています。連続物理学の手法を使用して、各オブジェクトの次の衝突がいつ発生するかを把握します。次に、最も近い衝突の瞬間を取り、その瞬間にすべてがどこにあるかを把握します。

はい、それは単一のシミュレーションステップの多くの仕事です。つまり、シミュレーションはすぐには開始されません...

...ただし、次の衝突がいつ発生するか（または大きなタイムステップで衝突が発生しないこと）がすでにわかっているため、衝突を毎回確認することなく、次のいくつかのシミュレーションステップをシミュレートできます。さらに、シミュレーションが大きなタイムステップに達すると、事前に計算した位置を配置するだけなので、そのシミュレーションで蓄積されたエラーは無関係です。

これで、各シミュレーションステップで衝突をチェックするために使用していた時間バジェットを使用して、見つかった次の衝突を計算できます。つまり、大きなタイムステップを使用して、先にシミュレーションを行うことができます。世界の範囲が制限されていると仮定すると（これは巨大なゲームでは機能しません）、シミュレーションの将来の状態のキューがあり、最後の状態から次の状態に補間する各フレームが必要です。

補間について議論します。ただし、加速があるため、すべてを同じ方法で単純に補間することはできません。代わりに、各オブジェクトの加速度を考慮して補間する必要があります。その点については、大きなタイムステップの場合と同じ方法で位置を更新できます（つまり、同じ動きに対して2つの異なる実装を使用しないため、エラーが発生しにくくなります）。

注：この浮動小数点数を使用している場合、このアプローチでは、オブジェクトが原点から離れるにつれて異なる動作をするという問題は解決しません。ただし、原点から遠ざかるほど精度が失われるのは事実ですが、それでも決定論的です。実際、それが元々それを持ち出さなかった理由です。

補遺

コメントの OPから：

アイデアは、プレイヤーがマシンを何らかの形式（xmlやjsonなど）で保存できるようにして、各ピースの位置と回転が記録されるようにすることです。そのxmlまたはjsonファイルは、別のプレーヤーのコンピューターでマシンを再現するために使用されます。

だから、バイナリ形式はありませんか？つまり、復元された浮動小数点数が元のものと一致するかどうかを心配する必要もあります。参照：フロート精度の再検討：9桁のフロートの移植性

私はあるよく知られているリアルタイム戦略ゲームを作っている会社で働いており、浮動小数点の決定論が可能であることを伝えることができます。

異なるコンパイラー、異なるコンパイラーを使用した同じコンパイラー、または同じコンパイラーの異なるバージョンを使用すると、すべて決定論が破綻する可能性があります。

プラットフォーム間またはゲームバージョン間でクロスプレイが必要な場合、固定小数点にする必要があると思います-浮動小数点で認識している唯一の可能なクロスプレイはPCとXBox1の間ですが、それはかなりおかしいです。

完全に決定論的な物理エンジンを見つけるか、オープンソースエンジンを使用して決定論的にするか、独自のエンジンをロールする必要があります。私は頭の中で、すべての統一が決定論的な物理エンジンを追加したと感じていますが、それが同じマシンで決定論的であるか、すべてのマシンで決定論的であるかはわかりません。

あなたが自分のものをロールバックしようとするなら、助けることができるいくつかの事柄：

• IEE754フロートは、フルーティーなものを何もしていない場合、確定的です（Googleの「IEE754確定論」を参照してください）。
• すべてのクライアントの丸めモードと精度が同じに設定されていることを確認する必要があります（controlfpを使用して設定します）
• 丸めモードと精度は特定の数学ライブラリによって変更できるため、閉じたライブラリを使用している場合は、呼び出し後にこれらをチェックすることをお勧めします（再度controlfpを使用してチェックします）
• 一部のSIMD命令は確定的ですが、多くはそうではありません。注意してください
• 前述のように、決定性を保証するには、同じプラットフォーム、同じコンパイラの同じ正確なバージョン、同じ構成をコンパイルし、同じコンパイラ設定も必要です
• いくつかのツールを組み込み、状態の非同期を検出し、それらの診断を支援します。たとえば、フレームごとにゲームの状態をCRCし、非同期が発生したことを検出します。次に、互いに非同期のシミュレーションから2つのファイルを取得し、diffツールで比較して、どこが間違っているかを確認します。
• 非同期の主な原因であるゲーム状態のすべての変数を初期化する
• 非同期を回避するために、ゲームシミュレーション全体を毎回正確に同じ順序で行う必要があります。これは非常に簡単に間違えるため、これを最小限に抑えるようにゲームシミュレーションを構築することをお勧めします。私は本当にソフトウェア設計パターンの男ではありませんが、この場合にはおそらく良いアイデアです-ゲームのシミュレーションが安全なボックスのようなもので、ゲームの状態を変更する唯一の方法は挿入することです「メッセージ」または「コマンド」。ゲーム状態以外のあらゆるもの（レンダリング、ネットワーキングなど）に対してconstアクセスのみが提供されます。したがって、マルチプレイヤーゲームのシミュレーションをネットワーク化するのは、これらのコマンドをネットワーク経由で送信する場合、または同じシミュレーションを再生する場合は、コマンドストリームを初めて記録する場合、

これがあなたが探している答えのタイプであるかどうかはわかりませんが、代替策は中央サーバーで計算を実行することです。クライアントに構成をサーバーに送信し、シミュレーションを実行させ（またはキャッシュされたものを取得させ）、結果を送り返します。結果はクライアントによって解釈され、グラフィックに処理されます。

もちろん、これにより、クライアントをオフラインモードで実行するために必要な計画がすべて遮断されます。また、シミュレーションの計算集約度によっては、非常に強力なサーバーが必要になる場合があります。または、複数ありますが、少なくとも、ハード構成とソフトウェア構成が同じであることを確認するオプションがあります。リアルタイムシミュレーションは難しいかもしれませんが、不可能ではありません（ライブビデオストリームを考えてください-動作しますが、わずかな遅延があります）。

100％の信頼性はありませんが、ほとんどの場合正常に動作し、実装は非常に簡単であるという直感に反する提案をします。

精度を下げます。

あらかじめ決められた一定の時間ステップサイズを使用し、標準の倍精度浮動小数点数で各時間ステップにわたって物理学を実行しますが、各ステップの後にすべての変数の分解能を単精度（またはさらに悪いもの）に量子化します。次に、浮動小数点の並べ替えによって生じる可能性のある偏差のほとんどは（同じプログラムの参照実行と比較して）削減されます。これらの偏差は、精度が低下しても存在しない桁で発生するためです。したがって、逸脱は、最終的に注目されるリアプノフ蓄積（バタフライ効果）の機会を得ることはありません。

もちろん、シミュレーションは実際の物理と比べてわずかに正確ではありませんが、すべてのプログラムの実行が同じように不正確である限り、それはあまり注目に値しません。

現在、技術的に言えば、並べ替えにより上位の桁に達する偏差が生じる可能性はもちろんありますが、偏差が実際に浮動小数点のみであり、値が連続的な物理量を表している場合、これはほとんどありません。double任意の2つの値の間に5億の値があるsingleため、ほとんどのシミュレーションのタイムステップの大部分は、シミュレーション実行間でまったく同じであると予想されることに注意してください。偏差が量子化を介して行われるいくつかのケースは、それほど長くは実行されない（少なくともカオスダイナミクスではない）シミュレーションであることが望ましいでしょう。

また、あなたが尋ねているものとは完全に反対のアプローチを検討することをお勧めします：不確実性を受け入れる！動作がわずかに非決定的である場合、これは実際の物理実験に実際により近くなります。それでは、各シミュレーション実行の開始パラメータを故意にランダム化し、複数の試行にわたってシミュレーションが一貫して成功することを要件にしないのはなぜですか？これは、シミュレーションでのみ現実的である非常に壊れやすい機械ではなく、物理学、およびマシンを十分に堅牢/線形になるように設計する方法についてより多くを学びます。

数字を保存するための独自のクラスを作成してください！

計算の実行方法を正確に知っている場合、決定論的な動作を強制できます。たとえば、扱う演算が乗算、除算、加算、減算だけである場合、すべての数値を単なる有理数として表すだけで十分です。これを行うには、単純なRationalクラスで十分です。

ただし、より複雑な計算（たとえば、三角関数など）を処理する場合は、そのような関数を自分で作成する必要があります。数値のサインを取得できるようにするには、上記の操作のみを使用して、数値のサインに近似する関数を記述できる必要があります。これはすべて実行可能であり、私の意見では、他の答えの毛深い詳細の多くを回避します。トレードオフは、代わりにいくつかの数学を処理する必要があるということです。

ここで用語の混乱があります。物理システムは完全に決定論的ですが、その動作は初期条件に非常に敏感であるため、有用な期間のモデル化は不可能であり、初期条件のわずかな変化でもまったく異なる動作が発生します。

これは、統計的な意味を除き、動作が意図的に予測できない実際のデバイスのビデオです。

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

Nステップ後の結果が開始条件のN番目の小数位に依存する単純な数学システムを簡単に構築できます（加算と乗算のみを使用）。一貫してこのようなシステムをモデル化するためのソフトウェアを書く、上の任意のユーザーが持つかもしれないコンピュータのハードウェアとソフトウェア、近い不可能にある-あなたは十分に大きな予算を持っている場合でも、テストのハードウェアおよびソフトウェアのすべての可能性の高い組み合わせでアプリケーションを。

これを修正する最良の方法は、問題をその発生源で攻撃することです。再現可能な結果を​​得るために、ゲームの物理を必要に応じて決定論的にします。

別の方法は、物理学が指定したものではないものをモデル化するためにコンピューターソフトウェアを微調整することにより、それを決定論的にしようとすることです。問題は、物理を明示的に変更する場合と比較して、システムにさらにいくつかの複雑なレイヤーを導入していることです。

具体的な例として、ゲームに剛体の衝突が含まれると仮定します。摩擦を無視しても、動きながら回転する可能性のある任意の形状のオブジェクト間の衝突の正確なモデリングは、実際には不可能です。しかし、状況を変えて、唯一のオブジェクトが回転しない長方形のレンガになるようにすると、生活は非常に簡単になります。ゲーム内のオブジェクトがレンガのように見えない場合は、いくつかの「非物理的」グラフィックスでその事実を隠します。たとえば、文字通り、煙や炎の背後にある衝突の瞬間を隠します。または何でも。

プレイヤーは、ゲームをプレイしてゲームの物理を発見する必要があります。自己一貫性があり、常識的な経験にもっともらしく似ている限り、「完全に現実的」でなくてもかまいません。

物理学自体を安定した方法で動作させる場合、少なくとも丸め誤差が無関係であるという意味で、物理学のコンピューターモデルも安定した結果を生成できます。

使用倍精度浮動小数点精度を代わりに、単一の浮動小数点精度。完全ではありませんが、物理学で決定論的と見なされるほど十分に正確です。単精度浮動小数点精度ではなく、倍精度浮動小数点精度でロケットを月に送ることができます。

完全な決定論が本当に必要な場合は、固定小数点演算を使用します。これにより、精度は低下しますが（同じビット数を使用すると仮定）、確定的な結果が得られます。固定小数点演算を使用する物理エンジンを認識していないため、このルートを使用する場合は独自の記述が必要になる場合があります。（私がアドバイスする何か。）

Mementoパターンを使用します。

最初の実行では、フレームごとに位置データを保存するか、必要なベンチマークを保存します。それがあまりにもパフォーマンスが悪い場合は、nフレームごとに実行してください。

次に、シミュレーションを再現するときに、任意の物理学に従いますが、nフレームごとに位置データを更新します。

過度に単純化された擬似コード：

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