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

エピグラフ：

「どうしたらいいかわからない場合、どのように評価しますか？」

-まあ、画面とボタンがあります。

-ディマ、あなたは今、私の人生を3つの言葉で説明しています！

（c）ゲーム会社の集会での真の対話







この記事で説明する一連のニーズとソリューションは、最初にFlashで、後にUnityで、約12の大規模プロジェクトに参加して形成されました。 最大のプロジェクトには200,000を超えるDAUがあり、貯金箱に新たな課題が追加されました。 一方、以前の調査結果の関連性と必要性​​が確認されました。



私たちの厳しい現実では、少なくとも一度は大規模なプロジェクトを少なくとも一度は自分の考えで設計した人は誰でも、それを行う方法について独自のアイデアを持ち、多くの場合、最後の一滴までアイデアを守る準備ができています。 他の人にとっては、それは私を笑顔にします。そして、経営者はしばしば、これらすべてを誰にも負けていない巨大なブラックボックスと見なします。 しかし、正しいソリューションが、新しい機能の作成を2〜3倍、古い5〜10倍のエラーの検索を削減し、以前はアクセスできなかった多くの新しい重要なことを行えるようになるとしたらどうでしょうか。 建築物をあなたの心に入れるのに十分です！

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

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

モデル

フィールドへのアクセス

ほとんどのプログラマーは、MVCのようなものを使用することの重要性を認識しています。 4人のギャングの本の純粋なMVCを使用する人はほとんどいませんが、通常のオフィスのすべてのソリューションは、このパターンの精神に何らかの形で似ています。 今日は、この略語の最初の文字についてお話します。 モバイルゲームでのプログラマの作業の大部分は、メタゲームの新機能であり、モデルの操作として実装され、これらの機能に何千ものインターフェイスをねじ込んでいます。 このレッスンでは、モデルの利便性が重要な役割を果たします。



完全なコードは提供しませんが、それはちょっとしたもので、一般的には彼に関するものではないからです。 私は簡単な例を使って推論を説明します。

public class PlayerModel { public int money; public InventoryModel inventory; /* Using */ public void SomeTestChanges() { money = 10; inventory.capacity++; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このオプションは、モデルで発生した変更に関するイベントを送信しないため、まったく適していません。 どのフィールドが変更の影響を受け、どのフィールドが変更されず、どのフィールドが再描画される必要があり、どのフィールドが再描画されないかについての情報がある場合、プログラマーは何らかの形で手動で指示します-これがエラーの主な原因となり、時間が費やされます 私が働いていたほとんどの大規模なオフィスでは、プログラマーがあらゆる種類のInventoryUpdatedEventを自分で送信し、場合によっては手動で入力することもありました。 これらのオフィスのいくつかは、数百万ドルを稼いでいますが、感謝ですか、それともそうですか？



独自のクラスReactiveProperty <T>を使用します。これは、必要なメッセージ送信のすべての操作を内部で隠します。 次のようになります。

 public class PlayerModel : Model { public ReactiveProperty<int> money = new ReactiveProperty<int>(); public ReactiveProperty<InventoryModel> inventory = new ReactiveProperty<InventoryModel>(); /* Using */ public void SomeTestChanges() { money.Value = 10; inventory.Value.capacity.Value++; } public void Subscription(Text text) { money.SubscribeWithState(text, (x, t) => t.text = x.ToString()); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これはモデルの最初のバージョンです。 このオプションは多くのプログラマーにとってすでに夢ですが、私はまだそれが好きではありません。 最初に気に入らないのは、値へのアクセスが複雑だということです。 この例を書いている間、私は混乱し、Valueを1か所で忘れてしまいました。まさにこれらのデータ操作が、行われ、モデルと混同されるすべての大部分を占めています。 4.x言語バージョンを使用している場合、これを行うことができます。

