技術日記：モバイルPvP開発の半年

2017年3月、小さなチームを編成し、新しい有望なプロジェクトの開発に着手しました。 特別な詳細がなければ、このタスクは面白くて魅力的だったと言えます-モバイル、同期、チームPvP。 7か月にわたる積極的な開発の後、他のプロジェクトや部門の同僚にPixonicの技術的な詳細を伝えたかったので、彼らのためにプレゼンテーションを準備しました。



技術チームとして、私たちが直面したタスクと問題、それらを解決する方法と理由を説明します。 プロジェクトに機能を追加するために反復アプローチを使用し、現在実装しています：iOSおよびAndroidのPvP（両方のプラットフォームが同じサーバーで再生されます）。 キャラクターのセット、3ダースのゲームの仕組み、ボット。 マッチメイキング; メタ機能のセット（キャラクターのカスタマイズ、レベリングなど）。 全世界へのスケーラビリティの問題を解決しました。



行きましょう。



免責事項

しかし、私はすぐに、記事に記載されているソリューションがすでに多くの状況で構成されている歴史的な現象と事実であるという予約をしなければなりません：製品のビジネスとゲームの設計要件、期限、チームの可能性、最初のいくつかの問題の未知性。 これはベストプラクティスではありませんが、決して冗長な経験ではありません。

痛い（、）楽しい

開発が始まる前でさえ、私たちはすでに直面しなければならないいくつかの困難をすでに提示していました。 すなわち：

• 同期PvP これは決して簡単なことではありません。チームが経験のない技術をすべて選択して実装する必要があります。 問題を解決するための技術の組み合わせは多数あります。画像の滑らかさ、遅延の隠蔽、不正行為、シミュレーションパフォーマンス（サーバーまたはマスタークライアント）、MTUに入る問題、およびトラフィックのコストです。 メッセージ配信ラグはキャンセルできませんが、メッセージはできるだけ早く配信する必要があり、それらの配信は互いに依存しないようにする必要があります。 これらの理由により、TCPプロトコルを使用できませんでした。UDPを使用すると、一連のケースが追加され、それらも処理する必要があります。
• モバイルプラットフォーム 。 パフォーマンスと制限に関する追加作業（例：RAMの最大使用）。 また、常にインターネットが不安定でpingが不十分なプレイヤーがいることに注意する必要があります-無視することはできません。
• 世界中のどこからでも入手可能 。 プレイヤーがサーバーの選択を気にせず、アプリケーションがデバイスの位置を自動的に理解し、最適な接続ポイントを見つけることが理想的です。
• ジャンルの詳細 。 道徳的に、私たちは、誰もまだ実装していないメカニックが確実にあり（特に技術的な制限に投影されている）、すべてのバンプを備えたパイオニアになる必要があることを確信していました。
• 技術スタックの幅 。 機能要件を見ると、少なくとも3つのサブプロジェクトが1つのプロジェクトに統合されていることを確認できます。ゲームクライアント、ゲームサーバー、および一連のメタマイクロサービスです。 機能の同期リリースのためにチームを同期することは困難なタスクであることが判明しました。 別の問題は、コードを保存する方法、手探りして再利用する方法でした。

次に、「問題-解決策」という形で状況を説明しようとしました。

コードの保存と共有

既に述べたように、プロジェクトは3つのサブプロジェクトで構成されています。

• Unityクライアント;
• Photon（PUNではない）トランスポートを使用するWindowsゲームサーバー
• メタゲーム（Java）のサービスセット。

すべてのCIプロセスがより高価になり、時間がかかるため、すべてを1つのgitリポジトリに格納するとプラスよりもマイナスが多いと考えました。 その結果、3つのリポジトリがあります。



プロトコルバッファを使用して、3つすべてのサブプロジェクト間でメッセージを交換します。 したがって、これらのメッセージの.protoファイルと生成されたコードファイルをどこかに保存する必要があります（ちなみに、生成されたファイルをコミットすることはお勧めできませんが、Unityでは開くときにコンパイルの回数が減り、時間を節約できます）。 さらに、それらはプロトコルごとに異なる必要があります。サーバーとクライアントは異なる引数を必要とするため、パケットを再利用する意味はありません。 これらのファイルをすべてのプロジェクトに受け取る方法がありました。 gitサブモジュールで解決しました。 メインプロジェクトの3つのペアのそれぞれの間で、追加のリポジトリを開始し、サブモジュールとしてメインプロジェクトに追加しました。 現在、6つのリポジトリがあります。



シミュレーションのデバッグと、サーバーに縛られずにゲームシミュレーションを実行する機能を高速化するために、シミュレーションコードを分離しました。 これにより、多くの機会が与えられました-時間の加速を備えたコンソールアプリケーションとして数百のゲームの起動をプロファイリングしたり、たとえば、ローカルの戦闘訓練作業のためにUnityクライアントでシミュレーションを使用したりします。 これは、制作自体にとっても非常に便利です。新しいゲーム機能を作成するプログラマーはすぐにUnityをプレイでき、ローカルサーバーを展開する必要さえありません。 シミュレーションコードをクライアントとゲームサーバーに配置するには、別のサブモジュールに移動する必要がありました。



