🥤 👨🏻‍🍳 👩🏾‍💻 モバイルゲームのアーキテクチャソリューション。パート2：コマンドとそのキュー 👰 🙍🏻 🏽

記事の最初の部分では、モデルを簡単に使用できるように配置する方法を検討しましたが、モデルのデバッグとインターフェースのねじ込みは簡単です。このパートでは、モデルの美しさと多様性のすべてについて、モデルの変更に対するコマンドのリターンを検討します。前と同じように、私たちにとっての優先事項は、デバッグの利便性であり、プログラマーが新しい機能を作成するために必要なジェスチャを最小限に抑え、人のコードを読みやすくすることです。

モバイルゲームのアーキテクチャソリューション。パート1：モデル

モバイルゲームのアーキテクチャソリューション。パート3：ジェット推力の表示

なぜコマンド

コマンドパターンは大声で聞こえますが、実際には、要求された操作に必要なすべてが追加され、そこに格納されるオブジェクトにすぎません。少なくともチームがネットワーク経由で送信されるため、このアプローチを選択します。さらに、公式に使用するためにゲームの状態のコピーをいくつか取得します。そのため、ユーザーがボタンをクリックすると、コマンドクラスのインスタンスが作成され、受信者に送信されます。略語MVCの文字Cの意味は多少異なります。

ネットワーク上での結果の予測とコマンドの検証

この場合、特定のコードはアイデアほど重要ではありません。そして、ここにアイデアがあります：

自尊心のあるゲームは、ボタンに反応する前にサーバーからの応答を待つことができません。もちろん、インターネットはより良くなっており、世界中にたくさんのサーバーを置くことができます。サーバーからの応答を待っているいくつかの成功したゲームさえ知っています。そのうちの1つはSummoning Warsでさえありますが、それでもあなたはそれをする必要はありません。モバイルインターネットの場合、5〜15秒のラグが例外よりも標準である可能性が高いため、モスクワでは少なくともプレイヤーが注意を払わないようにゲームは本当に素晴らしいはずです。

したがって、インターフェイスに必要なすべての情報を表すゲーム状態があり、コマンドはすぐに適用され、その後サーバーに送信されます。通常、勤勉なJavaプログラマーはサーバーに座って、すべての新しい機能を別の言語で1つずつ複製します。私たちの「鹿」プロジェクトでは、彼らの数は3人に達しました。代わりに、別の方法でそれを行うことができます。 .Netサーバーで実行し、クライアント側と同じコマンドコードをサーバー側で実行します。

前回の記事で説明したモデルは、セルフテストの新しい興味深い機会を提供します。クライアントでコマンドを実行した後、GameStateツリーで発生した変更のハッシュを計算し、チームに適用します。サーバーが同じコマンドコードを実行し、変更のハッシュが一致しなかった場合、何かがおかしくなりました。

最初の利点：

このソリューションは、開発を大幅にスピードアップし、サーバープログラマの数を最小限に抑えます。
プログラマーが非決定的な動作につながるミスを犯した場合、たとえば、辞書から最初の値を取得するか、DateTime.nowを使用し、コマンドフィールドに明示的に書き込まれなかったいくつかの値を使用すると、サーバーのハッシュが一致しなくなり、それについて調べます。
クライアント開発は、当分の間、サーバーなしで実行できます。サーバーがなくても、フレンドリーなアルファ版を使用できます。これは、夜に夢のゲームを逃してしまうインディー開発者だけでなく便利です。私がピクソニックにいたとき、サーバープログラマーがすべてのポリマーを失い、サーバーの代わりに時々ゲームの状態全体を愚かに守るダミーを使用して、ゲームをモデレートすることを余儀なくされた場合がありました。

何らかの理由で体系的に過小評価されている欠点：

クライアントプログラマーが何か間違ったことをし、テスト中にそれが目に見えない場合（たとえば、不思議な箱に入っている商品の確率）、同じことをもう一度書いてエラーを見つける人はいません。自動移植可能なコードには、テストに対してより責任ある態度が必要です。

詳細なデバッグ情報

優先事項の1つは、デバッグの利便性です。チームの実行中に実行をキャッチした場合-すべてが明確な場合、ゲームの状態をロールバックし、ログに完全な状態を送信し、それをドロップしたコマンドをシリアル化します。すべてが便利で美しいです。サーバーとの同期が取れていない場合、状況はより複雑になります。それ以来、クライアントはすでに他のいくつかのコマンドを完了しており、災害につながったコマンドを実行する前にモデルの状態を確認するだけでなく、本当にしたいことがわかったためです。各チームの前でゲームステートを複製するのは複雑すぎて費用がかかります。この問題を解決するために、エンジンのボンネットの下に縫い付けられたスキームを複雑にします。

