モバイルペースの速いシューティングゲームでどのように振ったか：技術とアプローチ

1年前、私たちの会社には1つのプロジェクトがありました。比較的遅いが、カラフルで激しい戦闘を行うモバイルシューティングゲームWar Robotsです。 ゲームは進化を続けており、世界中に数千万のインストールとプレイヤーがあり、常に更新が行われています。 ある時点で、Overwatch、CS：GOまたはQuakeに匹敵する速度のダイナミックUnityシューティングゲームを作りたかったのです。 しかし、現在のアーキテクチャとアプローチでWar Robotsに基づいたモバイルプラットフォーム（主にiOSとAndroid）の計画を実装することはほとんど不可能でした。



理論的にはこれを行う方法を理解しました-シューティングゲームの作成方法、ネットワークの操作方法、発生する問題、およびそれらの解決方法について詳しく説明する多くの記事、YouTubeのプレゼンテーションがあります。 Rocket Scienceはありません。これらのアプローチはすべて30年前に発明されたものであり、この間、あまり変化していません。 しかし、私たちには練習がありませんでした。



将来を見据えて、計画を実行することができました。 モバイルプラットフォーム用の動的高速シューティングゲームを作成しました。これは現在ベータテスト中であり、積極的に開発されています。 そして、これらすべてを本当に共有したいと思います。 これは、使用するほとんどすべてのリストと簡単な説明を含む最初のレビュー記事です（開発中の他のプロジェクト、類似しているが詳細が異なる技術やアプローチと混同しないでください）。

シミュレーション

ゲームプレイをシミュレートすることから始めましょう。 ECSで記述することにしました-これは、データをロジックから分離するデータ指向のアプローチです。 データは、エンティティに属するエンティティおよびコンポーネントとして表されます。 ロジックはシステムで説明されており、通常、エンティティのコンポーネントを通過して変更し、新しいコンポーネントとエンティティを作成します。







現在のソリューションが私たちに合わなかったため、ECSをかなり迅速に作成しました。 ECSを使用すると、ロジックをデータから分離し、ワールドデータをすばやくシリアル化し、クライアントとサーバー間で交換することができました。 共有ライブラリでECSコードを生成するための別のプロジェクトがあります。 その中の多くのメソッドは、コンポーネントからコンポーネントに複製されます。たとえば、データのシリアル化、コピー、比較、デルタ圧縮などです。



同じシミュレーションコードがクライアントとサーバーで同時に機能します。 これにより、次の利点が得られました。

1. ゲーム機能は、クライアントプログラマーによって完全に記述できます。サーバー上でも同じロジックが機能します。
2. プレイヤーのアクションとゲーム内のアクションの結果の間に遅延はありません。 クライアントは即座にコマンドをローカルで処理します（予測）。 そして、ローカルシミュレーションの結果がサーバーの結果と異なる場合にのみ、クライアントは世界のサーバーの状態を基準としてロールバックします。
3. プレイヤーのトレーニング（チュートリアル）ゲームサーバーに接続せずに、デバイス上でローカルにシミュレートできます。
4. 機能を開発するとき、プロジェクトは常に動作するサーバーを必要としません。 ロジック、グラフィックス、ゲームデザインなどをテストするには -ローカルで試合を開始できます。
5. 共通のライブラリを使用して、負荷テスト用のボットをすばやく作成することができました。これにより、ゲームサーバーのさまざまなパフォーマンスとメモリの問題が明らかになりました。

お客様

クライアントでの予測とロールバックに加えて、補間を使用します。 しかし、通常の意味ではありません、なぜなら 1フレームで1秒間に30回シミュレートして描画します。実際、古典的な補間は必要ありません。



可能であれば、サーバーのバッファ内の状態を補間します。なぜなら、 モバイルプラットフォームでは、パケットの損失が大きくなる可能性がありますが、ここでレンダリングするための世界の状況を望んでいます。



顧客のアーキテクチャ





