私たちの（マルチプレイヤー）ゲームでの不正行為を防ぐ方法は？
あなたがゲームを書いているなら、あなたは詐欺師と彼らが不正行為をするのを防ぐ方法について考えるべきです。
Mmoマルチプレイヤーゲームだけでなく、シングルプレイヤーまたは「自家製」のp2pmpゲームもあると思います。
ゲームが完全にサーバークライアントアーキテクチャに基づいている場合、仕事はほぼ完了していると思いますが、ウォールハックなどもあります。
私は自分でp2pゲームを作りましたが、しばらくして詐欺師が現れました。彼らはチートエンジンを使用し、スピードハックとメモリハックを試したスクリプトキディだけでした。
ほとんどのspeedhacksはgettickcountをフックします。私は次の簡単なトリックでスピードハッカーを分類しました。 time()-GetTickCount()値を追跡しているだけで、違いが変わると不正行為が発生します。
メモリ破損は、ハッシュされたコピーをどこかに保持し、常に移動し、常にランダムな値で再ハッシュすることで解決できます。不一致はクラッシュを引き起こします。
Cheat Engineを整理するには、以下を確認してください。
if (OpenFileMapping(FILE_MAP_READ,false,'CEHYPERSCANSETTINGS')!=0)
{
// Cheat Engine runs.
}
（友人が私にこれを言った、私はまだそれをテストしていない。）
これらのトリックは、最も詐欺師を整理しました。しかしもちろん、もっと多くの不正行為のテクニックがあります。私はこのウィキを開いて、他の不正行為のテクニックとそれらを回避する方法について話し合いました。
シングルプレイヤーゲームでの不正行為をやめるために何もすべきではないと思います。ユーザーがゲームを購入した場合、他のユーザーと対戦していない限り、必要に応じてチートできるはずです。
これが私がしたいくつかのことです。これらは主にトーナメントゲームのアンチチートシステムのために行われ、そこではお金が危機に瀕しており、ユーザーのシステムへの特定のレベルの侵入は許容できると考えられています。ゲームが安定していないと、システムに問題が発生する可能性があるため、カジュアルゲームでこのようなことを行う場合は注意が必要です。
1）可能な場合は、「クライアントを信頼しない」が最も安全な原則です。サーバー上ですべてのアクションを実行し、クライアントがいつでも画面に表示できるはずのものをレンダリングするために必要な知識だけをクライアントに提供します。つまり、クライアントが壁の後ろに隠れているプレーヤーの位置を知らない場合、ウォールハックはユーザーに何の役にも立ちません。高速アクションゲームの場合、これは非常に難しい場合があります。特に、リアルタイムの影などが標準であり、プレーヤーの体が見えていてもユーザーが影を見ることができる必要がある場合は、常にそうする必要があります。オプションの上部にあります。また、ピアツーピアゲームで行うのは非常に困難ですが、ピア間の知識を制限する方法があります。パフォーマンスが法外になる場合、または時間/お金の予算を超えた場合にのみ、次の項目を検討する必要があります。
2）他のすべてのプロセスを開き、それらのWriteProcessMemory関数をフックして、ゲームのプロセスのメモリに書き込めないようにします。この1つのステップを正しく実行すると、すべてのチートとチートエンジンの90％がブロックされます。
3）さまざまなマウスとキーボードのエミュレーション機能をフックして、同じことを行います。これにより、多くのエイムボットやその他のタイプの自動化ボットを防ぐことができます。
4）ゲーム独自のプロセスのVirtualProtectEx/VirtualAllocEx/etc関数に接続し、どのモジュールが保護レベルを変更しているか、新しいメモリチャンクを割り当てているかを監視します。ゲームが多くの割り当てを行うときにCPUに過度の負荷がかかるのを防ぐために、これを巧妙にする必要がありますが、それは可能です。
5）LoadLibrary関数に接続し、動的にロードされているDLLを監視して、DLLインジェクションを防止します。
6）ゲーム接続で軽量のポリモーフィックエンコーディングを使用します。
7）いくつかのアンチデバッグ手法を使用して、デバッガーがプロセスに接続しないようにします。グーグルのアンチデバッグとあなたはたくさんのものを見つけることができるはずです。
8）カスタム独自のPEパッカーを使用して、ゲームの有用な分解を防ぎます。
9）透明度とアルファブレンディングを処理するOpenGLまたはDirect3Dの関数とメソッドに接続します。
10）シェーダーを使用している場合は、シェーダーとシェーダー定数値をチェックサムします。
11）プレイヤーキャラクターに追加のオクルージョンカリングテクニックを使用して、他のジオメトリによって視線が遮られたときにキャラクターがレンダリングされないようにします。それはあなたのパフォーマンスにも役立つかもしれないし、そうでないかもしれませんが、それは多くのウォールハックを防ぎます。
この論文は チートプルーフゲームプロトコル 興味深いものです。これらはすべて同じアイデアのバリエーションです。ハッシュをプロミスとして使用し、他のプレイヤーの行動の条件が満たされたときにハッシュされたプロミスの意味を明らかにします。これは複雑で、パフォーマンスに影響を与えますが、いくつかのアイデアは、特にピアツーピアゲームに役立つ場合があります。
ゲームが完全にサーバークライアントアーキテクチャに基づいている場合、仕事はほぼ完了していると思いますが、ウォールハックなどもあります。
ほとんどのロジックをサーバー側で実行するように移動できない場合は、少なくとも各ゲームプレイフェーズで現実的に可能な限り少ない状態を共有するようにしてください。言い換えると、各プレーヤーのアクティブなゲームモードを考慮に入れ、情報のみを共有します。その時点で実際に関連しています。
これにより、不正行為の可能性が減るだけでなく、プロトコルによって引き起こされるトラフィックも減ります。つまり、効率が向上します。
これは、大きな3Dシーンをレンダリングする際の効率を向上させるために、それ自体がゲーム/シミュレーション業界で長い間知られており、適用されてきた手法です。
そこでは、「錐台カリング」を使用して、シーンのどの部分が実際に表示されているかを判別し、関連する部分のみがレンダリングされるようにします。
同様に、同じ手法を使用して、マルチプレーヤークライアントが実際に関連している場合にのみ、特定の更新/情報を受信するように制限できます。他のクライアントが実際に "関連性の範囲"内にある場合、他のクライアントが対応する更新を取得できるようにします。
それでも、関連性と「可視性」を区別します。ドアで区切られた2人のプレーヤーは、実際にはお互いを「見る」ことはできませんが、周囲の状況によっては、お互いの声をよく聞くことができます。したがって、さまざまなタイプの「可視性」を区別します。可聴状態の伝播は、必ずしもゲーム座標でのプレーヤーの実際の位置の伝播を意味する必要はありません。同じことがその逆にも当てはまります。プレーヤーを「見る」という理由だけで、必ずしもクライアントの声を聞く資格があるとは限りません（たとえば、ライフルのスコープを想像してください）。
つまり、サポートする更新パケットを疎結合して、相互に依存関係がなく、独立して伝播/サブスクライブできるようにします。
不正行為は、適切なカプセル化とデータ隠蔽メカニズムを適用するだけで大部分を制御できるため、マルチプレーヤークライアントは通常、グローバル状態を共有しませんが、共有状態はプレーヤーのアクティブなコンテキスト（位置、進行方向、向き、速度など）に直接依存します。