クライアントには、1つのゲームステートではなく、2つのゲームステートがあります。最初はレンダリングのメインインターフェイスとして機能し、コマンドはすぐに適用されます。その後、適用されたコマンドはサーバーに送信するためにキューに入れられます。サーバーはサイドで同じアクションを実行し、すべてが正常で正しいことを確認します。確認を受け取ったクライアントは、同じコマンドを取得して2番目のゲーム状態に適用し、サーバーによって既に正しいと確認された状態にします。同時に、安全のために行われた変更のハッシュを比較する機会もあります。また、クライアント上のツリー全体の完全なハッシュを比較することもできます。これは、コマンドの実行後に計算でき、重量が少なく、十分に高速であると見なされます。サーバーがすべてが正常であると言っていない場合、何が起こったのかをクライアントに尋ね、クライアントはコマンドがクライアントで正常に実行される前とまったく同じように、シリアル化された2番目のゲーム状態をクライアントに送信できます。

ソリューションは非常に魅力的に見えますが、コードレベルで解決する必要がある2つの問題が発生します。

コマンドパラメータの中には、単純なタイプだけでなく、モデルへのリンクもあります。別のゲームステッドでは、まったく同じオブジェクトがモデルの他のオブジェクトです。この問題を次の方法で解決します。コマンドがクライアントで実行される前に、すべてのデータをシリアル化します。それらの中には、モデルへのリンクがあります。これは、ゲーム状態のルートからモデルへのパスの形式で記述します。実行後にパスが変更される可能性があるため、チームの前にこれを行います。次に、このパスをサーバーに送信すると、サーバーのゲームステートは、途中でモデルへのリンクを取得できます。同様に、チームが2番目のゲーム状態に適用される場合、モデルは2番目のゲーム状態から取得できます。
基本的なタイプとモデルに加えて、チームにはコレクションへのリンクがあります。辞書<キー、モデル>、辞書<モデル、キー>、リスト<モデル>、リスト<値>。すべての場合、彼らはシリアライザーを書かなければなりません。確かに、あなたはこれに突入することはできません。実際のプロジェクトでは、そのような分野はめったに起こりません。
サーバーに一度に1つずつコマンドを送信することはお勧めできません。インターネットでコマンドを前後にドラッグするよりも速くユーザーがコマンドを作成できるためです。貧弱なインターネットでは、サーバーで処理できなかったコマンドのプールが大きくなります。コマンドを一度に1つずつ送信する代わりに、いくつかのピースをまとめて送信します。この場合、サーバーから何か問題が発生したという応答を受け取った後、最初にサーバーによって確認された同じパッケージからのすべての以前のコマンドを2番目の状態に適用する必要があります。その後、制御2番目の状態を消去してサーバーに送信します。

コマンドの利便性と使いやすさ

コマンド実行コードは、ゲーム内で2番目に大きく、最も責任のあるコードです。よりシンプルで明確になり、プログラマーが手で余分なことを書く必要が少なくなるほど、コードが速く書かれ、エラーが少なくなり、非常に予想外に、プログラマーは幸せになります。実行コードは、個別の静的ルールクラスにある一般的な部分と機能に加えて、コマンド自体に直接配置します。ほとんどの場合、それらは、動作するモデルクラスの拡張の形式です。私のペットプロジェクトのコマンドの例をいくつか示します。1つは非常に単純で、もう1つはもう少し複雑です。

namespace HexKingdoms { public class FCSetSideCostCommand : HexKingdomsCommand { //              protected override bool DetaliedLog { get { return true; } } public FCMatchModel match; public int newCost; protected override void HexApply(HexKingdomsRoot root) { match.sideCost = newCost; match.CalculateAssignments(); match.CalculateNextUnassignedPlayer(); } } }

そして、このログが無効にされていない場合、このコマンドがそれ自体の後に残すログがあります。

 [FCSetSideCostCommand id=1 match=FCMatchModel[0] newCost=260] Execute:00:00:00.0027546 Apply:00:00:00.0008689 { "LOCAL_PERSISTENTS":{ "@changed":{ "0":{"SIDE_COST":260}, "1":{"POSSIBLE_COST":260}, "2":{"POSSIBLE_COST":260}}}}

ログに示される最初の時間は、モデルに必要なすべての変更が行われた時間であり、2番目は、すべての変更がインターフェースコントローラーによって実行された時間です。これは、ひどく遅いことを誤って行わないため、または単にモデル自体のサイズのために操作に時間がかかりすぎる場合に間に合うように通知するために、ログに表示する必要があります。

Id-shniksの永続オブジェクトへの呼び出しは別として、ログの可読性を大幅に低下させますが、ここでは回避できたかもしれませんが、コマンドコード自体とゲーム状態で行ったログは驚くほど明確です。コマンドのテキストでは、プログラマーが1回余分に移動することはありません。必要なものはすべて、ボンネットの下のエンジンによって行われます。

では、より大きなチームの例を見てみましょう