 public ReactiveProperty<int> money { get; private set; } = new ReactiveProperty<int>();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、これはすべての問題を解決するわけではありません。 私は簡単に書きたいです：inventory.capacity ++;。 モデルフィールドごとに取得しようとするとします。 セット; ただし、イベントをサブスクライブするには、ReactiveProperty自体へのアクセスも必要です。 明らかな不便さと混乱の原因。 どのフィールドを監視するかを指定するだけでよいという事実にもかかわらず。 そして、ここで私は私が好きだったトリッキーな操作を思いついた。



気に入ったら見てみましょう。



ルールを記述するプログラマーが処理する特定のモデルに挿入されるのはReactiveProperty自体ではありませんが、そのPValue静的記述子、より一般的なプロパティの相続人、フィールドを識別し、Modelコンストラクターの内部では、目的のタイプのReactivePropertyの作成と保存が隠されています。 最良の名前ではありませんが、実際に名前が変更されました。



コードでは、次のようになります。

 public class PlayerModel : Model { public static PValue<int> MONEY = new PValue<int>(); public int money { get { return MONEY.Get(this); } set { MONEY.Set(this, value) } } public static PModel<InventoryModel> INVENTORY = new PModel<InventoryModel>(); public InventoryModel inventory { get { return INVENTORY.Get(this); } set { INVENTORY.Set(this, value) } } /* Using */ public void SomeTestChanges() { money = 10; inventory.capacity++; } public void Subscription(Text text) { this.Get(MONEY).SubscribeWithState(text, (x, t) => t.text = x.ToString()); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは2番目のオプションです。 もちろん、モデルの一般的な祖先は、その記述子に従って実際のReactivePropertyを作成および抽出することを犠牲にして複雑でしたが、これは非常に迅速に、リフレクションなしで、またはむしろ、クラス初期化の段階で1回だけリフレクションを適用できます。 そして、これはエンジンの作成者によって一度行われた作業であり、その後、すべての人によって使用されます。 さらに、この設計により、ReactivePropertyに格納されている値ではなく、ReactiveProperty自体を操作しようとする偶発的な試みが回避されます。 フィールドの作成は煩雑ですが、すべての場合でまったく同じであり、テンプレートを使用して作成できます。



記事の最後に、どのオプションが一番好きかというアンケートがあります。

以下で説明するものはすべて、両方のバージョンで実装できます。

取引

プログラマーがモデルフィールドを変更できるようにしたいのは、エンジンで採用されている制限によって許可されている場合にのみ、つまりチーム内で、それ以降はモデルフィールドを変更できないようにすることです。 これを行うには、セッターはどこかに移動し、トランザクションコマンドが現在開いているかどうかを確認し、モデル内の情報を編集できるようにする必要があります。 これは非常に必要です。なぜなら、エンジンのユーザーは、通常のプロセスをバイパスするために奇妙なことを定期的に試み、エンジンのロジックを壊し、微妙なエラーを引き起こすからです。 私はこれを1、2回以上見ました。



モデルからのデータの読み取りと書き込みのために別のインターフェイスを作成すると、何らかの形で役立つと考えられています。 実際には、追加のファイルと退屈な追加操作でモデルが大きくなりすぎています。 プログラマーは、「特定の各機能、モデル、またはそのインターフェースが与えるべきこと」を最初に知り、常に考えることを強いられ、次に、これらの制限を回避しなければならない状況も発生します。出口には、これをすべて白で思いついたダルタニャンと、プロジェクトマネージャーの警備員である彼のエンジンの多くのユーザーがいます。 したがって、このような間違いの可能性をしっかりとブロックすることを好みます。 いわば、コンベンションの線量を減らしてください。



ReactivePropertyセッターには、トランザクションの現在の状態を確認する場所へのリンクが必要です。 この場所がclassCModelRootであるとしましょう。 最も簡単なオプションは、モデルコンストラクターに明示的に渡すことです。 RPropertyを呼び出すときのコードの2番目のバージョンは、これへのリンクを明示的に受け取り、そこから必要な情報をすべて取得できます。 コードの最初のバージョンでは、リフレクションを使用してコンストラクター内のReactiveProperty型のフィールドを実行し、さらに操作するためにこれへのリンクを提供する必要があります。 少し不便なのは、次のような各モデルのパラメーターを持つ明示的なコンストラクターを作成する必要があることです。

