Techlide日記：新しいモバイルPvPの開発の後半

私は1年働いているPixonicのチームリーダーです。 新しいプロジェクトの開始と開発について、以前にHabréについての記事を書きました。 さらなる制作の過程で、さらに6か月後、私は多くの興味深い経験を蓄積しました。それを再び共有したいと思いました。 今回は、モバイルクライアントで機能を構築し、コードを柔軟な状態に維持するプロセスに焦点を当てます。



私は、大多数が少なくとも一度はある種のマルチプレイヤーゲームを開始したと確信しています。 開始時に、クライアントは原則としていくつかの魔法のメッセージを書き込み、数秒後に（1人の有名なデスクトップシューティングゲームの場合-数分）、プレーヤーはメインメニューに移動します。 しかし、起動プロセスは、プレイヤーの介入なしに非常に迅速に発生する膨大な数のステージで構成されています。

• プレーヤーに最適な地域の選択。
• 変更を確認し、ゲームの新しい設定をダウンロードします。
• 接続の確立と認証の成功。
• 最新のプレーヤープロファイルデータの取得。
• プレーヤーを技術的な詳細に没頭させることのない他の多くのアクション。

さらに、この機能はすぐに完全に記述されるのではなく、プロジェクトの全期間を通じて徐々に拡張され、継続的に改善されます。 設計者の挑戦的なタスクの1つは、 疎結合や再利用性などの優れた特性を失うようなコードの開発を防ぐことです。



しかし、TKの小さなニュアンスが原因で、簡潔で多目的に見えるコードモジュールがモンスターに変わることがよくあります。 一言で言えば、コードでマカロニを許可するべきではありません-変更が来てもすぐに解かれてはいけません 。



この設計上の問題を解決するのは私次第であり、すでに1年の開発の後、ゲームクライアントモジュールの設計を導いたロジックについて説明します（関数が追加または変更されると、すべての素材は時系列になります）。



一部の人にとっては、この資料は固い原則の単なる別の解釈のように思えるかもしれませんが、実際の大規模な実践の例は、彼らの理解を統合し改善するのに役立ちます。



アプリケーションモジュールを説明するたびに、接続図に追加します。 図では、モジュールは矢印で接続されます。これは、あるモジュールを別のモジュールが単独で所有および使用することを意味します。 スレーブモジュールにはユーザー情報がありません。 このルールに従って、アーキテクチャは常にツリーのようになります。 私の意見では、ツリーは柔軟なコードとその正しい拡張のシンボルです。



しかし、続行する前に、もう一度予約する必要があります。

• 公式リリースの前に、ゲームデザインの機能を明確にしたり、ゲームのフレームを表示したりすることはできません。
• 指定されたコードは、プロジェクトのコードの正確なコピーではありません（これは、例を簡単にするために行われました）。
• これらのプラクティス、ヒント、およびコードは、他のプロジェクトには適用されない可能性があります（ただし、要件とテクノロジスタックを使用して、効果的に機能します）。

それでは、最下層から始めましょう。ゲームサーバーとモバイルクライアントの相互作用です。

トランスポート層

マルチプレイヤーゲームには、統合された、または独立して記述されたデータトランスポートがあります。送信、整合性、複製に対する反対、および送信データの不正な順序を担当するネットワークプロトコルがあります。



私たちの新しいプロジェクトでは、APIを普遍的かつ同期的にするため、および実装を置き換える可能性を高めるために、最初から実装を抽象化することにしました。 まず、ゲームプレイ中の高頻度配信プロトコル。



低レベルフォトンネットワークを使用して、ゲームサーバーからクライアントにデータを転送し、高頻度でゲーム中に直接送り返します。 コードの抽象化の作成は次のようになりました。