 namespace HexKingdoms { public class FCSetUnitForPlayerCommand : HexKingdomsCommand { //            protected override bool DetaliedLog { get { return true; } } public FCSelectArmyScreenModel screen; public string unit; public int count; protected override void HexApply(HexKingdomsRoot root) { if (count == 0 && screen.player.units.ContainsKey(unit)) { screen.player.units.Remove(unit); screen.selectedUnits.Remove(unit); } else if (count != 0) { if (screen.player.units.ContainsKey(unit)) { screen.player.units[unit] = count; screen.selectedUnits[unit].count = count; } else { screen.player.units.Add(unit, count); screen.selectedUnits[unit] = new ReferenceUnitModel() { type = unit, count = count }; } } screen.SetSelectedReferenceUnits(); screen.player.CalculateUnitsCost(); var side = screen.match.sides[screen.side]; screen.match.CalculatePlayerAssignmentsAcceptablity(side); screen.match.CalculateNextUnassignedPlayer(screen.player); } } }

そして、ここにチームが残したログがあります：

 [FCSetUnitForPlayerCommand id=3 screen=/UI_SCREENS[main] unit=militia count=1] Execute:00:00:00.0065625 Apply:00:00:00.0004573 { "LOCAL_PERSISTENTS":{ "@changed":{ "2":{ "UNITS":{ "@set":{"militia":1}}, "ASSIGNED":7}}}, "UI_SCREENS":{ "@changed":{ "main":{ "SELECTED_UNITS":{ "@set":{ "militia":{"@new":null, "TYPE":"militia", "REMARK":null, "COUNT":1, "SELECTED":false, "DISABLED":false, "HIGHLIGHT_GREEN":false, "HIGHLIGHT_RED":false, "BUTTON_ENABLED":false}}}}}}}

彼らが言うように、それははるかに明確です。時間をかけて、チームに便利でコンパクトで有益なログを提供します。これがあなたの幸せの鍵です。モデルは非常に高速に動作する必要があるため、ここでは、ストレージの方法とフィールドへのアクセス方法でさまざまなトリックを使用しました。最悪の場合、コマンドはフレームごとに1回実行されますが、実際には数倍の頻度で実行されるため、コマンドフィールドのシリアル化と非シリアル化は、リフレクションを介して、問題なく実行されます。順序が固定されるように、名前でフィールドを並べ替えるだけです。コマンドの実行中にフィールドのリストを1回コンパイルし、ネイティブメソッドC＃を使用して読み書きします。

インターフェイスの情報モデル。

エンジンを複雑にする次のステップに進みましょう。このステップは恐ろしく見えますが、インターフェースの作成とデバッグを大幅に簡素化します。非常に多くの場合、特に関連するMVPパターンでは、モデルにはサーバー制御のビジネスロジックのみが含まれ、インターフェイスの状態に関する情報はプレゼンター内に保存されます。たとえば、5つのチケットを注文するとします。すでに番号を選択していますが、まだ「注文」ボタンをクリックしていません。フォームで選択したチケットの正確な数に関する情報は、クラスの秘密のコーナーのどこかに保存でき、モデルとそのディスプレイの間のガスケットとして機能します。または、たとえば、プレイヤーが画面を切り替えるが、モデルに何も変化がなく、悲劇が起こったときに彼がいた場所で、デバッグに関与するプログラマーは非常に訓練されたテスターの言葉からしか知りません。私の意見では、このアプローチはシンプルで理解しやすく、ほとんどの場合に使用され、少し悪意があります。何か問題が発生した場合、エラーの原因となったこのプレゼンターの状態を見つける方法がまったくないためです。特に、制御中の再現可能な環境のテスターではなく、1000ドルの操作中にバトルサーバーでエラーが発生した場合。

この通常のアプローチの代わりに、モデル以外の人にインターフェースの状態に関する情報を含めることを禁止します。これには、いつものように、戦わなければならない長所と短所があります。

（+1）最も重要な利点は、人々のプログラミング作業を数か月節約できることです。何か問題が発生した場合、プログラマーは事故の前にゲームの状態を読み込むだけで、ビジネスモデルだけでなく、画面の最後のボタンへのインターフェイス全体の状態もまったく同じになります。
（+2）一部のチームがインターフェースで何かを変更した場合、プログラマーは簡単にログにアクセスし、前のセクションのように、便利なjson形式で何が変更されたかを簡単に確認できます。
（-1）モデルには、ゲームのビジネスロジックを理解するために必要ではなく、サーバーによって2回必要とされない多くの冗長な情報が表示されます。

この問題を解決するために、一部のフィールドをnotServerVerifiedとしてマークします。たとえば、次のようになります。

 public EDictionary<string, UIStateModel> uiScreens { get { return UI_SCREENS.Get(this); } } public static PDictionaryModel<string, UIStateModel> UI_SCREENS = new PDictionaryModel<string, UIStateModel>() { notServerVerified = true };

モデルのこの部分とその下のすべては、クライアントのみに関連します。

まだ覚えている場合は、エクスポートする必要があるものとそうでないもののフラグ：