しばらくして、ゲーム構成の変更を保存および追跡する必要がありました。その必要な部分はサブプロジェクトから分岐し、逆シリアル化のプロトスキームを含む別のサブモジュールを作成しました。







私はすでに長所について話しましたが、今は短所について話しました：

• 私は、サブモジュールを使用するようにチームをトレーニングする必要がありましたが、多くはサブモジュールを使用した経験がありませんでした。
• gitで単一の認証オプションをサポートする必要があります。 たとえば、teamcityでクライアントを構築するには、sshを介してサブモジュールを使用してクライアントリポジトリをポンプアウトします。 しかし反例として、公開鍵と秘密鍵が何であるかを説明するgitの経験がほとんどない人（アーティストなど）と協力するのは非常に無駄です。 この問題は、相対リンクを介して.gitmodulesにモジュールを登録することにより、最終的に「解決」されました。
  
  
  
  

  [submodule "Assets/shared-code"] path = Assets/shared-code url = ../shared-code.git
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  しかし、それはあなたのバージョンのSourceTreeがこれを理解できるという事実ではなく、すべてのリポジトリはgitの同じホストに保存されなければなりません。
• プロトコルリポジトリを1つにまとめて、クライアントをビルドするときにストリッピングを構成して、サブモジュールの数とgitでの操作の全体数を減らすことは価値があるかもしれませんが、サブプロジェクトの3チームすべてがそこで変更をコミットするため、これは他の困難をもたらす可能性があります。
• もう1つの重要なマイナス点は、git-flowで作業する場合、影響を受けるすべてのリポジトリで機能ブランチを維持する必要があることです。そうしないと、ディープレベルモジュールをトップレベルリポジトリに統合する技術的負債が蓄積されます。
  
  
  
  例：プログラマーはメインリポジトリのブランチとサブモジュールの機能ブランチに機能を作成しますが、この時点で新しい機能がサブモジュールの開発ブランチに注がれます。これにより、単に最新バージョンにアップグレードすることはできません。 これらの変更をサポートするには、コアモジュールコードを変更する必要があります。 その結果、プログラマーは、サブモジュールの最新バージョンへの適応を記述するまで、完成した機能を開発に注入することはできません。 これにより統合が遅くなり、再びプログラマーをタスクのコンテキストから切り替えました。 上記のように、最初に機能ブランチにサブモジュールの変更を記述し、次に機能ブランチにもメインリポジトリの適応を記述します。その後、レビューとテストに合格した後、これらのブランチは同時にリポジトリの開発にマージされます。

プレーヤーの入力損失

ここで、製品に直接関係する問題にさらに目を向けます。 ゲームサーバーとモバイルクライアントの間では信頼性の低いUDPを使用していますが、これはメッセージ配信や正しい順序を保証するものではありません。 もちろん、これはプレイヤー自身にとって重大な問題を数多く課します。 良い例は、高価で強力なロケットとそれを起動するボタンです。 プレイヤーは、この能力を使用するのに適した状況を待ち、ボタンを1回押すと、最も都合の良い瞬間に、自分の意見で判断します。 プレイヤーがこの瞬間を通過できないように、この情報をサーバーに確実かつできるだけ早く配信する必要があります。 しかし、このパッケージが消えるか2秒で到着すると、目標は達成されません。



最初は、受信確認がない状態でデータを送信する戦略を検討しましたが、時間の損失をできるだけクライアントデータの送信期間に近づけたいと考えました。 追加のタスクは、サーバーでのシミュレーションでキャラクターがスタンを終了した後、スタンの作業中にショットボタンを押すことでした。



このソリューションは安価であることが判明しましたが、効果的です。

1. クライアントの作業の各フレームで、入力を記録して番号を付けます。
2. それらをクライアントのコレクションに保存し、サーバーに複数の最後のレコード（たとえば、最後の10）を一度に送信します。 このようなメッセージのサイズは非常に小さく（クライアントから平均で約60バイト）、余裕があります。
3. サーバーはメッセージを受信し、まだ受信していない部分のみをメッセージから取得して、処理順番に追加します。 したがって、一部のパッケージがサーバーからクライアントに到達しない場合、次に到着するパッケージには常に最新の入力履歴全体が含まれます。
4. キャラクターの準備ができたとき（キャンプを出るとき）にスキルの使用を延期する問題を解決するために、すべてのデータがそこにあります。 処理ロジックは、特定のプレーヤー用にどの入力フレームが処理されたかを認識しており、特定のゲームプレイの状況では、できるだけ早くそれを処理し続けます。 この場合のアプローチの利点は、入力キューの「穴」を見逃すことがほとんどないことです。

クライアントの画像の滑らかさの問題

非保証の配信方法を使用すると、サーバーからクライアントに世界の状態を戻すという問題にも直面します。 しかし、それについては後で。 まず、ネットワークを介して状態を転送するプロジェクトゲームのチームが解決する必須の問題について説明します。