public interface INetworkPeer { PeerStatus PeerStatus { get; } //  int Ping { get; } IQueue<byte[]> ReciveQueue { get; } //   void Connect(); void Send(byte[], bool sendReliable); void Update(); //    ,  Service  PhotonPeer void Disconnect(); } public enum PeerStatus { Disconnected = 0, Connecting = 1, Connected = 2, }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

「スレッドセーフ」、または必要に応じて「スレッドセーフ」は、インターフェイスを介して読む必要があります。 お気づきかもしれませんが、INetworkPeer APIは同期的であり、Updateメソッドは、呼び出し元の実行のコンテキストで作業の一部が行われることを示唆しています。



それは私たちに何を与えましたか



シミュレーションコードでの作業中、新しい機能を使用する最も速い方法は、作業中のコンピューターに変更されたコードでローカルサーバーを展開しないことです。 このインターフェイスの2番目の実装を記述する機会がありました。その中で、すでに共通のサブモジュールのコードを使用していたため、クライアント自体がサーバーになります。



少し後に、この置換を使用して、変更されたルールを使用してローカルシミュレーションを作成しました（したがって、トレーニングシステムはクライアントで動作します）。 このモードは、サーバーを不必要にロードせず、最初の段階でインターネットプレーヤーを必要としません。これにより、通過ファンネルが改善されます。



トランスポートの他の実装で実験を行い、必要に応じて変更します。 主な理由は、サーバーの容量とパフォーマンスを向上させるためのメモリとシステムコールの処理の最適化です。

逆シリアル化ストリーム

次のタスクは、受信したバイト配列をデータ転送オブジェクトに変換することです（GameClientMessageタイプ）。 このようなインターフェイスの背後にこれらの責任を隠しました（このインターフェイスはINetworkPeerの実装に関連付けられていないことに注意してください）。

 public interface INetworkPeerService { float Ping { get; } NetworkServiceStatus Status { get; } //     void Connect(INetworkPeer peer); void SendMessage(GameClientMessage message, bool sendReliable); //   DTO ,   . void Disconnect(); bool HasMessage(); // ,    . GameClientMessage DequeueMessage(); //    } public enum NetworkServiceStatus { Disconnected = 0, Connecting = 1, Connected = 2, }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

INetworkPeerServiceはINetworkPeerのタイプを知っており、それをConnectメソッドで使用し、INetworkPeerの実装は同時にINetworkPeerServiceについて何も知らないことに注意してください。



それは私たちに何を与えましたか



この抽象化内で、メッセージのシリアル化に関連する機能をカプセル化し、安全に開発できます。 私たちの場合、内部には次の責任の構成があります。

• LZ4アルゴリズムによる圧縮。
• プロトコルバッファーを使用したシリアル化。
• メモリ使用を最適化するための配列プルとDTO。
• 別のスレッドでのコード実行。

最後の点は非常に重要です。フレームレートは、フレームごとに受信したメッセージの数に依存しないためです。 また、オブジェクトのプールを拡張する操作の自発的な労力から保護されています。

ネットワークモデル、その状態、およびハンドシェイク手順

ゲームに接続するとき、単に接続を確立するだけでは十分ではありません。 ゲームサーバーは次のことを理解する必要があります：あなたが誰であるか、なぜあなたが接続されているか、あなたとどうするか。 また、クライアントでは、状態のシーケンスが変更される必要があります。

1. サーバーへの接続を開始します。
2. 接続が成功するまで待つか、エラーを返します。
3. 意図に関する情報を送信します（プレイヤー選択サービスが私にどのようなゲームを送ったか）。
4. サーバーからの肯定的な応答を待って、そこからセッションIDを取得します。
5. ゲームに関連する作業を開始し、入力を送信し、受信したデータへのアクセスを提供します。
6. サーバーから切断された場合、必要な状態を受け入れます。

私の意見では、州の設計パターンはここで明確に示唆しています。 以下の例からわかるように、このマシンはユーザーから閉じられており、その責任範囲で決定を下すことができます。

