4

あなたが見た初心者の間違いとその治療法は何ですか?

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

例えば：

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

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

例えば

  • クライアント：ゲーム開始
  • クライアント: サーバーに接続します
  • クライアント: サーバーから利用可能な金額を照会します
  • ユーザー：お金を無限に設定するトレーナーを有効にします
  • クライアント: server.buyItem('非常に高価')
  • サーバー: ゲームの状態を確認します (ユーザーは今すぐアイテムを購入できます)。player[0].money をチェック -> ボーナスなし。
  • クライアント: 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(プレーヤー[0]、「お金」、プレーヤー[0].お金)。

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

4

3 に答える 3

6

間違いなく、クライアントの盲目的な信頼。私が取り組んでいるゲームでは、すべての「ビジネス ロジック」をサーバー側に保持し、クライアント マシンからは作成中のコマンドのみが送信されます。たとえば、「プレーヤー B は右に移動したい」としますが、サーバーは右にどれだけ移動したかを計算します。これにはパフォーマンスのオーバーヘッドがあります (そしてもちろん、より適切に処理できる遅延の問題もあります)。そのため、クライアント側で重い計算を実行し、サーバーでチェックを実行することが考えられる妥協点になる可能性があります。たとえば、更新間の時間内にクライアントのプレーヤーが想定以上に動いているかどうかを確認します。つまり、プレーヤーの最大速度が 200 ユニット/秒の場合、0.5 秒後に 150 ユニット移動したという更新を受け取った場合は、それらを起動します。

もちろん、これは誰かがボットをコーディングしてこれらのキー プレスを送信することを必ずしも阻止するものではないため、これを防ぐ方法は他にもあります。それでも、検証をまったく行わないことは、非常に初心者の間違いです（確かに、私が近道をしたときに罪を犯しました）

于 2009-03-06T00:37:51.113 に答える
6

Valve が (少なくとも、ある時点で) 取ったアプローチは、クライアントとサーバーが独立してゲームをシミュレートすることでした。次に、サーバーは信頼できるシミュレーションを実行し、すべてのクライアントにステータスの更新を送信して、ミスやハッキングの試みを修正します。

たとえば、左矢印を押すと、キャラクターはすぐに左に移動します。サーバーが「OK」と言うのを待つ必要はありません。ただし、壁をハッキングしたことが判明した場合、次のサーバーの更新では、サーバーが壁をしっかりと認識しているため、壁のすぐ隣に表示されます.

同様に、クライアントがキャラクターが前方に移動するのを見た場合、サーバーが正式な応答で戻ってくるまで、前方に移動し続けると想定します。

このアプローチは、サーバーが主要な決定を下す (そしてシミュレーションの過程でサニティ チェックを実行する) ときにハッキングの試みを打ち負かし、クライアントがサーバーから情報を得るまで予測を行う際のラグにも対処します。

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

于 2009-03-06T02:37:32.760 に答える
1

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

したがって、何がうまくいかないかを説明する代わりに、何がうまくいくかを見てください。

Valve はnetcodeに多くの労力を費やしました。それを読んでください

于 2009-03-06T02:00:13.443 に答える