パート2：プロトコル
パート3：クライアントとサーバーの相互作用
パート4：3Dへの移行
一般に、約束どおり、マルチプレイヤーオンラインゲームの開発に関する一連の記事を公開しています。 最初は、興味深いScala言語でのサーバー側の開発に関する記事をまとめたかっただけです。 しかし、トピックを拡張するための1つの記事が機能しないことに気付きました。 そして、私はすべてについて何も別のトピックを書きたくはありませんでした。 したがって、3つの行為で演劇に会います。 その間、プロジェクトのアーキテクチャを開発し、サーバーとクライアント部分を実装します...
誰もが面白いダンディ戦車を覚えていますか？
さて、これらの戦車の例を使用して、サーバーとクライアントを開発します。
景品やハードコピーの貼り付けが好きな人には、すぐに完全なソースコードは存在しないと言います。 サーバーとクライアントの両方の特定の興味深い（複雑な？）モーメントのみをアップロードします。
親愛なる視聴者を始めましょう。
ストーリーの過程で、ネットワークゲームテクノロジーの世界に飛び込みます...禁止されたscalaコードの甘い実を認識し、フラッシュのコーディングを味わう機会を得ます...そして最後のステップとして、完成したプロジェクトのhabraeffectを手配し、実際のハードウェアで結果のアーキテクチャを確認します。
パート1 アクション1：プロジェクトの一般的な説明。
何をするかを順番に書きます。
BigWorldを作成するタスク（これは知識のない人のエンジンです）に直面しておらず、プロトタイプを作成しているため、可能な限りタスクを単純化します。 私たちの主な仕事は、ネットワークゲームの一般的な開発方法を示すことです。 具体的な作業例。 そして、完成した商用製品を作らないでください。
タスク ：「ダンディタンク」などのネットワークゲーム。 Flashのクライアント部分、Scalaのサーバー。 ソケットを介した接続。 多くのトラブルを取り除くために、「以前に起きたのは誰ですか-それとスリッパ」の原則に基づいて非同期サーバーを作成します。
一般的に、クライアントはゲーム内のサーバーインタラクションとして何を意味しますか？
1.ユーザーログイン
2.サーバーとの交換（クライアントからサーバーへのコマンドの送信、サーバーからのコマンドへの応答の受信、サーバーからのコマンドの受信）
3.サーバー管理のAdiminsky部分
ユーザーログインは、ゲームの主要な認証です。 シンプルなことはすべて行い、検証はログイン段階でのみ行われます。 一般的に、不正行為者からのすべての消防士について、ゲームで承認を定期的に確認する必要があります。 新しいログインで最初にログインすると、ゲームはそれをデータベースに入れます。これが登録全体です。
管理部分もプリミティブです。 ユーザーのリストをオンラインで表示します。 ストレステストに役立ちます。
サーバーとの交換-これはゲームのプロトコルです。 サーバーの実装を行うときに作成します。
サーバー
サーバーの実装では、同期クライアントの同期オプション（履歴の再現、予測など）を気にしません。 （それは私が断ったものです-同期同期...-著者のコメント）
つまり 原理は非常に簡単です。 クライアントへのpingを測定するため、各クライアントの遅延がわかります。 これにより、接続が不十分なクライアントのゲーム全体への影響を排除でき、同期オプションよりも実装が簡単です。 はい、このオプションを使用すると、pingが非常に長い場合にオプションを使用でき、スライドショーを取得できます。 しかし同時に、すべてが正しく処理されます。 また、スライドショーは、大きなpingを持っているお客様のみを対象としています。 ロード時には、各クライアントの実際のping値を保存する必要があります。
プロジェクトの概要を説明すると、すべてが明確に見えます。
パート1 ステップ2：サーバーアーキテクチャ。
この記事はある程度調査中であることをすぐに警告したいと思います。 つまり サーバーの実装および負荷テストの過程で、そのアーキテクチャはさまざまな状況の影響下で変化する可能性があります（そして変化します）...
一般的なスキームは次のとおりです。
一般に、スレッドのプールを使用した古典的なスキームに従って行います。 私たちのゲームは単純で、物理学は含まれていません。実際、サーバー上の計算はほとんどありません。
サーバーの一般的なロジックは次のとおりです。
1.クライアントから承認リクエストを受け取ります。
2.マップ上のタンクの外観の座標をランダムに与えます。
3.クライアントは、一定の周期で（より頻繁に移動中に）座標をサーバーに送信します。
4.発射されると、それが来た地点の座標がサーバーに送信されます。
5.サーバーは発射物の飛行を計算し、衝突するかどうかを決定します。
6.また、運転中、サーバーは障害物を識別します。 そして、タンクがこの方向に移動することを許可しません。
7.クライアントの要求に応じて、サーバーはクライアントの数をオンラインで送信します。
基本的にこれで目的はすべてです。
将来的には、ハブロフスク市民にとって興味深い場合、このスキームは、サーバーパーツを異なるマシンに分離する通常のアーキテクチャに拡張できます。
数日のうちに、交換プロトコルを開発し、TCPサーバーを実装し、サーバーとクライアントの最初の接続を行う次の部分があります。
PS実際には、トピックは非常に広範囲です。 したがって、何に注意を喚起するかについての希望がある場合、または説明で見失ったものがある場合-kamentyのウェルトに。
あなたの願いと批判は、物語の次の部分をより有用かつ建設的にすることを可能にします。
更新しました。 Habrachiansのリクエストにより、プロジェクトのGithubをオープンしました