 public class PlayerModel : Model { public PlayerModel(ModelRoot gamestate) : base (gamestate) {} }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、モデルの他の機能については、モデルに親モデルへのリンクがあり、双連結構成を形成していると非常に便利です。 この例では、これはplayer.inventory.Parent == playerになります。 そして、このコンストラクタは回避できます。 どのモデルでも、次の親がその魔法の場所であることが判明するまで、親から魔法の場所へのリンクを取得してキャッシュできます。 その結果、宣言のレベルでは、これはすべて次のようになります。

 public class ModelRoot : Model { public bool locked { get; private set; } } public partial class Model { public Model Parent { get; protected set; } public ModelRoot Root { get; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

モデルがゲームステートツリーに入ると、このすべての美しさが自動的に満たされます。 はい、まだそこに到達していない新しく作成されたモデルは、トランザクションについて学習できず、それ自体で操作をブロックできませんが、トランザクションの状態が禁止されている場合、その後の状態になることはできず、将来の親のセッターはそれを許可しませんそのため、ゲームステートの整合性は影響を受けません。 はい、これはエンジンのプログラミング段階で追加の作業が必要になりますが、一方で、エンジンを使用するプログラマーは、何か間違ったことをしようとして手に入れるまで、それについて知る必要も考える必要もまったくありません。



トランザクションに関する会話が始まっているので、変更に関するメッセージは、変更が行われた直後に処理されるべきではなく、現在のコマンド内のモデルでのすべての操作が完了したときにのみ処理されます。 これには2つの理由があります。1つ目はデータの一貫性です。すべてのデータ状態が内部的に一貫しているわけではありません。おそらく、レンダリングを試みることはできません。 または、たとえば、ループ内で配列を並べ替えたり、モデル変数を変更したりするのが待ちきれない場合。 何百もの変更メッセージを受け取るべきではありません。



これを行うには2つの方法があります。 1つは、変数の更新をサブスクライブするときにトリッキーな関数を使用することです。これにより、トランザクションの終了のストリームが変数の変更のストリームに追加され、メッセージの後にのみ渡されます。 たとえば、UniRXを使用している場合、これは簡単です。 しかし、このオプションには多くの欠点があり、特に多くの不必要な動きが生じます。 個人的には、他のオプションが好きです。



各ReactivePropertyは、トランザクションの開始前の状態と現在の状態を記憶します。 変更および変更の修正に関するメッセージは、トランザクションの終了時にのみ作成されます。 変更のオブジェクトが何らかの種類のコレクションである場合、これにより、送信されたメッセージに発生した変更に関する情報を明示的に含めることができます。たとえば、リストにそのような2つのアイテムが追加され、その2つが削除されました。 単に何かが変わったと言って、受信者に再描画が必要な情報を求めて長さ1000項目のリストを分析することを強制する代わりに。

