サーバー上のゲームロジック！良いまたは悪い？

現在、シンプルなオンラインマルチプレイヤーゲームを計画しています。そしてここに質問があります。サーバーでゲームロジック全体を作成し、クライアントからサーバーに入力を送信するだけで意味がありますか？長所と短所はどちらですか、そうしない理由はありますか？

プレイヤーの入力をサーバーに送信したくありません。おそらくやりたいことは、プレーヤーがやりたいことの抽象化された表現をサーバーに送信し、そこでロジックを実行することです。

同様に、必ずしもクライアントが行う必要があるすべてを送り返す必要はありません。たとえば、「NPC Xが死んだ」というメッセージを送信すると、クライアントは再生するアニメーション/サウンドを決定します。そのようなもの。

トリックは、帯域幅と処理能力（サーバー上）が人々の不正行為を防ぐことで勝るラインを見つけることです。通常、あなたはサーバーでのみゲームを変える権威ある決定を行い、すべての補助的な視覚的なものはクライアントに任せます。

このトピックに関しては、サイト全体にもっと具体的な質問がたくさんあります。例えば：

衝突の検出は、サーバー側で行うか、クライアント/サーバー間で協調して行う必要がありますか？

MMOでAIを計算するのは誰ですか？

ゲームのホストはオーソリティか、それとも別の愚かなクライアントでしょうか？

さて、あなたは答えを得ましたが、あなたの本当の答えは「自分で試して」です。物事はゲームごとに異なります。

いくつかの分散ネットワークゲームデザインコースで複数のマルチプレイヤーゲームを行いました。最も困難なのは、多くのプレイヤーが関与し、地獄のような入力を送信するリアルタイムアクションゲームを行うことでした。その時点になると、すべてが問題になります。Tetratが最初に送信したリンクを見ると、共謀を判断することさえ問題になります。そして、ラグ、補間、外挿、予測などの用語を読み上げます。しかし、ゼロからコーディングを試したことがない場合、これらの単語を受け入れるだけで、それらが本当に何を意味するのかわかりません。

私の推奨事項は次のとおりです。

ステップ1
今のところ、完全に承認されたサーバーベースの設計から始めます。あなたが言ったように、ユーザー入力をサーバーに送信し、サーバーにすべてをさせ、クライアントに結果を取得させます。ゲームは完全に一貫して動作します。しかし、クライアントを見ると、スムーズな動きではなく、いくつかの遅れ、テレポートの問題に気づくでしょう...電気ショック療法。

ステップ2
クライアント側で問題の修正を開始します。たとえば、テレポートの問題。あなたのキャラクターは（0,0）で、サーバーはあなたが（100,100）にいると言いました。あなたのキャラクターは（100,100）にテレポートしますが、これは良くありません。補間があります。クライアント側に（0,0）から（100、100）にスムーズにキャラクターをスライドさせるコードが必要です。はい、キャラクターを（0,0）から（100,100）に移動しますが、どのくらいの速さですか？現時点では、各サーバーの更新間の時間差を使用できます。サーバーが1秒に10パケットを送信する場合、つまり各パケット間の遅延は100ミリ秒になります。

ステップ3
これで、ゲームはすでに（1-50）msの遅延がある高速ネットワークに適しています。ただし、パケット損失、高遅延、またはサーバーでの計算に時間がかかる場合は、運命づけられます... このような状況では、左矢印を押すと、200ミリ秒の遅延でキャラクターが左に移動するのがわかります。パケット間の遅延は計算時間であり、サーバーに送られ、最後の位置に戻ってきます。これは悪いことであり、サーバー認可設計の最悪の欠点です。プレイヤーは、左を押すとすぐにキャラクターが左に移動することを望んでいます。彼を待たせることはできません。幸い、クライアントもサーバーと同じコードを持っているので、クライアントですぐに実行して、サーバーからの回答で最終結果を修正してみませんか？それが基本的に入力予測です。クライアントが左を押すと、彼の側のコードが彼を左に移動し、しばらくしてから200ミリ秒とすると、実際の位置はサーバーから取得され、クライアントはその位置を修正します。すべてが順調に進んだ場合、クライアントは何も気付かないでしょう。「ステップ2」もこれに役立ちます。

まあ、ネットにはこの主題に関する多くのチュートリアルと事柄があります。しかし、私が本当に好きな2つがあります。

本当に良い、カバーダークスポット：バルブ・ソースエンジンマルチプレイネットワーク
の歴史の種類、楽しみ、それを読んで、ワース：28.8で1500人の射手、

長所：

• このアプローチは、より（ほとんどの）著作権侵害の証拠です
• 更新をより簡単に適用できます
• 集中コミュニティ

短所：

• 巨大な帯域幅要件
• 一部のユーザーはそのアプローチを嫌う可能性があります（プライバシーなど）
• ローカルゲームプレイ（LANパーティー）、シングルプレイヤーの問題

また、サーバー側のロジックはスケーラビリティの問題を引き起こします。サーバー上のすべてのクライアントに対してすべての作業を行う必要があります。

作成するゲームとゲームのどの部分に依存します。RTS（またはロックステップモデルを使用するゲーム）を開発する場合は、入力と受信したシミュレーションステップのみを送信する必要があります。

シューティングゲームを実行する場合は、入力関数と抽象関数の両方を使用できます。Unreal Tournament 3をケースとして使用すると、主に複製された関数呼び出しを介してマルチプレーヤーが作成されます。
動きについては、プレーヤーの入力（アクションごとに1ビットに圧縮）デルタ回転、加速、タイムスタンプを取得し、サーバーに送信します。
武器のような他の目的のために、それらはあなたが撃つときに同期します（私の知る限り、この部分をまだ詳しく調べていません）。
ヘルスなどのより静的な/あまり頻繁に変更されない値の場合、プログラマが指定した内容に応じて変数をクライアントまたはサーバーに送信します。

また、RTS以外のゲームでは、クライアントの予測を覚えておいてください。