ゲームサーバーを想像してください。これは、同じことを1秒間に一定回数実行するアプリケーションです。ネットワーク経由で入力を受け取り、決定を下し、ネットワーク経由で状態を送り返します。 そして今、クライアントを想像してください-これは、（特に）1秒あたり特定のフレーム数（たとえば60）でゲームの状態を表示するアプリケーションです。 ネットワークから送信されたものを表示するようにすると、クライアントは2〜3フレームごとに同じ着信状態を表示し、表示がぎくしゃくします。また、不均等な配信の場合は、時間を加速/減速します。 表示をスムーズにするために、サーバーからの2つの状態間の補間を使用して、いくつかの必要なフレームの計算された中間値を表示する必要があります。



私たちは過去にクライアントを去っています...



ただし、この時点では状態が1つしかなく、中間フレームを描画する秒はありません。 どうする 解決策：クライアントイベントの時間を過去に少しずらすことで、レンダリングの時点で、次の世界の状態が来る理論上の機会をすでに得ています。



実際には、それほどバラ色ではありません。UDPは配信を保証しません。世界の状態がクライアントに到着しない場合、数フレーム表示するデータがありません。いわゆる「フリーズ」を取得します。 入力遅延とパケット損失の割合のバランスをとり、2送信期間+半RTTの過去への逸脱を使用します。 したがって、1つのパケットが失われた場合でも、次のパケットを受信する時間があります。 同時に、パケットの受信が2期間以上中断された場合、さらに切断される可能性が非常に高くなります。これは、自発的な遅延よりもプレーヤーにとってはるかに理解しやすいものです。 プレーヤーには再接続ウィンドウが表示され、ゲーム体験をそれほど損なうことはありません。

断続的なPingの問題

実際には、補間とフォールバックを備えたスキームは常にうまく機能するとは限りません。 プレーヤーは、10ミリ秒のPingで自宅でWi-Fiをプレイしてゲームを開始し、外に出てタクシーに乗り、既に100ミリ秒のPingでモバイルインターネットをオンにして街中を走ります。 この場合、ゲームの開始時にRTTを覚えていると、パッケージが完全に、均等に、かつ損失なく配信される場合でも、プレイヤーは補間のための十分な時間を絶えず持つことができます。



このケースでは、この問題を次のように解決しました。

1. パケット到着時間とそれが意味するサーバー時間を分析するたびに。
2. ネットワークの状態が悪化した場合、必要なマージンで、さらに大きな過去にスムーズに移行するため、ルールは次のようになります。
   
   
   
   

    2 * Send Rate + RTT/2
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

3. クライアントでは入力遅延が増加しますが、画像は滑らかなままです。

視覚的には、これを発見したとき、クライアントがすでに遅れ始めているという問題が残っています。 すぐに過去に移動するわけではありませんが、短時間（0.5秒）以内に、この場合でも1〜2フレームのデータは保持されません。 送信レートが1を超えるpingドロップの場合、プレーヤーは小さな（1 \ 30秒）1回のジャークに気付きます。



同様に、反対方向でpingが減少した場合、クライアントはこれを判断し、ディスプレイを現在に近づけて、滑らかな画像と最小入力遅延の最適なバランスを実現します。

質問への回答

結論として、あなたが持っているかもしれないいくつかの質問に答えたいと思います。



入力遅延と戦うのではなく、シミュレーションでクライアントの動作をローカルで予測しないのはなぜですか？



この決定は、ゲームのジャンルと仕組みに基づいています：ファーストパーソンシューティングゲームを作成する場合、瞬間的な現象があり、プレイヤーの影響がキャンセルされない場合は、ローカル予測+ラグ補正が最適です。 ゲームプレイに多数の霜、押し込み、およびプレーヤーに影響を与えて行動を変える他のメカニズムが含まれる場合、ネットワークアーティファクトの出現は100％に近づきます。 この点で最も必死なのは、最小限のアーティファクトとローカル予測の必要性との最適なバランスを見つけたBlizzard Overwatchプロジェクトチームです。 しかし、これはPC上にあり、プレイヤーの平均的なpingが理論的にこれを許可します。 私たちの場合、ローカルプレーヤーでは、100％の場合、前方への急な動きは「テレポート」で終了し、初期状態への衝撃があります。



異なるpingを持つ異なる国のプレイヤーはどのようにプレーしますか？



pingが最高の人は、反応する時間がもっとあるので、当然のことながら利点があります。 例：敵がプレイヤーに発射物を投げたいとします。 pingが低いプレーヤーは、敵のアニメーションの開始に少し早く気づき、防御アクションを実行する機会が増えます。 さらに、保護アクションはより速くサーバーに到達し、回避を管理する可能性が高くなります。



両方が同時にクリックされ、1人のプレイヤーにさらにpingを実行した場合、最初に誰が撮影しますか？



サーバーはプレスの時間を考慮せず、入力の到着時間とその順序のみを考慮します。そのため、上記の答えの原理が機能します。

もう一つ

私が書いた資料が、同様の道を歩む他の開発者に役立つことを願っています。 一般に、この期間中にプロジェクトには多くの問題と解決策が蓄積されているため、複数の記事を書くには十分です。



頑張って