 public partial class Model { public void DispatchChanges(Command transaction); public void FixChanges(); public void RevertChanges(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このオプションは、エンジンの作成段階でより時間がかかりますが、使用コストは低くなります。 そして最も重要なことは、次の改善の可能性を開くことです。

モデルに加えられた変更に関する情報

モデルにもっと欲しい。 いつでも、アクションの結果としてモデルの状態に何が変わったのかを簡単かつ便利に見たいです。 たとえば、この形式では：

 {"player":{"money":10, "inventory":{"capacity":11}}}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ほとんどの場合、プログラマーにとって、コマンドの開始前と終了後、またはコマンド内のある時点でのモデルの状態の差分を確認すると便利です。 このためのいくつかは、チームの開始前にゲーム全体を複製し、比較します。 これにより、デバッグ段階で問題が部分的に解決されますが、製品でこれを実行することは絶対に不可能です。 2つのリスト間の取るに足らない差を計算する、その状態の複製は、くしゃみをするために途方もなく高価な操作です。



したがって、ReactivePropertyは現在の状態だけでなく、前の状態も保存する必要があります。 これにより、非常に有用な機会のグループ全体が生まれます。 第一に、そのような状況での違いの抽出は高速であり、私たちはそれをすべて静かに食品に捨てることができます。 第二に、かさばるdiffではなく、変更からコンパクトで小さなハッシュを取得し、それを別の同じゲーム状態の変更のハッシュと比較できます。 同意しない場合、問題があります。 第三に、コマンドの実行が実行に失敗した場合、いつでも変更をキャンセルし、トランザクションが開始された時点での損なわれていない状態を見つけることができます。 状態に適用されるチームと一緒に、この情報は、状況を正確に簡単に再現できるため、非常に貴重です。 もちろん、このためには、ゲーム状態のシリアル化とシリアル化解除を便利にする既製の機能が必要ですが、とにかく必要になります。

モデル変更のシリアル化

エンジンは、シリアル化とバイナリを提供し、jsonで-これは偶然ではありません。 もちろん、バイナリシリアル化はより少ないスペースを占有し、はるかに高速に動作します。これは、特に初期ブート中に重要です。 しかし、これは人間が読める形式ではありません。ここでは、デバッグの利便性を祈っています。 さらに、別の落とし穴があります。 ゲームが製品版になると、常にバージョンを切り替える必要があります。 プログラマーがいくつかの簡単な予防策に従い、ゲームの状態から不必要に何も削除しない場合、この移行を感じることはありません。 バイナリ形式では、明らかな理由で文字列フィールド名がありません。バージョンが一致しない場合は、古いバージョンの状態のバイナリを読み取って、同じjsonなどのより有益なものにエクスポートしてから、新しい状態にインポートして、バイナリにエクスポートする必要があります。書き留めてください、そして、このすべての作業が通常どおりに行われた後にのみ。 その結果、一部のプロジェクトでは、設定がシクロピーンのサイズを考慮してバイナリに書き込まれ、すでにjsonの形式で状態を前後にドラッグすることを好みます。 オーバーヘッドを評価して選択してください。

 [Flags] public enum ExportMode { all = 0x0, changes = 0x1, serverVerified = 0x2, //    ,    } /**    */ public partial class Model { public bool GetHashCode(ExportMode mode, out int code); public bool Import(BinaryReader binarySerialization); public bool Import(JSONReader json); public void ExportAll(ExportMode mode, BinaryWriter binarySerialization); public void ExportAll(ExportMode mode, JSONWriter json); public bool Export(ExportMode mode, out Dictionary<string, object> data); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Exportメソッドのシグニチャー（ExportModeモード、out Dictionary <string、object>データ）は、少々驚くべきものです。 そして、これは次のとおりです。ツリー全体をシリアル化すると、すぐにストリームに書き込むことができます。この場合は、StringWriterの簡単なアドオンであるJSONWriterに書き込むことができます。 しかし、変更をエクスポートするとき、それはそれほど単純ではありません。ツリーの奥深くに移動してブランチの1つに移動すると、そこから何かをエクスポートするかどうかがまったくわからないからです。 そのため、この段階で2つのソリューションを考え出しました。1つは単純なソリューションで、もう1つはより複雑で経済的なソリューションです。 より簡単な方法は、変更のみをエクスポートすることにより、すべての変更を辞書<string、object>およびList <object>からツリーに変換することです。 そして、何が起こったのか、あなたの好きなシリアライザーを養います。 これは、タンバリンと踊る必要のない単純なアプローチです。 しかし、その欠点は、ヒープへの変更をエクスポートするプロセスで、1回限りのコレクションの場所が割り当てられることです。 実際、この完全なエクスポートは大きなツリーを提供し、典型的なコマンドはツリーにほとんど変更を残さないため、スペースはあまりありません。



ただし、多くの人々は、ガベージコレクターをその荒らしとして供給することは、極端な必要なしには必要ないと考えています。 彼らのために、そして私の良心を落ち着かせるために、私はより複雑な解決策を用意しました：

 /**    */ public partial class Model { public void ExportAll(ExportMode mode, Type propertyType, JSONWriter writer, bool newModel = false); public bool DetectChanges(ExportMode mode, Stack<Model> ierarchyChanged = null); public void ExportChanges(ExportMode mode, Type propertyType, JSONWriter writer, Queue<Model> ierarchyChanges = null); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この方法の本質は、ツリーを2回通り抜けることです。 初めて、自分自身を変更したすべてのモデル、または子モデルに変更があるすべてのモデルを確認し、それらをすべて現在の状態でツリーに表示される順序でキュー<Model> ierarchyChangesに正確に書き込みます。 多くの変更はありません。キューは長くなりません。 さらに、呼び出し間でStack <Model>とQueue <Model>を保持することを妨げるものは何もないため、呼び出し中の割り当てはほとんどありません。



そして、ツリーを2回目に通過すると、毎回キューの先頭を見て、ツリーのこのブランチに入るか、すぐに進む必要があるかを理解することができます。 これにより、JSONWriterは他の中間結果を返さずにすぐに書き込むことができます。



後でツリーへの変更のエクスポートはデバッグまたは例外でクラッシュする場合にのみ必要であることがわかるので、この複雑さは実際には必要ではない可能性が非常に高いです。 通常の操作中は、すべてがGetHashCode（ExportModeモード、out intコード）に制限され、これらすべての喜びはまったく異質です。



モデルを複雑にし続ける前に、これについて話しましょう。

なぜそんなに重要なの

すべてのプログラマーは、これは非常に重要だと言いますが、通常誰も信じていません。 なんで？



第一に、すべてのプログラマーは古いものを捨てて新しいものを書く必要があると言っているからです。 資格に関係なく、それだけです。 これが真実であるかどうかを確認する管理上の方法はなく、実験は通常高価すぎます。 マネージャーは1人のプログラマーを選択し、彼の判断を信頼することを余儀なくされます。 問題は、そのようなアドバイザーは通常、経営陣が長い間働いてきたアドバイザーであり、そのアイデアを実現できたかどうかによって評価するということです。 したがって、これは他の人のアイデアや異質なアイデアがどれほど優れているかを知る理想的な方法でもありません。



第二に、すべてのモバイルゲームの80％は、生涯で500ドル未満です。 したがって、プロジェクトの開始時には、管理には他の問題があり、さらに重要なのはアーキテクチャです。 しかし、プロジェクトの最初の段階で下された決定は人々を人質にし、6ヶ月から3年までは手放しません。 リファクタリングを行い、すでにクライアントがいる作業中のプロジェクトで他のアイデアに切り替えるプロセスは、非常に難しく、費用がかかり、リスクの高いビジネスです。 最初のプロジェクトで、通常のアーキテクチャに3か月を投資することは容認できない贅沢のように思えますが、新しい機能での更新を数か月延期するコストについてはどう思いますか？



第三に、「それがどうあるべきか」というアイデア自体が理想的であっても、その実装にどのくらい時間がかかるかはわかりません。 プログラマーのクールさに費やす時間の依存性は非常に非線形です。 聖職者は、後輩ほど速くない単純なタスクを実行します。 たぶん1.5回。 しかし、各プログラマーには独自の「複雑さの限界」があり、それを超えるとその効果は劇的に低下します。 かなり複雑な建築作業を実現する必要があり、家でインターネットをオフにして1か月分の食事を注文するという問題に完全に集中する必要さえあったときに、私は人生の中で問題を抱えていました。 、私は3日でこの問題を解決しました。 誰もがそのようなことをキャリアで覚えていると思います。 そして、ここにキャッチがあります！ 事実、素晴らしいアイデアを思いついた場合、その新しいアイデアはおそらくあなたの個人的な複雑さの限界のどこかにあり、それより少し遅れている可能性があります。 そのようなことに繰り返し燃えている経営者は、新しいアイデアを吹き始めます。 そして、自分でゲームを作ると、あなたを止める人はいないので、結果はさらに悪くなる可能性があります。



しかし、それでは、どのようにして優れたソリューションを使用することができますか？ いくつかの方法があります。



まず、各企業は、以前の雇用主ですでにこれを行っている既製の人を雇いたいと考えています。 これは、実験の負担を他の人に移す最も一般的な方法です。



第二に、最初に成功したゲームを作成し、丸lurみし、次のプロジェクトを開始した企業または人々は、変更の準備ができています。



第三に、給与のためではなく、プロセスの喜びのために何かをすることがあることを正直に認めてください。主なことは、この時間を見つけることです。



第4に、ゲーミング会社の主要な資金を構成するのは、実績のあるソリューションとライブラリのセットであり、人々と一緒です。これは、一部のキーパーソンが退職してオーストラリアに移動したときに残るものです。



最も明らかな理由ではありませんが、最後になります。それは非常に有益だからです。優れたソリューションは、新しい機能の作成、デバッグ、エラーの検出にかかる時間を複数回削減することにつながります。例を挙げましょう。2日前、クライアントは新しい機能を実行していました。その可能性は1000分の1です。つまり、QAはそれを再現するために拷問します。すべてが崩壊する前に状況を再現し、ブレークポイントでクライアントを1行キャッチするのにどれくらい時間がかかりますか？たとえば、10分あります。

モデル

モデルツリー

モデルは多くのオブジェクトで構成されています。プログラマーによって、それらを接続する方法が異なります。最初の方法は、モデルが置かれている場所によって識別される場合です。これは、モデルへの参照がModelRootの単一の場所に属している場合、非常に便利で簡単です。おそらく、場所から場所へと移動することもできますが、異なる場所からの2つのリンクがそれにつながることはありません。これを行うには、あるモデルからそこにある他のモデルへのリンクを処理するModelProperty記述子の新しいバージョンを導入します。コードでは、次のようになります。

 public class PModel<T> : Property<T> where T:Model {} public partial class PlayerModel : Model { public PModel<InventoryModel> INVENTORY = new PModel<InventoryModel>(); public InventoryModel inventory { get { return INVENTORY.Value(this); } set { INVENTORY.Value(this, value); } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

違いは何ですか？このフィールドに新しいモデルが追加されると、そのモデルが追加されたモデルがその親フィールドに書き込まれ、削除されると、親フィールドがリセットされます。理論的には、すべてがうまくいきますが、多くの落とし穴があります。最初の-それを使用するプログラマは、間違える可能性があります。これを回避するために、さまざまな角度からこのプロセスに隠れたチェックを課します。

1. PValueを修正して、値のタイプをチェックし、モデルへの参照を保存しようとするときに専門家が誓うようにします。これには、混乱しないように、異なる構造を使用する必要があることを示します。もちろん、これは実行時チェックですが、最初の起動試行で誓うので、実行されます。
2. PModel Parent - , . . , .

これにより副作用が発生します。そのようなモデルをある場所から別の場所に移動する必要がある場合、最初にその場所を削除し、次にそれを2番目に追加する必要があります。しかし、これは実際にはめったに起こりません。



モデルは厳密に定義された1つの場所にあり、その親への参照を持っているため、新しいメソッドを追加できます。ModelRootツリー内のどの方向にあるかを知ることができます。これはデバッグには非常に便利ですが、一意に識別できるようにするためにも必要です。たとえば、別の同じゲーム状態でまったく同じモデルを見つけるか、サーバーに送信されたコマンドで、コマンドに含まれるモデルへのリンクを指定します。次のようになります。

 public class ModelPath { public Property[] properties; public Object[] indexes; public override ToString(); public static ModelPath FromString(string path); } public partial class Model { public ModelPath Path(); } public partial class ModelRoot : Model { public Model GetByPath(ModelPath path); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、なぜ、ある場所に根ざしたオブジェクトを持つことは不可能ですが、別の場所からそれを参照することは不可能なのですか？また、JSONからオブジェクトをデシリアライズしていることを想像すると、ここにはまったく別の場所に根ざしたオブジェクトへのリンクがあります。そして、そのための場所はまだありません。デシリアライズの床を通してのみ作成されます。おっとマルチパス逆シリアル化を提供しないでください。これがこの方法の制限です。したがって、2番目の方法を考えます。



2番目の方法で作成されたすべてのモデルは1つの魔法の場所で作成され、ゲーム状態の他のすべての場所ではリンクのみが挿入されます。逆シリアル化中にオブジェクトへの参照が複数ある場合、オブジェクトは魔法の場所に最初にアクセスしたときに作成され、同じオブジェクトへの後続の参照がすべて返されます。他の機能を実装するために、ゲームには複数のゲーム状態を設定できるため、魔法の場所は一般的なものではなく、たとえばゲーム状態に配置する必要があります。そのようなモデルへの参照には、PPersistent記述子の別のバリエーションを使用します。モデル自体は、Persistent：Modelによってさらに特別なものになります。コードでは、次のようになります。

 public class Persistent : Model { public int id { get { return ID.Get(this); } set { ID.Set(this, value); } } public static RProperty<int> ID = new RProperty<int>(); } public partial class ModelRoot : Model { public int nextFreePersistentId { get { return NEXT_FREE_PERSISTENT_ID.Get(this); } set { NEXT_FREE_PERSISTENT_ID.Set(this, value); } } public static RProperty<int> NEXT_FREE_PERSISTENT_ID = new RProperty<int>(); public static PDictionaryModel<int, Persistent> PERSISTENT = new PDictionaryModel<int, Persistent>() { notServerVerified = true }; /// <summary>      Id-. </summary> public PersistentT Persistent<PersistentT>(int localId) where PersistentT : Persistent, new(); /// <summary> C    Id. </summary> public PersistentT Persistent<PersistentT>() where PersistentT : Persistent, new(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

少し面倒ですが、使用できます。ストローを置くために、PersistentはModelRootパラメーターを使用してコンストラクターを固定できます。これにより、このModelRootのメソッドを使用せずにこのモデルを作成しようとすると、アラームが発生します。



コードで両方のオプションを使用すると、疑問が発生します。2番目のオプションが考えられるすべてのケースを完全にカバーしている場合、なぜ最初のオプションを使用するのですか？



答えは、ゲームの状態は、まず第一に、人々が読めるものでなければならないということです。可能であれば、最初のオプションが使用される場合、どのようになりますか？

 { "persistents":{}, "player":{ "money":10, "inventory":{"capacity":11} } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして今、2番目のオプションのみが使用された場合、次のようになります。

 { "persistents":{ "1":{"money":10, "inventory":2}, "2":{"capacity":11} }, "player":1 }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

個人的にデバッグするには、最初のオプションを好みます。

モデルプロパティへのアクセス

最終的にリアクティブプロパティストレージ施設へのアクセスは、モデルの内部に隠れていることが判明しました。最終モデルにコードを追加したり、リフレクションを追加したりせずに、迅速に機能するように機能させる方法はあまり明確ではありません。よく見てみましょう。



辞書について最初に知っておくと便利なことは、辞書のサイズに関係なく、辞書からの読み取りにそれほど時間がかからないことです。各タイプのモデルに含まれるフィールドの説明が割り当てられたモデルでプライベート静的ディクショナリを作成し、モデルの構築時に一度アクセスします。型コンストラクターで、型の説明があるかどうかを確認し、ない場合は作成し、ある場合は完成したものを作成します。したがって、説明はクラスごとに1回だけ作成されます。説明を作成するとき、各静的プロパティ（フィールドの説明）に、リフレクションを通じて抽出されたデータ（フィールドの名前、およびこのフィールドのデータストアが配列内にあるインデックス）を入れます。このようにフィールドの説明を介してアクセスすると、その記憶域は、既知のインデックスで、つまり迅速に配列から取り出されます。



コードでは、次のようになります。

 public class Model : IModelInternals { #region Properties protected static Dictionary<Type, Property[]> propertiesDictionary = new Dictionary<Type, Property[]>(); protected static Dictionary<Type, Property[]> propertiesForBinarySerializationDictionary = new Dictionary<Type, Property[]>(); protected Property[] _properties, _propertiesForBinarySerialization; protected BaseStorage[] _storages; public Model() { Type targetType = GetType(); if (!propertiesDictionary.ContainsKey(targetType)) RegisterModelsProperties(targetType, new List<Property>(), new List<Property>()); _properties = propertiesDictionary[targetType]; _storages = new BaseStorage[_properties.Length]; for (var i = 0; i < _storages.Length; i++) _storages[i] = _properties[i].CreateStorage(); } private void RegisterModelsProperties(Type target, List<Property> registered, List<Property> registeredForBinary) { if (!propertiesDictionary.ContainsKey(target)) { if (target.BaseType != typeof(Model) && typeof(Model).IsAssignableFrom(target.BaseType)) RegisterModelsProperties(target.BaseType, registered, registeredForBinary); var fields = target.GetFields(BindingFlags.Public | BindingFlags.Static); // | BindingFlags.DeclaredOnly List<Property> alphabeticSorted = new List<Property>(); for (int i = 0; i < fields.Length; i++) { var field = fields[i]; if (typeof(Property).IsAssignableFrom(field.FieldType)) { var prop = field.GetValue(this) as Property; prop.Name = field.Name; prop.Parent = target; prop.storageIndex = registered.Count; registered.Add(prop); alphabeticSorted.Add(prop); } } alphabeticSorted.Sort((p1, p2) => String.Compare(p1.Name, p2.Name)); registeredForBinary.AddRange(alphabeticSorted); Property[] properties = new Property[registered.Count]; for (int i = 0; i < registered.Count; i++) properties[i] = registered[i]; propertiesDictionary.Add(target, properties); properties = new Property[registered.Count]; for (int i = 0; i < registeredForBinary.Count; i++) properties[i] = registeredForBinary[i]; propertiesForBinarySerializationDictionary.Add(target, properties); } else { registered.AddRange(propertiesDictionary[target]); registeredForBinary.AddRange(propertiesForBinarySerializationDictionary[target]); } } CastType IModelInternals.GetStorage<CastType>(Property property) { try { return (CastType)_storages[property.storageIndex]; } catch { UnityEngine.Debug.LogError(string.Format("{0}.GetStorage<{1}>({2})",GetType().Name, typeof(CastType).Name, property.ToString())); return null; } } #endregion }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このモデルの祖先で宣言された静的プロパティ記述子にはすでにストレージインデックスが登録されている可能性があり、Type.GetFields（）からプロパティを返す順序は保証されないため、設計は少し単純です。時には、あなた自身を監視する必要があります。

コレクションのプロパティ

モデルツリーのセクションでは、前述されていない構造に気付くことができます。PDictionaryModel<int、Persistent>-コレクションを含むフィールドの記述子。コレクション用の独自のリポジトリを作成する必要があることは明らかです。このリポジトリには、トランザクションの開始前のコレクションの外観と現在の外観に関する情報が格納されます。ここの水中の小石は、ピーターIの下のサンダーストーンのサイズです。2つの長い辞書を手に持っているので、それらの間の差分を計算するのは非常に高価な作業です。このようなモデルは、メタに関連するすべてのタスクに使用する必要があると思います。つまり、それらは迅速に動作するはずです。 2つの状態を保存し、それらを複製して比較するのに費用がかかるのではなく、トリッキーなフックを作成します-辞書の現在の状態のみがストアに保存されます。置換された要素の古い値。最後に、辞書に追加された新しいキーのセットが保存されます。この情報は簡単かつ迅速に入力されます。必要なすべての差分を簡単に生成でき、必要に応じて以前の状態を復元するだけで十分です。コードでは、次のようになります。

 public class DictionaryStorage<TKey, TValues> : BaseStorage { public Dictionary<TKey, TValues> current = new Dictionary<TKey, TValues>(); public Dictionary<TKey, TValues> removed = new Dictionary<TKey, TValues>(); public Dictionary<TKey, TValues> changedValues = new Dictionary<TKey, TValues>(); public HashSet<TKey> newKeys = new HashSet<TKey>(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

リストに同じすばらしいリポジトリを思い付くことができなかった、または十分な時間がないので、2つのコピーを保持します。差分のサイズを最小限に抑えるには、追加のアドオンが必要です。

 public class ListStorage<TValue> : BaseStorage { public List<TValue> current = new List<TValue>(); public List<TValue> previouse = new List<TValue>(); //        public List<int> order = new List<int>(); //       . }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

合計

何をどのように受け取りたいかが明確にわかっている場合は、数週間ですべてを書くことができます。同時に、ゲームの開発速度は劇的に変化するため、試してみたところ、優れたエンジンがなければ自分のゲーム制作ゲームを開始することすらできませんでした。なぜなら、最初の月に私への投資が明らかに報われたからです。もちろん、これはメタにのみ適用されます。ゲームプレイは昔ながらの方法で行わなければなりません。



記事の次の部分では、コマンド、ネットワーク、およびサーバー応答の予測について説明します。また、私にとって非常に重要な質問もいくつかあります。あなたの答えが括弧で与えられたものと異なる場合、私は喜んでコメントでそれらを読むか、あなたが記事を書くことさえあるでしょう。回答ありがとうございます。



PS多数の構文エラーに関する協力と指示の提案は、PMでお願いします。