クライアントコードは依存性注入を積極的に使用します。 DIフレームワークとして、 Zenjectを使用します 。 特定のバインディング設定は、Zenjectではインストーラーと呼ばれる小さなコンポジションルートで説明されています。 ほとんどの場合、特定のインストーラーを無効にすることで、機能/表示/ネットワークの相互作用を無効にするような方法で記述しようとします。



ゲームにはいくつかのコンテキストがあり、そこにあるオブジェクトは特定のコンテキストに属し、それと一緒に住んでいます：

• ProjectContext-アプリケーションが存続する間ずっと存続するオブジェクト。
• MetaContext-キャラクターの選択、装備、購入など。
• MatchContext-PvPバトルコンテキスト。

戦闘コンテキスト



ゲームメカニクスのプレゼンテーションレベルでのMatchContextのコンテキストでは、 MVPを使用します。 モデルはECSからのデータであり、プレゼンターはそれらを使用して表示し、Unityビュー部分を表示します。 エンティティとコンポーネントのプレゼンターがいます。 プレゼンテーションレベルでは、UIは以下で説明するMVVMを使用します。



クライアントとサーバー間でデータを転送するために、低レベルのPhotonライブラリが機能し、そこからudpベースのプロトコルを使用します。 データを自分でシリアル化します。カスタムデルタ圧縮を作成しました。 ゲームの世界は広く、モバイルデバイスにとってトラフィックの量は非常に重要です。MTUに会って、世界の状態が1つの物理パッケージに収まるようにするのはいいことです。



メタコンテキスト



表示レベルのMetaContextでは、 Unity-Weldライブラリに基づいてMVVMとDataBindingを使用します。 その結果、Unityプロジェクトで通常行われているように、多くの設定とUIロジックを持つ各ウィンドウのカスタムMonoBehaviourクラスはありません。 代わりに、UIロジックは特定のウィンドウのViewModelで記述され、Viewレベルは1つのクラス-View（MonoBehaviorから継承）およびデータバインディングのいくつかの標準クラスだけで表されます。 この場合、プログラマーはロジックのみを記述し、必要なデータを「出力」し、UIデザイナーはディスプレイへのデータバインディングをタイプセットして設定します。



メタコンテキストでは、 StrangeIoCおよびIoC +ライブラリから部分的に借用したSignal-Command-Serviceアプローチも使用します。 現在はZenject信号に基づいていますが、いつでも他のオプションに書き換えられるように書かれています。 したがって、 イベントとアクションの関係はインストーラーレベルで構成され、1行で説明されます。



メタサーバーと通信するためのプロトコルはProtobufに基づいており 、 WebSocketはトランスポートとして使用されます。

サードパーティのソリューション

上記のものに加えて、開発をスピードアップするために、クライアントで他の多くのサードパーティのソリューションとプラグインを使用します。

• FMOD-サウンドの操作用。 別のサウンドデザイナーがいます。彼はFMODエディターでクールなサウンドと音楽を「調理」する方法を知っています。
• 揮発性物理学 -クライアントおよびサーバー上の物理学、C＃で記述されています。
• Lunar Console-クライアントのログを表示するため、および機能をテストするため。
• ヘルプシフト -プレイヤーと通信し、フィードバックを収集します。
• AppMetrは、独自の分析システムです。
• Json.net 。
• その他

一般的なソリューション

プロジェクトの共通ソリューションを開発する別のチームがあります。 例：

• 独自のPackageManagerがあり（Unity 2018よりも優れており、そのかなり前に登場しました）、バージョン管理と削除をサポートしています。 これにより、他のすべてのソリューションとサードパーティのプラグインおよびライブラリをプロジェクトに提供します。 プラグインの削除と更新に問題はありません。
• 独自のBuildPipeline-さまざまな構成とプラットフォームに合わせてアセンブリをカスタマイズする機能 通常、アセンブリと構成の手順は異なります+ TeamCityとの統合。
• システム内のクライアント認証モジュール。
• 自動試験システム;
• 弊社に適合したサードパーティのプラグイン（ロギング、分析、上記参照）;
• 一般的なシェーダー;
• その他

顧客の最適化

モバイルプラットフォーム向けに最適化した豊富な経験があります。 特に：

