TL;DR
- アンドロイド、ボードのようなゲーム。
- レイテンシは重要ではありません。
- LAN/グローバル経由のクライアントサーバー、高スコアの可能性 => 信頼なし。
- 将来の潜在的なBluetoothレイヤー=>完全な信頼。
- モバイルは高価なトラフィックを意味し、アップストリームはダウンストリームよりも高価です。
- PRNG はよく使用され、決定論的でなければなりません。
- シリアライズ+送信用kryonet
私と数人の仲間は、ボードゲームの「ポート」/「フレーバー」(多くの異なるイベントタイプとあらゆる種類の順列) を Android に構築し、ネットワーク化されたマルチプレイヤーの側面をそれに追加しています。私たちは暗号化やネットワークの専門家ではありません =)
ゲームのデフォルトのマルチプレイヤー レイヤーは、クライアント サーバー ベースになります (サーバーは専用ホストであるか、Android デバイス上で実行されます [友人と森の中でネットワークを持っていない場合に備えて])。これは、グローバル サーバーまたは LAN である可能性がありますが、それほど重要ではありません。ただし、チート防止メカニズムが必要な潜在的なハイスコアが存在する可能性があります。ターンベースのボードのようなゲームであるため、遅延は問題になりません。
将来、時間があれば、Bluetooth ベースのレイヤーを追加する可能性がありますが、この場合、人々はお互いをよく知っているという前提であるため、不正行為は問題ではありません。
アップストリームがダウンストリームよりも高価な (ほとんどの場合) モバイル ネットワークを扱っているため、サーバーからのダウンロードは、クライアントからモデルを送信するよりも安価です。
おそらく、データのシリアル化と送信に kryonet を使用することになるでしょう。
ゲームは PRNG を頻繁に使用するため、優れたアンチチートおよび検証ロジックが必要になるため、gamedev とスタック オーバーフローで多くの検索と読み取りを行った後、次のロジックを考案しました。計画がどれほど健全であるかについて、意見が必要です。すべてのヒントと推奨事項は大歓迎です。
仮定/考慮事項:
- PRNG は決定論的に動作します (Mersenne Twister を使用することを考えています)。
- 通常のゲーム プレイは、チート対策によってペナルティを受けるべきではありません。
スキーム/計画:
「ハンドシェイク」/「onResume()」以降の最初の接続時 - サーバーから PRNG シードを取得して保存します。各プレイヤーは、サーバーに独自のシードを持っています。
- また、同じリクエストでゲーム状態のハッシュをサーバーに送信し、同期していない場合はゲーム状態を同期します。
アクション/ユーザー入力で、次の乱数を取得します -> 「乱数のバケット」に保存します(したがってバケットと呼ばれます - バケットは「トラップされたリスト」であり、追加することはできますが、削除することはできません)。入力 ID/Type/Enum もリストに保存します。
他のプレイヤーが知る必要があるまで (つまり、次のプレイヤーのターン) / PNR (ポイント オブ ノー リターン) まで変更を蓄積します。
PNR到達
モデルの変更 ID/タイプ/列挙型 (約 64 ビット) + バケット + ハッシュ (変更後) を送信します。バケット + ハッシュを暗号化する必要があります。おそらく AES 256 (より適切な他の暗号化技術?) です。
N = size( bucket ) である N 個の連続する乱数に対してバケットをチェックします。一致しない場合は、6 に進み、次に 7 に進みます。
モデルを一時的に変更します (完全なゲーム モデルにコミットすることはありません)。
ハッシュを計算し、クライアント提供のハッシュと照合します。無効な場合は 6 に進みます。
有効: サーバー上のゲーム モデルにコミットします。
無効: サーバーから返された状態に戻すようにクライアントに依頼します。
チート: 禁止 (IP [動的 IP...] ではなく、MAC アドレスまたは UID ではありません) / いくつかのチートでゲームから削除します。
編集:また、アンチチートに関する別の質問... ボードのようなゲームで 2 つのファーミング ハイスコアのボット チームに対する対策の良いアイデアはありますか?
EDIT2:私が行った質問前の調査へのリンクは次のとおりです。
良いリンク (分散型のクライアント-クライアント プロトコル用): https://gamedev.stackexchange.com/questions/47145/peer-to-peer-hostless-competitive-games-of-chance
iPhone パズル ゲーム:シンプルなゲーム サーバーのコード例
調べてください:
5) ゲーム接続で軽量のポリモーフィック エンコーディングを使用します。
6) アンチデバッグ手法を使用して、デバッガーがプロセスにアタッチするのを防ぎます。Google のアンチデバッグと、多くのものを見つけることができるはずです。
7) カスタム独自の PE パッカーを使用して、ゲームの有用な分解を防ぎます。
8) ハッシュをプロミスとして使用し、他のプレイヤーの行動に関する条件が満たされると、ハッシュされたプロミスの意味を明らかにします。これは複雑で、パフォーマンスに影響を与えますが、いくつかのアイデアは、特にピア ツー ピア ゲームに役立つ場合があります。
9) クラッカーにとって問題をより困難にする良い方法は、サーバーにゲームの状態の信頼できる唯一のコピーを持ち、クライアントとの間で更新を送受信するだけで、通信プロトコル自体に埋め込むことができるようにすることだと思います。クライアントの検証 (クラッキングされていないため、検出ルールがまだ有効であること)。それと、発見された新しい奇妙な行動を積極的に監視することで、あなたがなりたい場所に近づくことができるかもしれません。
リアルタイム FPS 関連、私たちとの関連性は低い:
クライアント サーバー: (マルチプレイヤー) ゲームでチートを防ぐ方法は?
自動化: 自動化に対する保護
https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
- 優れたマルチプレイヤー/mmo クライアント <> サーバー ゲームは、移動計算でレイテンシーを使用しますか?
- タイムスタンプで場所の違いを検証するときにレイテンシの違いを考慮する方法 (アンチチート)?
以上です、何かヒントになれば幸いです!