 public interface IGameplayNetworkModel { NetworkState NetworkState { get; } //     int SessionId { get; } //       IQueue<GameState> GameStates { get; } //    float Ping { get; } void ProcessNetwork(TimeData timeData); //Update ,  , Service void ConnectToServer(INetworkPeer peer, string roomId, string playerId); //INetworPeer    INetworkPeerService.Connect(peer). void SendInput(IEnumerable<InputFrame> input); void ExitGameplay(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

IGameplayNetworkModelインターフェイスの実装の場合、コンストラクターは次のようになります。

 public GameplayNetworkModel(INetworkPeerService networkPeerService)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、低レベルエンティティのコンストラクターから高レベルエンティティへの古典的な注入です。 INetworkPeerServiceはGameplayNetworkModelまたはIGameplayNetworkModelについても何も知りません。 NetworkPeerServiceとGameplayNetworkModelの両方がアプリケーション用に一度作成され、クライアントが動作する間ずっと存在します。 IGameplayNetworkModelを使用して作業する上位レベルのユーザーは、INetworkPeerServiceなどの自分から隠されたエンティティについて知る必要はありません。



それは私たちに何を与えましたか



最も重要なことは、このインターフェイスのユーザーがネットワーク状態の操作のすべての詳細から保護されることです。 違いは何ですか、入力を送信できず、ゲームに関する最新のデータを取得できず、接続損失ウィンドウが表示されるはずです。 主なものは、実装を信頼することです。



状態パターン自体は、機能を隠すための非常に強力なツールです。 要件が複雑になるにつれて、新しい状態を疎実行チェーンに追加するのは非常に簡単です。 次の例で、このパターンに複数回言及します。

ゲームゲームモデル。 ゲームデータの補間と保存のカプセル化

Unityでは、Update（）の呼び出しを通じて、コードは実行制御を取得します。ネットワークゲームでは、通常3つのこと（簡略化）を行う必要があります。

1. サーバーに送信するための入力を収集します（存在する場合、およびネットワークステータスが許可する場合）。
2. ネットワークの状態を更新し、到着し、このフレームの処理の準備ができているものを受け入れます。
3. データを収集し、視覚化を開始します。

ただし、モバイル接続が不十分で配信が保証されていない状況での画像の滑らかさのために戦うには、さらに次の機能を実装する必要があります。

• プレーヤー入力の収集と保存（レンダーのフレームレートが送信頻度と等しくないため）。
• 配信時に入力データを複製して、配信の信頼性を向上させます。
• 到着した世界の州とその注文の保管。
• 受信した状態に基づいて現在のフレームを構築するために必要なデータの補間。
• DTOタイプからの抽象化。
• 送信頻度の統計を維持します。
• 時間の操作：サーバー上の時間を分析し、データを一時的な問題に適合させます（入力遅延を減らすために時間を高速化し、接続が低下したりデータが欠落した場合に時間を一時的に遅くしたりシフトしたりします）。

私たちの場合、これはゲームプレイモデルのインターフェースの背後にカプセル化されています。

 public interface IGameplayModel : IDisposable { int PlayerSessionId { get; } //      ICurrentState CurrentState { get; } //      ,   . void SetCurrentInputTo(InputData input); //    . void ConnectToGame(string roomId, string playerName, string playerId, INetworkPeer networkPeer); //    void ExitGamePlay(); //  void UpdateFrame(TimeData timeData); //     . }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

UpdateFrameメソッドの実装では、IGameplayNetworkModel.ProcessNetwork（timeData）が適切なタイミングで呼び出されます。 実装コンストラクターは次のようになります。

