マルチプレイヤー/オンラインゲームプログラミングで最もよく見られる初心者の間違いですか？

Question

これまでに見た初心者のミスの種類とその解決策は何ですか？

何度も発生するのは、クライアントがサーバーに対してチェックされないことです。

例：

• ユーザーはフラッシュゲームソースを逆コンパイルするか、ネットワークトラフィックをリッスンし、ハイスコアデータの行き先を確認し、ゲームをプレイしていなくても偽のハイスコアを送信します。
• ユーザーはトレーナーを使用して、現在のレベルには表示されないアイテムを取得します。 「クライアントXがアイテムYを取得しました」などのサーバーに送信されたサーバーはそれを受け入れます。

単純な解決策は、もちろんゲームクライアントをサーバーのAPIとしてのみ処理することです。その後、ユーザーは好きなだけトレーナーやその他のメモリ操作を使用できますが、サーバーはあなたにはできないと言っています。サーバーは、ゲームルールを上に置いてクエリを実行できるデータベースと考えてください。

たとえば

• クライアント：ゲームを開始します
• クライアント：サーバーに接続します
• クライアント：サーバーから利用可能な金額を照会します
• ユーザー：お金を無限に設定するトレーナーを有効にします
• クライアント：server.buyItem（ 'very高価'）
• サーバー：ゲームの状態を確認します（ユーザーは今すぐ購入できます）。 player [0] .moneyをチェックします-＆gt;ボーナスなし。
• クライアント：server.buyItem（ 'can get this'）
• サーバー：ゲームの状態を確認します（ユーザーは今すぐ購入できます）。 player [0] .moneyをチェックします。 player [0] .items.add（ 'can get this'）これにより、player [0] .moneyからのコストが削減されます。次に、クライアントにsend（player [0]、 'items'、 'can get this'）; send（player [0]、 'money'、player [0] .money）。

もう1つの方法は、クライアントの動きを記録し、それをサーバーが再生するハイスコアサーバーに送信することです。もちろん、これはそのレコードが非常に大きいことにつながる可能性があります。

Answer 1

疑いもなく、クライアントの盲目的な信頼。私が取り組んでいるゲームでは、すべての「ビジネスロジック」を保持しています。サーバー側で、クライアントマシンが送信するコマンドのみを送信するようにします。たとえば、「プレイヤーBが右に移動したい」などです。 -しかし、サーバーは移動した距離を計算します。これにはパフォーマンスのオーバーヘッドがあり（そしてもちろん、より良い処理が可能な遅延の問題もあります）、可能な中間点は、クライアント側で重い計算を行うことであり、それでもサーバー上にチェックがあります。たとえば、クライアントのプレーヤーが、更新と更新の間に想定される以上に移動しているかどうかをチェックしますつまり、プレーヤーの最大速度が200ユニット/秒の場合、0.5秒後に150ユニット移動したという更新が表示されたら、それらを起動します。

もちろん、これは必ずしも誰かがボットをコーディングしてそれらのキー押下を送信するのを止めるわけではないので、これを防ぐ他の方法があります。それでも、検証がまったくないというのは初心者の間違いです（ショートカットを作成したときは間違いなく罪を犯しました）

Answer 2

Valveが取ったアプローチ（少なくとも、ある時点で）は、クライアントとサーバーにゲームを個別にシミュレートさせることでした。その後、サーバーは信頼性の高いシミュレーションを実行し、すべてのクライアントにステータスの更新を送信して、ミス/ハッキングの試みを修正します。

E.g。左矢印を押すと、キャラクターはすぐに左に移動します。サーバーが「OK」と言うのを待つ必要はありません。しかし、壁をハックしたことが判明した場合、次のサーバーの更新により、壁のすぐ隣に表示されます。サーバーはそれを堅実なものと見なします。

同様に、クライアントがキャラクターが前方に移動するのを見ると、サーバーが信頼できる応答を返すまで、前方に移動し続けると仮定します。

このアプローチは、サーバーが主要な決定を下す（およびシミュレーションの過程で健全性チェックを実行する）ため、ハッキングの試みを無効にし、クライアントがサーバーから情報を得るまで予測を行う際の遅延にも対処します。

「クライアントの信頼」に関連するもう1つの大きな間違いは、ネットワークプロトコルを偽造できないと考えていることです。バイナリチャンクをサーバーに送信する場合、これらのバイナリチャンクはリバースエンジニアリングされず、何が起こるかを確認するためにデータを混乱させようとしないと想定される傾向があります。これにより、あらゆる種類の問題が発生しています。

Answer 3

サーバーを信頼するクライアントで問題が発生する可能性のあるすべてのことを、皆さんがほぼカバーしています。他に考えられる問題はありません。

したがって、何がうまくいかないかを伝えるのではなく、何がうまくいくかを見てください。

Valveは、 netcode 。読んでください