マルチプレイヤーFPSサーバー側のパフォーマンス


12

これはMMOのパフォーマンスに関連していますが、質問は帯域幅に関するものです。これはCPUの負荷に関するものです。

node.jsとwebGLを使用して簡単なFPSを作成しました。これは非常にシンプルで、MIDI MazeのBuddyMazeクローンによく似ています。ほとんど何も起きていません。全員が2次元(高さなし)で動き、単純な発射体を発射し、壁にぶつかります。

今、サーバーに複数の接続を行い、すべてのプレイヤーが円を描くように高速で射撃する場合、サーバーがコアを使い果たして速度が低下する前に、ゲームで約15〜20人のプレイヤーを獲得できます。これは、サーバーで30 fpsで実行している場合です。10 fpsでは、約25-30の接続が得られます。これはかなり悪いことです。ゲームにはすぐにもっと多くのことが必要になるからです。これを実現するためには、より多くのプレイヤーにフィットさせる必要があります。

私の兄弟は、同僚のTF2サーバーに関する統計情報をいくつか指摘しました。彼のサーバーは私たちのサーバーよりもスペックが低いですが、TF2を実行します。明らかに毎秒500ティック、コアあたり36ユーザーという非常に複雑なゲームです。また、現在、使用する帯域幅よりもはるかに多くの帯域幅を消費していますが、それ以上下げることはまだ試みていません。

これはどのように可能ですか?サーバーのパフォーマンスをこの程度まで向上させるには、どのようなトリックがありますか?私が知っているいくつかのことは次のとおりです。

  • サーバーのフレームレートを下げ、クライアントの位置を補間します。いくつかの利点が得られましたが、明らかにTF2サーバーはこれを気にしません。
  • クライアントでの衝突検出などの高価なことを行い、サーバーで頻繁にそれを検証します。私はまだこれを引っ越していません、今夜にしましょう。それでも、私はそのような大きな利益を期待していません。
  • 計算を最小限に抑えるために、競技場を地域(四分木)に分けます。この機会はまだありません。
  • node.jsはTF2が使用しているものよりもかなり遅く、この種の高強度タスクには適さない可能性があるという残念な可能性を検討しました。
  • それはすべてサーバー構成の魔法ですか?

それでは、サーバー上で最低限必要なことだけを行いながら、完璧なゲーム体験を維持するための業界の他のトリックは何ですか?「CPU時間を節約するためにクライアントを延期する」と「クライアントを信頼しない」との間に大きな矛盾があります。

更新

プロファイリングは、私がこれまでに発見した唯一のマントラです。コードにいくつかのタイミング関数をすばやくラップし(ありがとう、FP!)、予期しないことを発見しました。データをクライアントにブロードキャストする行為は、実行時間のほぼすべてを占めています。具体的には、その約90%です。さらにテストを行ったところ、この時間はクライアントの数とデータのサイズの両方に依存していることが判明しましたが、データのサイズに大きく依存しています。ユーザー数が20人の場合、全データの代わりに「{}」のみを送信することで、ブロードキャスト時間を90%に24ミリ秒から2ミリ秒以上に短縮しました。ただし、ユーザーが5人のみの場合、ブロードキャストには約0.5ミリ秒かかります。したがって、ここでいくつかの最適化を行う必要があることは明らかです。

最初の最も明らかな改善点は、見通しの確認です。これにより、データを気にする人の数と、関係者に送信されるデータの量の両方が減少します。私が試すことができるこの分野には、ブロードキャスト操作のコストを最小限に抑えることに焦点を当てた他のトリックがありますか?


5
コードのプロファイルは、私が提案できるすべてです。私の推測では、あなたが考えるほど細かく調整されていないので、TF2が少ないハードウェアでより高いティックレートを実行しているのはそのためです。私はまた、TF2があなたが提案したすべてのことをしている可能性があり、その結果、パフォーマンスが高い理由に貢献していると思います。
ネイト

1
最新の結果を聞きたいのですが、node.jsからより良いパフォーマンスを得ることができましたか?
iddqd

回答:


5

サーバーは、ティックごとにすべてのプレーヤーの状態をすべてのプレーヤーに送信しないでください。代わりに、特別に細工されたメッセージを各クライアントに送信し、「ビューポート内のこれらのxプレーヤーはこれらの座標に500ミリ秒であるはずです」と500ミリ秒ごとに言う必要があります。ほとんどの場合、これは正常に機能しますが、サーバーが間違った情報を提供したことに気付いた場合、余分なメッセージを送信するだけです。

これにより、ネットワークトラフィックが大幅に減少します。

考慮すべきもう1つのことは、サーバーでゲームティックを使用せず、代わりにクライアントがアクションが発生したときにのみメッセージを送信し(方向の変更、発砲)、アクションを受信したときにサーバーで先に計算することです。


ええ、私は今、視線チェックを追加しています。実際には、25人のプレイヤーの45ミリ秒から35ミリ秒まで、ゲインは最小限でした。ただし、ブロードキャストの代わりに個別の送信コマンドを使用すると、余分なオーバーヘッドが発生する場合があります。そして、入力時にのみメッセージを送信します。しかし、あなたは正しいです、入力を受け取ったときだけ、まったくチェックする必要がない方法があるかもしれません。
テセレックス

1

node.jsはTF2が使用しているものよりもかなり遅く、この種の高強度タスクには適さない可能性があるという残念な可能性を検討しました。

おそらくこれでしょう。TF2のサーバーはC / C ++を使用して記述されているため、node.jsよりも高速になります(正しく覚えていればJavaで解釈されたJavascriptを使用しています)

GoogleのWebGLベースのQuakeはサーバーにjavaを使用しており、ソースコードはhttp://code.google.com/p/quake2-gwt-port/にあります。それを見て、それがどのように行われているかを見る価値があるかもしれません。また、サーバーでフレームレートを使用することについて話すとき、あなたは何を意味するのでしょうか。サーバー上で何かをレンダリングする理由はありません。クライアントから送信されたコマンドを処理するためだけにあるはずです。

最後に、「クライアントを信頼しない」というルールは、パフォーマンスの向上を期待して、高価な計算をクライアントにオフロードするよりも重要です。特に衝突検出と同じくらい重要なもの。ゲームがJavascriptベースであるため、ハッキングがかなり簡単な場合(コンパイルされるTF2のようなものと比較して)、二重にそうなります。

これはあまり答えではないことはわかっていますが、パフォーマンスの向上に役立つ可能性のあるいくつかの方向性を示してくれることを願っています。


7
フレームレートではなくティックレートを指定する必要があります。もちろん、サーバー上では何もレンダリングされません。ゲームループでコマンドを処理する間隔を意味します。また、いくつかの回答は、数秒ごとにランダムな検証を行う限り、衝突検出などをクライアントに提供できることを示唆しています。誰かがそれをだましてすぐに詐欺師を排除すると言いました。
テセレックス
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.