• シェーダーを最適化します。
• テクスチャを圧縮し、アトラスにアセンブルし、シェーダーのバリアントの数を減らすなどして、ビルドサイズを大幅に削減します。
• MeshMergerを使用して、静的オブジェクトと1つのマテリアルを1つのオブジェクトに結合し、テクスチャもマージします。
• Unityの組み込みプロファイラー、およびdotTraceとdotMemoryを使用して、コードを最適化します。
• ガベージコレクションを最小限に抑えるために、メモリプールと事前に割り当てられたメモリを使用します。
• デルタ圧縮を使用して、送信パケットのサイズを削減します。
• はるかに。

これの一部は、以前の記事「モバイルゲームでのポストエフェクト」および「Unity3dでのモバイルデバイス用の2dアプリケーションの最適化 」で読むことができます。 これら2つの記事の2つ目はすでに時代遅れですが、そこからの多くのヒントが機能します。

ゲームサーバー

戦闘が行われるゲームサーバーはC＃で記述されています。 上記のudpベースのPhoton Network Libraryは、ネットワークプロトコルとして使用されます。 現時点では、サーバーの編集はほとんど行われません。 すべてのゲームロジックはクライアントプログラマーによって作成され、サーバー上で回転しています。



また、httpを介してサーバーに接続し、リアルタイムで戦闘を視覚的に表示できる特別なツールも作成しました。 さらに、すべてのエンティティ、そのコンポーネント、および値を表示したり、戦闘を記録して後でテスト目的でプレイしたりすることができます。 今後の記事では、ゲームサーバーについて個別に記述します。

メタサーバー

メタとは、プレイヤープロフィール、購入、マッチメイキング、チャット、クランなどの機能を実装できるマイクロサービスシステムのことです。 これらはすべて個々のプログラマーによって作成され、異なるプロジェクトで一緒に使用されます。 開発で使用される技術：

• Javaは主要な開発言語です。
• Cassandra 、 postgres-プレイヤーデータを保存します。
• Consul-ゲームおよびサーバー設定のキーと値のデータの保存を含む、サービス発見として。
• RabbitMQ-メッセージキュー。
• Protobufは、サービスとクライアント間のプロトコルです。
• gRPC-サービスとゲームサーバー間の通信用。
• netty 、 akka 、 logbackなども同様です。

チーム

ゲームは機能とともに急速に成長し、新しい従業員を積極的に集めていますが、一般的に、プロジェクトチームはコア部門と関連部門で構成されています。



コアには、クライアントプログラマ、ゲームデザイナー、プロジェクトマネージャー、プロダクトオーナー、QA（テスター）が含まれます。 関連部門は次のとおりです。

• グラフィックプログラマ;
• メタサーバープログラマー。
• プロジェクトの共通ソリューションを開発するチーム。
• アーティスト;
• アニメーター;
• コミュニティマネージャー。
• サポート;
• マーケティングなど

どうやって働くの

私たちはスクラムに取り組んでいます。 しかし、誰もが自分のスクラムを持っていることを理解することは価値があります。 2週間の反復、ポーカープランニング、回顧、デモなどがあります。 しかし同時に、私たちのリリースはスプリントの終わりに縛られておらず、リリーステストの追加段階があります。



GitHubにコードを保存し、プルリクエストを行い 、コードのレビューにUpsourceを使用します。 RiderおよびVisual Studio + Resharperでコードを記述します。



クライアントを構築し、サーバーを展開および展開するには、TeamCityとGradleを使用します。 モバイルデバイスへのクライアントのインストールは、1回または2回のクリックで行われます。

• [実行]をクリックして、TeamCityでクライアントをビルドします（ほとんどのアセンブリは自動的に行われるため、この手順は省略できます）。
• ビルド用に生成されたQRコードを使用したインストール。

結論の代わりに

ご覧のように、私たちの時代には、真面目な製品は多くのアプローチとテクノロジー、およびリソースとスペシャリストを使用しており、すべてが一見思えるほど単純ではありません。



次の記事では、ECS 、その作成方法、およびその機能について説明するか、上記の他に近い将来読みたいものについてのコメントを書くことができます。