 [Flags] public enum ExportMode { all = 0x0, changes = 0x1, serverVerified = 0x2 }

したがって、ハッシュをエクスポートまたは計算するときに、ツリー全体をエクスポートするか、サーバーによってチェックされるツリーの一部のみをエクスポートするかを指定できます。

ここから生じる最初の明らかな複雑さは、サーバーがチェックする必要があるコマンドと不要なコマンドを個別に作成する必要があることですが、完全にチェックする必要はないコマンドもあります。コマンドを設定するための不必要な操作をプログラマにロードしないようにするために、エンジンフードで必要なすべての操作を再度試みます。

 public partial class Command { /** <summary>    ,      </summary> */ public virtual void Apply(ModelRoot root) {} /** <summary>         </summary> */ public virtual void ApplyClientSide(ModelRoot root) {} }

コマンドを作成するプログラマは、これらの機能の一方または両方をオーバーライドできます。もちろん、これはすべて素晴らしいことですが、プログラマーが何かを台無しにしないようにするにはどうすればよいでしょうか。もし彼が何かを台無しにしたらどうすれば手早く簡単に修正できるでしょうか。 2つの方法があります。最初のアプリケーションを適用しましたが、2番目のアプリケーションをもっと気に入るかもしれません。

最初の方法

モデルのクールな機能を使用します。

エンジンは最初の関数を呼び出し、その後、サーバーがチェックしたゲーム状態の部分の変更のハッシュを受け取ります。変更がない場合は、クライアントチームのみを対象としています。
サーバーで検証されたものだけでなく、モデル全体の変更のモデルハッシュを取得します。前のハッシュと異なる場合、プログラマーは台無しにして、サーバーによってチェックされなかったモデルの一部を変更しました。状態ツリーを一周し、notServerVerified = trueフィールドと彼が変更したツリーの下にあるフィールドの完全なリストをプログラマーに実行としてダンプします。
2番目の関数を呼び出します。モデルから、チェックされた部分で発生した変更のハッシュを取得します。最初の呼び出し後のハッシュと一致しない場合、2番目の関数でプログラマがすべてを行ったことを意味します。この場合に非常に有益なログを取得したい場合は、モデル全体を元の状態にロールバックし、ファイルにシリアル化します。プログラマはデバッグに便利になり、全体を複製します（2行-シリアル化-非シリアル化）、最初に適用します関数、モデルが変更されていないように変更をコミットし、その後、2番目の関数を適用します。そして、サーバーチェックされた部分のすべての変更をJSONの形式でエクスポートし、不正な実行に含めます。これにより、恥ずかしいプログラマーは、何をどこで変更し、何を変更すべきではないかをすぐに確認できます。

もちろん、恐ろしく見えますが、実際には7行です。これを行う関数はすべて（2番目の段落からツリーをトラバースすることを除く）既に準備ができているからです。そして、これはレセプションであるため、最適ではない行動をとることができます。

第二の方法

もう少し残忍です。ModelRootには1つのロックフィールドがありますが、2つに分割できます。1つはチェックされたフィールドのみをサーバーにロックし、もう1つはチェックされたフィールドのみをロックします。この場合、何か間違ったことをしたプログラマーは、それを行った場所に結び付けてすぐにそれについて説明を得るでしょう。このアプローチの唯一の欠点は、ツリーで1つのモデルプロパティが未チェックとしてマークされている場合、各フィールドがマークされていなくても、ハッシュの計算と変更の制御に関するその下のツリーのすべてが検査されないことです。そしてもちろん、ロックは階層を調べません。つまり、ツリーのチェックされていない部分のすべてのフィールドをマークする必要があり、UIの同じクラスとツリーの通常の部分を使用する場所によっては機能しません。オプションとして、そのような構成が可能です（簡略化して記述します）。