 public GameplayModel(IGameplayNetworkModel gameplayNetworkModel)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それは私たちに何を与えましたか



これはすでにゲームの本格的なネットワーククライアントモデルです。 理論的には、プレイするために他に必要なものはありません。 この抽象化の別のユーザー実装をコンソールアプリケーションとして作成することをお勧めします。 dotTraceおよびdotMemoryツールは私たちの助けになりました。Unityプロファイラーよりもはるかに視覚的であり、さらに、どのような問題があるかを伝えることができます。



その過程で、このインターフェイスの実装をいくつか作成しました。これにより、非常に安価に有用な機能が提供されました。

• リプレイを記録および再生します。 書き込み時に、実装は受信したデータを別のバッファーに保存します。 また、再生中、実装はユーザー入力を無視し、IGameplayNetworkModelインスタンスをまったく必要とせずに、単にバッファーから失われます。
• 技術的なタスクとテストの接続。 抽象化できるすべてのものは、多くの場合自動化できます。統合テストは簡潔に見え、高レベルのツールのセットに沿ってドラッグしません。 また、このモデルを使用して、テストルームを作成し、特定のバッチ内のゲームデザイナーから変更された構成を転送します。

一般的なアプリケーションモデル。 アプリケーションの開始をカプセル化し、ゲームに再接続します

ある時点で、私たちのチームは、プレイヤーが何らかの形で戦闘から姿を消した場合、プレイヤーをゲームに再接続するタスクを受け取りました。 インターネットがオフになっている状態ですべてが明らかな場合、アプリケーションのシャットダウンが失敗し、その後再起動した場合、この機能がどのように機能するかはすぐにはわかりませんでした。 IGameplayModel状態のコレクションを拡張するだけでは不十分でした。そのインターフェイスは外部からの制御を明確に示しているためです。



解決策は次のとおりです。ゲームプレイモデルの状態を監視し、必要に応じて再接続を実行する、より高いレベルの状態マシンを作成することです。 さらに、開始時に、このマシンの初期状態は未完のゲームの記録をチェックし、もしあれば、ゲームへの接続を試みて続行します。 そして最後のケースでは、そのようなゲームがサーバー上にもう存在しない場合、標準の準備状態に戻ります。



ステータスリスト：

• ゲーム記録の検証を伴うアプリケーションの開始。
• 仕事の準備。
• 状態は「ゲームの進行中です。
• 再接続ステータス

当時のこの最高レベルのモデルのインターフェースは次のようになりました。

 public interface IAppModel : IDisposable { ApplicationState ApplicationState { get; } //    .             . GameplayData GamePlayData { get; } //      void StartGamePlay(GameplayStartParameters parameters); void PlayReplay(Replay replay); void RefreshRoomsList(string serverAddress); // ,      void ExitGamePlay(); void SetLastGamePlayInput(Vector2 input, ISafeList<SkillInputData> skillButtonStates); //       . void SelectHero(int dropTeamMemberId, bool isConfirmed); //     void Update(TimeData timeData); // ,    . }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それは私たちに何を与えましたか



これにより、セッション間で再接続するためのエレガントなソリューションだけでなく、初期化段階を拡張するツールも提供されました。 どういうわけか、このツールを最大限に活用した方法を示します。

予備結果

責任を分離し、責任をカプセル化することにより、アプリケーションは多くの機能を組み合わせます。 すべてのコンポーネントは交換可能であり、一部の変更は他のコンポーネントにほとんど影響しません。 依存関係は、より広い要素からより特化した要素へのリンクのチェーンとしてチャートに表示できます。



実際には、このような設計は非常に優れたサポートとコードの可変性インジケーターを提供します。 私たちにとって（すべての締め切り、厳しい締め切り、通常の生産/機能の変更を考慮する）、コードの変更は軽量であり、リファクタリングタスクは数週間で計算されません。



ちなみに、2番目のサーバーとの対話のトピックについてはまったく触れていないことに気づいたかもしれません。

• ユーザーのログイン方法。
• クライアントが現在のプレーヤーに関するデータを受信する方法。
• 戦闘に入る手順はどうですか。
• どうすれば戦闘の結果を得ることができますか？
• 2つのサーバーへの2つの接続を考慮して接続を復元する方法。

このクライアントの責任のセットは、アプリケーションモデルレベルの依存関係ツリーにも組み込まれ、タイプと関係の別個の大規模なブランチを形成します。 しかし、次回については。