7

「スーパー ミート ボーイ」は、最近 PC 向けに登場した難しいプラットフォーマーで、優れたコントロールとピクセル パーフェクトなジャンプが必要です。ゲーム内の物理コードはフレームレートに依存しており、フレームレートは 60fps に固定されています。これは、コンピューターがゲームをフルスピードで実行できない場合、物理学が異常になり、(とりわけ) キャラクターの実行が遅くなり、地面から落ちることを意味します。さらに、vsync がオフの場合、ゲームは非常に高速に実行されます。

2D ゲーム プログラミングの経験者は、ゲームがこのようにコーディングされた理由を説明できますか? 一定の速度で実行される物理ループは、より良い解決策ではないでしょうか? (実際には、一部のエンティティはフレームレートに関係なく正常に動き続けるため、ゲームの一部に物理ループが使用されていると思います。一方、あなたのキャラクターは正確に [fps/60] の速さで実行されます。)

この実装で気になるのは、モニター、グラフィック カード、CPU などのシステム固有のものに依存する、ゲーム エンジンとグラフィック レンダリングの間の抽象化が失われていることです。何らかの理由で、コンピューターが vsync を処理できない場合、または正確に 60 fps でゲームを実行できない場合、コンピューターは見事に壊れます。レンダリングステップが何らかの形で物理計算に影響を与えるのはなぜですか? (最近のほとんどのゲームは、ゲームを遅くするか、フレームをスキップします。) 一方、NES と SNES の古い学校のプラットフォーマーは、制御と物理の多くを固定フレームレートに依存していたことを理解しています。これはなぜですか? フレームレートに依存せずに、その流れでパトフォーマーを作成することは可能でしょうか? グラフィックス レンダリングをエンジンの残りの部分から切り離すと、必然的に精度が失われますか?

ありがとうございます。質問がわかりにくかったら申し訳ありません。

4

3 に答える 3

7

物理がフレームレートに依存する理由はなく、これは明らかに悪い設計です。

私はかつて、なぜ人々がこれを行うのかを理解しようとしました。社内の別のチームによって作成されたゲームのコード レビューを行いました。最初から見たわけではありませんが、コード内でハードコードされた 17 の値が多く使用されていました。FPS を表示してデバッグ モードでゲームを実行したところ、FPS はちょうど 17 でした。コードをもう一度見てみると明らかです。プログラマーは、ゲームが常に 17 FPS の固定フレーム レートであると想定していました。FPS が 17 より大きい場合、FPS がちょうど 17 になるようにスリープ状態になりました。もちろん、FPS が 17 より小さい場合は何もしませんでした。ゲーム、ゲーム システムは私に警告しました:「速すぎます!速すぎます!」)。

そこで、なぜこの値をハードコーディングして物理エンジンを使用するのかを尋ねるメールを書いたところ、この方法でエンジンをよりシンプルに保つことができると回答しました。そして、私はもう一度答えました。17 FPS に対応していないデバイスでゲームを実行すると、ゲーム エンジンは非常に面白く動作しますが、期待どおりには動作しません。そして彼らは、次のコードレビューまで問題を修正すると言いました。

3 ～ 4 週間後、ソース コードの新しいバージョンを入手したので、彼らが FPS 定数をどうしたか知りたいと思っていたので、最初に 17 以降のコードを検索しました。それらのうち、私が見たかったものではありませんでした:

最終的な静的 int FPS = 17;

そのため、すべてのコードからハードコードされた 17 値をすべて削除し、代わりに FPS 定数を使用しました。そして彼らの動機: 10 FPS しかできないデバイスにゲームを配置する必要がある場合、その FPS 定数を 10 に設定するだけで、ゲームはスムーズに動作します。

結論として、こんなに長いメッセージを書いて申し訳ありませんが、誰かがそのようなことをする唯一の理由は悪いデザインであることを強調したかった.

于 2010-12-27T20:41:33.840 に答える
2

タイムステップを一定に保つ必要がある理由についての良い説明があります: http://gafferongames.com/game-physics/fix-your-timestep/

また、物理エンジンによっては、タイムステップが変わるとシステムが不安定になる場合があります。これは、フレーム間でキャッシュされるデータの一部が時間ステップに依存するためです。たとえば、反復ソルバー (制約がどのように解決されるか) の最初の推測は、答えとはかけ離れている場合があります。これが Havok (多くの商用ゲームで使用されている物理エンジン) に当てはまることは知っていますが、SMB がどのエンジンを使用しているかはわかりません。

数か月前の Game Developer Magazine にも記事があり、初速度は同じだがタイムステップが異なるジャンプが、異なるフレームレートで異なる最大高さを達成する方法を示していました。ゲーム (Tony Hawk?) から、ゲームの NTSC バージョンで実行すると特定のジャンプを行うことができたが、PAL バージョンでは実行できなかった (フレームレートが異なるため) という裏話がありました。申し訳ありませんが、現時点では問題を見つけることができませんが、必要に応じて後で掘り下げることができます。

于 2010-12-28T00:00:43.557 に答える
0

彼らはおそらく、ゲームを十分に迅速に完成させる必要があり、現在の実装で十分なユーザーベースをカバーできると判断しました.

さて、開発中に考えてみれば、独立性を後付けすることはそれほど難しいことではありませんが、いくつかの急な穴を下る可能性があると思います.

これは不要だと思いますし、以前にも見たことがあります (いくつかの初期の 3d-hw ゲームでは、空を見るとゲームが速くなり、地面を見ると遅くなるという同じことを使用していました)。

それはただひどいです。それについて開発者にバグを報告し、可能であればパッチを当てることを望みます。

于 2010-12-27T20:40:55.650 に答える