 public class GameState : Model { public RootModelData data; public RootModelLocal local; } public class RootModel { public bool locked { get; } }

次に、各サブツリーに独自のロックがあることがわかります。 GameStateはモデルを継承します。同じ機能をすべて個別に実装するよりも簡単だからです。

必要な改善

もちろん、コマンドの処理を担当するマネージャーも新しい機能を追加する必要があります。変更の本質は、すべてのコマンドがサーバーに送信されるのではなく、チェックされた変更を作成するコマンドのみがサーバーに送信されることです。その側のサーバーは、ゲーム状態ツリー全体を上げるのではなく、チェック対象の部分のみを上げるため、ハッシュはチェック対象の部分についてのみ一致します。サーバーでコマンドが実行されると、コマンドの2つの関数のうち最初の関数のみが起動されます。ゲーム状態のモデルへの参照を解決する場合、パスがツリーの検証不可能な部分につながる場合、モデルの代わりにコマンド変数にnullが配置されます。すべての非送信チームは、通常のチームと正直に並んでいますが、同時に確認済みとみなされます。それらがラインに到達し、それらの前に未確認のものがなくなるとすぐに、それらはすぐに2番目の状態に適用されます。

実装には基本的に複雑なものはありません。モデルの各フィールドのプロパティには、もう1つの条件であるツリートラバーサルがあります。

別の必要な改良-ツリーのチェック済みおよび未チェックの部分でParsistentModelの個別のファクトリが必要になり、それらのNextFreeIdは異なります。

サーバーによって開始されたコマンド

サーバーがクライアントにコマンドをプッシュしたい場合、サーバーに対するクライアントの状態が数ステップ先にジャンプする可能性があるため、いくつかの問題があります。主な考え方は、サーバーがコマンドを送信する必要がある場合、次の応答でサーバー通知をクライアントに送信し、このクライアントに送信される通知のフィールドにそれを書き込みます。クライアントは通知を受信し、それに基づいてコマンドを作成し、クライアントで完了したがまだサーバーに到達していないものの後に、それをキューの最後に配置します。しばらくすると、モデルを操作する通常のプロセスの一部として、コマンドがサーバーに送信されます。処理のためにこのコマンドを受信すると、サーバーは発信キューから通知をスローします。クライアントが次のパッケージで設定時間内に通知に応答しなかった場合、再起動コマンドが送信されます。通知を受け取ったクライアントが落ちたり、後で接続したり、何らかの理由でゲームをロードしたりした場合、サーバーはすべての通知をコマンドに変換してから状態に渡し、その側でそれらを実行します。その後、参加クライアントに新しい状態を与えます。サーバーがプレイヤーからお金を奪った瞬間にプレイヤーがお金を使うことができた場合、プレイヤーは負のリソースと競合状態になる可能性があることに注意してください。偶然の一致はありそうにありませんが、DAUが大きい場合、ほとんど避けられません。したがって、このような状況でインターフェースとゲームのルールが死ぬことはありません。

サーバーの応答を知る必要がある実行するコマンド

典型的な間違いは、乱数はサーバーからしか取得できないと考えることです。共通のsidから開始して、クライアントとサーバーで同期して実行される同じ擬似乱数ジェネレーターを使用することを妨げるものは何もありません。さらに、現在のシードはゲームステートに直接保存できます。このジェネレーターの応答を同期するのが難しいと感じる人もいます。実際、このためには、同じ記事にもう1つ数字があれば十分です。つまり、この時点までにジェネレーターから受け取った数字の数です。何らかの理由でジェネレーターが収束しない場合、どこかにエラーがあり、コードは確定的に機能しません。そして、この事実はカーペットの下に隠されるべきではなく、整理されてエラーを探すべきです。不思議な箱も含めて、ほとんどの場合、このアプローチで十分です。

ただし、このオプションが適切でない場合があります。たとえば、非常に高価な賞品をプレイしていて、cな仲間にゲームを逆コンパイルさせたくない場合、ボットを書いて、今すぐダイアモンドボックスを開けると、その前に別の場所でドラムを回すとどうなるかを事前に伝えます。ランダム変数ごとにシードを個別に保存できます。これにより、正面からのハッキングを防止できますが、必要な製品が現在いくつあるかを通知するボットからの助けにはなりません。さて、最も明白なケース-まれなイベントの可能性に関する情報をクライアント設定に反映したくない場合があります。要するに、サーバーの応答を待つ必要がある場合があります。

このような状況は、エンジンの追加機能ではなく、チームを2つに分割することで解決する必要があります。最初の状況では、状況を準備し、通知を待機状態にします。クライアントでそれらの間のインターフェイスをしっかりとブロックしても、別のコマンドがすり抜けることがあります。たとえば、エネルギーの単位が時間内に復元されます。

このような状況はルールではなく、例外であることを理解することが重要です。実際、ほとんどのゲームに必要なのは、GetInitialGameStateという1つのチームだけです。そのようなコマンドのもう1つのパックは、メタゲームでのプレイヤー間の対話、たとえばGetLeaderboardです。他の200個すべては決定論的です。

サーバーデータストレージとサーバー最適化の曖昧なトピック

私はクライアントであるとすぐに認めますが、時々、よく知られているサーバーサーヴァントから、頭に忍び寄らないようなアイデアやアルゴリズムを聞いたことがあります。同僚とのコミュニケーションから、理想的な場合にサーバーサイドで自分のアーキテクチャがどのように機能するかについての図を作成しました。ただし、禁忌があります。専門のサーバーに相談する必要があります。

まず、データストレージについて。追加の制限があるのはサーバー側です。たとえば、静的フィールドの使用が禁止されている場合があります。さらに、コマンドとモデルのコードは自動移植可能ですが、クライアントとサーバーのプロパティコードは一致する必要はありません。たとえば、memcacheからのフィールド値の遅延初期化まで、あらゆるものを非表示にすることができます。プロパティフィールドは、サーバーで使用される追加のパラメーターを受け取ることもできますが、クライアントの操作には影響しません。

サーバーの最初の基本的な違い：フィールドはシリアル化および非シリアル化されます。合理的な解決策は、状態ツリーのほとんどが1つの巨大なバイナリまたはjsonフィールドにシリアル化されることです。同時に、いくつかのフィールドはテーブルから取得されます。プレイヤー間のインタラクションサービスが機能するためには、一部のフィールドの値が常に必要になるため、これが必要です。たとえば、アイコンとレベルはさまざまな人々によって絶え間なく動いています。それらは通常のデータベースに保存するのが最適です。誰かが自分の領域を調べることを決めた場合、その人の完全なまたは部分的な、しかし詳細な状態が必要になることはほとんどありません。

さらに、ベースからフィールドを一度に1つずつ引き出すのは不便であり、長時間すべてをドラッグすることができます。私たちのアーキテクチャでのみ利用可能な非常に非標準的なソリューションは、クライアントがコマンドを実行するときに、ゲッターがタッチするテーブルに個別に保存されたすべてのフィールドに関する情報を収集し、サーバーがこのフィールドのグループを上げることができるようにコマンドにこの情報を追加することで構成されますデータベースへの1つのリクエスト。もちろん、すべてを不注意に触れた利き腕のあるプログラマーに起因するDDOSを請うことのないように、合理的な制限があります。

このような別個のストレージでは、あるプレーヤーが別のプレーヤーのデータにクロールするとき、たとえば彼からお金を盗むとき、トランザクション性のメカニズムを考慮する必要があります。しかし、一般的なケースでは、通知によってこれを行います。つまり、泥棒はすぐにお金を受け取り、奪われた人は、そのことになるとお金を取り消すよう指示する通知を受け取ります。

チームをサーバー間で分割する方法

サーバーにとって2番目の重要な瞬間です。 2つのアプローチがあります。最初に、要求（または要求のパケット）を処理するために、状態全体がデータベースまたはキャッシュからメモリに上げられ、処理された後、データベースに返されます。操作は、多数の異なる実行サーバーでアトミックに実行され、共通のベースのみを持ち、常にそうではありません。クライアントとして、各チームに状態全体を上げることは衝撃的ですが、どのように機能し、非常に信頼性が高くスケーラブルに機能するかを見ました。 2番目のオプションは、状態がメモリ内でいったん上昇し、クライアントが現在の状態をデータベースに時々追加するだけで落ちるまでそこに存在することです。私は、この方法またはその方法の長所と短所をあなたに伝えることができません。コメントの誰かが私に最初の人が一般に生命に対する権利を持っている理由を説明してくれると良いでしょう。 2番目のオプションでは、偶然別のサーバーでレイズされたことが判明したプレーヤー間の対話方法についての質問が発生します。これは、たとえば、複数のクランメンバーが共同攻撃を開始する準備をしている場合に重要になることがあります。 10セーブの遅延で、彼のパーティーメンバーの状態を他の人に示すことはできません。残念ながら、ここで開くことはできません。上記の通知を介したやり取り、あるサーバーから別のサーバーへのコマンド-現時点では、そこで発生したプレーヤーの現在の状態を保存することはできません。サーバーが異なる場所から同じレベルの可用性を備えている場合、そして、バランサーを管理できるので、あるサーバーから別のサーバーにプレイヤーを静かに静かに転送することができます。解決策をよく知っている場合は、コメントに必ず記載してください。

時間をかけて踊る

質問から始めましょう。私はインタビューで人々を引き付けるのが本当に好きです。ここには、クライアントとサーバーがあり、それぞれにかなり正確な時計があります。それらがどの程度異なるかを調べる方法。ナプキンのコーヒーショップでこの問題を解決しようとすると、プログラマーの最高の品質と最悪の品質が明らかになります。事実は、問題には正式な数学的に正しい解決策がないことです。しかし、インタビューを受けた人は、これを知っているので、原則として、主要な質問の後でのみ、5番目に少し時間がかかります。そして、彼がどのようにこのインスピレーションに出会い、彼が次に何をするか-彼のキャラクターで最も重要なこと-この人があなたのプロジェクトで実際の問題が始まったときに何をするかについて多くを語っています。

私が知っている最良の解決策では、正確な違いを見つけることはできませんが、クライアントからサーバーに実行された最適なパケットの時間までの多くの要求-応答と、サーバーからクライアントに実行された最良のパケットの時間までの範囲を明確にすることはできません。合計すると、これにより数十ミリ秒の精度が得られます。これは、モバイルゲームのメタゲームに必要なものよりも何倍も優れています。ここではVRマルチプレイヤーやCSはありませんが、クロック同期の難しさの規模と性質を表現することはプログラマにとってはまだ良いことです。最も可能性が高いのは、30％を超える偏差のカットオフを使用して、長い間、pingとして実行される平均遅延を知ることで十分です。

遭遇する可能性のある2番目のクールな状況は、スリップゲームのステージングと、携帯電話でのクロックの転送です。どちらの場合も、アプリケーションの時間は劇的に急激に変化するため、これを正しく解決する必要があります。少なくともゲームは再起動しますが、もちろん、各スリップの後に再起動しない方が良いので、アプリケーションの起動以降に経過した時間を使用することはできません。

第三に、状況は何らかの理由で、一部のプログラマーにとって理解しがたい問題ですが、それに対する正しい解決策があります：操作はサーバー時間では絶対に実行できません。たとえば、生産の要求がサーバーに到着したときに商品の生産を開始します。さもなければ、決定論に別れを告げ、賞をクリックすることが既に可能かどうかについてクライアントとサーバーの異なる意見によって引き起こされる1日あたり35,000の非同期をキャッチします。正しい決定は、チームが実行された時間に関する情報を記録することです。サーバーは、現在のサーバー時間とコマンド内の時間との時差が許可された間隔内に収まっているかどうかを確認し、許容範囲内にある場合は、クライアントが宣言した時間を使用して一部でコマンドを実行します。

インタビューの別のタスク：クライアントが再起動を試みるタイムアウト-30秒。許容されるサーバー時間差の制限は何ですか？ヒント＃1：間隔は対称ではありません。ヒント2：このセクションの最初の段落をもう一度読み直し、エッジ効果で1日あたり3000エラーをキャッチしないように間隔を延長する方法を指定します。

これが美しく正しく動作するためには、コマンド呼び出しパラメーターに追加のパラメーター、つまり呼び出し時間を追加することをお勧めします。このようなもの：

