ネットワークゲームで堅牢な方法でエンティティIDを割り当てるにはどうすればよいですか？

ネットワークゲームのエンティティシステムに取り組んでおり、各エンティティに一意の32ビット整数IDを割り当てています。このIDを使用して、エンティティおよびエンティティ自体への参照をシリアル化できます。

現在、エンティティが作成されるたびにカウンターをインクリメントしています。IDが最終的に使い果たされると思いますが、40億のエンティティがあるとは本当に思っていません。また、これにより、エンティティ＃5が破棄され、IDが5になった場合に問題が回避されます。新しい＃5を参照するのか、古い＃5を参照するのですか？

問題は、衝突の処理/回避方法がわからないことです。現在、クライアントが現在の「フリーID」よりも高いIDを持つエンティティの更新を受け取ると、それまでのフリーIDにぶつかります。しかし、それはあまり堅牢ではないようです。

競合することなくエンティティを割り当てることができるように各クライアントに範囲を割り当てることを考えました（上位nビットはプレーヤー番号です）が、範囲が時間とともに重複し始めた場合にどうなるか心配です。

これを処理するより良い方法はありますか？idがオーバーフローしたり、許可された範囲の終わりを超えたりすることさえ気にする必要がありますか？これらのケースを検出するコードを追加できますが、クラッシュ以外の事態が発生した場合はどうなりますか。

もう1つのオプションは、128ビットGUIDのように一意である可能性が高いものを使用することですが、ネットワークトラフィックを最小限に抑えようとしているゲームにとっては非常に重いようです。また、現実的には、32ビットまたは24ビットの整数に収まるエンティティが一度に必要になることはありません。

ありがとう！

私がやったことは、サーバーにすべてをさせることです。クライアントは単にサーバーに何かをするように要求できますが、自分で何もすることはできません。この場合、サーバーは常にIDを割り当て、問題を解決します。

サーバーが「ロケットを撃つ」や「ここにソーラーステーションを作る」などのアクションを承認するのを待つ間、クライアント側の予測に対処していません。これらのアクションはエンティティを作成する必要があり、エンティティにはIDがあります。これまでのところ、私は親指でサーバーを待っていますが、サーバーの承認を待つ間に一時的なエンティティを作成する必要があると考えています。サーバーの承認を受け取ると、サーバーはIDを割り当て、一時オブジェクトを更新または上書きできます。

IDのオーバーフローも処理していませんが、サーバーがフルコントロールでオーバーフローを検出した場合、必要と思われる処理（0から再開、空きスタックから選択、クラッシュなど）を実行できます。クライアントは知りませんし、気にしません。クライアントは、サーバーから渡されたIDを受け入れるだけです。

商用のマルチプレイヤーゲームでこれを行ったとき、私はあなたが提案したとおりに行いました。32ビットGUID整数を使用します。上位8ビットはプレーヤー番号で、下位24ビットにはローカルで一意の番号が含まれます。

ローカル番号がオーバーフローした場合（私の場合、ほとんど発生しません。通常の使用では、単一のネットワークセッションで4〜5日間連続して再生すると、発生します）、所有者は「すべてのオブジェクトのリセット」メッセージ、およびゼロから始まるすべてのまだ存在するオブジェクトの番号を変更します。メッセージはすべてのピアに、受け取ったオブジェクトを破棄し、再度照会するように指示しました。

より洗練されたアプローチは、既存のすべてのオブジェクトに対して「GUID 'n'のオブジェクトはGUID 'm'のオブジェクトになりました」というメッセージです。しかし、私の場合、実際に起こることはまずなく、1回のネットワークセッションで5日間ノンストップでプレイした後、世界中の人々が0.5秒間消えるリモートオブジェクトを本当に気にかけるとは思いませんでした。;）

クライアントが独自のエンティティを生成できる場合、ピアツーピアのマルチプレイヤーゲームがあると思います。

その場合は、おそらくクライアントが多すぎません。確かに256以下です。また、エンティティIDは24ビットに収まることが保証されています（16000000以上のエンティティで十分です！）。したがって、IDの最上位バイトをクライアントのIDと等しくするだけです。

entityId = clientId<<24 + (maxEntityIn++)

か何か。

そして、私が間違っていて、権限のあるサーバーがある場合は、クライアント上に新しいエンティティを作成しないでください。

私は永続的なマルチプレイヤーゲームで「最も素朴な」方法（新しいIDごとに整数を増やす）を使用していますが、クライアントに新しいIDを作成させないため、うまく機能します。

クライアントに（説明されたGUID手法を使用して）決定させると、クライアントは古いIDを新しいアイテムに割り当てることでさまざまなバグを導入することもできます（これは5秒のように頭の中で考えたことです） 、他の抜け穴がたくさんあるかもしれません）。

いつものように、不正行為を防ぐために、サーバーはすべての作成と検証を行う必要があります。