 public interface Command { void Apply(ModelRoot root, long time); }

ちなみに、私のアドバイスは、モデルの時間にネイティブのUnityタイプを使用しないでください。 UnixTimeをサーバー時間に保存し、常に便利な変換メソッドを用意する必要がある場合、PValue <long>とは異なる特別なPTimeフィールドにモデルに保存することをお勧めします。JSONにエクスポートする場合は、 import：人間が読める形式の時間。あなたは私に従うことができません。私はあなたに警告しました。

第4の状況：ゲームの状態では、プレーヤーの参加なしにチームを開始しなければならない状況があります。たとえば、エネルギーの回復などです。実際、非常に一般的な状況。私はフィールドを持ちたい、それは便利に練習しています。たとえば、PTimeOutでは、コマンドを作成して実行する必要がある時点を記録できます。コードでは、次のようになります。

 public class MyModel : Model { public static PTimeOut RESTORE_ENERGY = new PTimeOut() {command = (model, property) => new RestoreEnergyCommand() { model = model}} public long restoreEnergy { get { return RESTORE_ENERGY.Get(this); } set { RESTORE_ENERGY.Set(this, value); }} }

もちろん、プレーヤーの初期ロード中に、サーバーは最初にこれらすべてのコマンドの作成と実行を引き起こし、それからプレーヤーに状態を与える必要があります。ここでの落とし穴は、このすべてがこの間にプレーヤーが受け取る可能性のある通知を妨害することで有名です。したがって、コマンドの束を同時にプルする必要がある場合は、最初の通知の時刻の前にまず時間を緩め、次に通知自体からコマンドを作成し、次の通知まで時間を緩めて、それを実行する必要があります。この全体の休日がサーバーのタイムアウトに収まらない場合、およびプレーヤーが通知でいっぱいになった場合にこれが可能であれば、現在の状態をメモリからデータベースに書き込み、代わりにクライアントに再接続するコマンドで応答します。

これらのコマンドはすべて、作成して実行に必要なものについて何らかの方法で学習する必要があります。私の少し松葉杖ですが、便利な解決策は、モデルにもう1つの課題があることです。これは、モデルの階層全体を移動し、各コマンドが実行された後、タイマーでも作動します。もちろん、これはほとんど更新でツリーを歩き回る余分なオーバーヘッドです。代わりに、このフィールドを変更するたびにゲーム状態から突き出たcurrentTimeイベントをサブスクライブまたはサブスクライブ解除できます。

 public partial class Model { public void SetCurrentTime(long time); } vs public partial class RootModel { public event Action<long> setCurrentTime; }

これは良いことですが、問題は、モデルツリーから永久に削除され、そのようなフィールドを含むモデルはこのイベントにサブスクライブされたままであり、正しく動作する必要があることです。コマンドを送信する前に、それらがまだツリー内にあり、このイベントまたは制御の反転に弱いリンクを持っているかどうかを確認します。これにより、GCにアクセスできなくなることはありません。

付録1、実生活から取られた典型的なケース

コメントから最初の部分に移ります。おもちゃでは、非常に多くの場合、モデルへのコマンドの直後ではなく、何らかのアニメーションの最後にいくつかのアクションが実行されます。私たちの実践では、ミステリーボックスが開くようなケースがありました。もちろん、アニメーションが最後まで再生されたときにのみお金が変わるはずです。私たちの開発者の1人は、彼の人生を簡素化することを決定し、コマンドで値を変更せず、サーバーに彼が変更したことを伝え、アニメーションの最後にコールバックを実行し、モデルの値を目的の値に修正します。一言で言えば、よくできました。彼は2週間これらの不思議な箱を作り、その後、彼の活動の結果として表面化した3つのキャッチしにくいミスを見つけました。そして、「通常の書き換え」の時間はもちろんですが、誰も強調できませんでした。そこから鮮やかに続く結論は、最初からすべてを通常の反応性で行う方が良いということだと思います。

だから、私の決定はこのようなものです。もちろん、お金は別のフィールドにあるのではなく、インベントリ辞書のオブジェクトの1つですが、これは今のところそれほど重要ではありません。モデルには、サーバーによってチェックされ、それに基づいてビジネスロジックが機能する部分と、クライアント上にのみ存在する部分があります。メインモデルのお金は、決定が行われるとすぐに発生し、「遅延表示」リストの2番目の部分では、その外観の事実によってアニメーションを開始するのと同じ量の要素が作成され、アニメーションが終了すると、この要素を削除するコマンドが起動されます。このような純粋なクライアントのメモは、「まだこの金額を表示しません」また、実際のフィールドでは、フィールドの値だけでなく、フィールドの値からすべてのクライアント延期を差し引いた値が表示されます。ちょうどそのような2つのチームへの分割が行われたのは、クライアントが最初のチームの後でリブートし、2番目のチームの前にプレーヤーが受け取ったすべてのお金がマークや例外なしで彼のアカウントに入ればどうなるでしょうコードでは、次のようになります。

 public class OpenMisterBox : Command { public BoxItemModel item; public int slot; //        ,  . public override void Apply(GameState state) { state.inventory[item.revardKey] += item.revardCount; } //       . public override void Apply(GameState state) { var cause = state.NewPersistent<WaitForCommand>(); cause.key = item.key; cause.value = item.value; state.ui.delayedInventoryVisualization.Add(cause); state.ui.mysteryBoxScreen.animations.Add(new Animation() {cause = item, slot = slot})); } } public class MysteryBoxView : View { /* ... */ public override void ConnectModel(MysteryBoxScreenModel model, List<Control> c) { model.Get(c, MysteryBoxScreenModel.ANIMATIONS) .Control(c, onAdd = item => animationFactory(item, OnComleteOrAbort => { AsincQueue(new RemoveAnimation() {cause = item.cause, animation = item}) }), onRemove = item => {} ) } } public class InventoryView : View<InventoryItem> { public Text text; public override void ConnectModel(InventoryItem model, List<Control> c) { model.GameState.ui.Get(c, UIModel.DELAYED_INVENTORY_VISUALIZATION). .Where(c, item => item.key == model.key) .Expression(c, onChange = (IList<InventoryItem> list) => { int sum = 0; for (int i = 0; i < list.Count; i++) sum += list[i].value; return sum; }, onAdd = null, onRemove = null ) //      .Join (c, model.GameState.Get(GameState.INVENTORY).ItemByKey(model.key)) .Expression(c, (delay, count) => count - delay) .SetText(c, text); //     ,      ,   ,  ,   ,       ,     : model.inventory.CreateVisibleInventoryItemCount(c, model.key).SetText(c, text); } } public class RemoveDelayedInventoryVisualization : Command { public DelayCauseModel cause; public override void Apply(GameState state) { state.ui.delayedInventoryVisualization.Remove(cause); } } public class RemoveAnimation : RemoveDelayedInventoryVisualization { public Animation animation public override void Apply(GameState state) { base.Apply(state); state.ui.mysteryBoxScreen.animations.Remove(animation); } }

最後に何がありますか？ 2つのビューがあり、そのうちの1つでいくつかのアニメーションが再生され、その終わりはお金が完全に異なるビューで表示されるのを待っています。すべてが反応的です。いつでもGameStateの完全な状態をゲームに読み込むことができ、アニメーションの開始を含め、中断したところから正確にプレイを開始します。アニメーションステージは消去しないため、真実は最初から始まりますが、本当に必要な場合は消去することもできます。

合計

モデル、コマンド、静的ファイルをルールでゲームのビジネスロジックを作成し、美しく詳細で自動生成されたログでそれらをラップし、新しい機能を見たプログラマーが犯した多くの典型的なミスの有益な実行を囲みます。白い光。それは、新しい機能を数倍速く登録できるからです。新しい機能のダウンロードとデバッグが簡単な場合、ゲームデザイナーは同じプログラマーを使用してゲームデザインの実験を数回行うことができるため、これは非常に重要です。私たちの仕事に敬意を払って、ゲームが失敗するかどうかは私たち次第ですが、それが射撃するかどうかはgamedismsに依存し、実験のためにスペースを与える必要があります。

そして今、私にとって非常に重要な質問に答えるようお願いします。あなたが私が下手にしたことをする方法についてのアイデアを持っているか、私の答えにコメントしたい場合、私はコメントであなたを待っています。多数の構文エラーに関する協力と指示の提案は、PMでお願いします。

モバイルゲームのアーキテクチャソリューション。 パート2：コマンドとそのキュー