クライアントとサーバーの一般的なゲームロジック

Pixonic DevGAMM Talksで、DTOのAnton Grigoryevも話をしました。 会社では、新しいPvPシューティングゲームに取り組んでいると既に述べており、アントンはこのプロジェクトのアーキテクチャのニュアンスの一部を共有しました。 彼は、クライアントのゲームロジックの変更がサーバーに自動的に反映されるように（およびその逆に）開発を構築する方法と、コードを記述せずにトラフィックを最小限に抑えることができるかどうかを話しました。 以下は、レポートの記録とトランスクリプトです。


私は何かをする方法を学びません、私たちがそれをどのようにしたかについて話します。 あなたが同じレーキを踏まないようにして、私たちの経験を活用してください。 1年半前、私たちは携帯電話でシューティングゲームを作成する方法を知りませんでした。 なんと言っても、戦争ロボット、1億ダウンロード、150万DAUがあります。 しかし、このゲームでは、ロボットの動作が非常に遅いため、迅速なシューティングゲームを作成したかったため、War Robotsのアーキテクチャではこれが許可されませんでした。

私たちはどのようにして何をすべきかを知っていましたが、経験はありませんでした。 それから私たちはこの経験をした人を雇い、言いました：あなたがすでに100回やったことと同じことをしてください。 それから彼らは座って建築について考え始めました。



Entity Component System（ECS）に来ました。 多くの人がそれが何であるかを知っていると思います。 世界のすべてのオブジェクトはエンティティによって表されます。 たとえば、プレーヤー、彼の銃、マップ上のオブジェクト。 それらには、コンポーネントによって記述されるプロパティがあります。 たとえば、Transformコンポーネントはプレイヤーの空間における位置であり、Healthコンポーネントは彼の健康です。 ロジックがあります-それは分離され、システムによって表されます。 通常、システムはExecute（）メソッドであり、特定のタイプのコンポーネントを通過し、ゲームワールドでそれらを使用して何かを行います。 たとえば、MoveSystemはMovementのすべてのコンポーネントを通過し、このコンポーネントの速度、パラメーターを調べ、これに基づいてオブジェクトの新しい位置を計算します。 Transformに書き込みます。

このようなアーキテクチャには独自の特性があります。 ECSで開発する場合、物事を異なる方法で考え、実行する必要があります。 プラスの1つは、多重継承ではなく構成です。 C ++で複数の継承を持つこの菱形を覚えていますか？ 彼のすべての問題。 これはECSには当てはまりません。



2番目の機能は、ロジックとデータの分離です。これについては既に説明しました。 これにより何が得られますか？ 世界の状態とその履歴をバッチで保存したり、シリアル化したり、このデータをネットワーク経由で送信したり、リアルタイムで変更したりできます。 これはメモリ内の単なるデータです。いつでも値を変更できます。 したがって、ゲームのロジックを変更する（またはデバッグする）ことは非常に便利です。

システムコールの順序を追跡することも非常に重要です。 すべてのシステムは次々に実行され、Execute（）メソッドによって呼び出され、理想的には独立している必要があります。 実際には、これは起こりません。 1つのシステムが世界の何かを変更し、別のシステムがそれを使用します。 そして、この順序を破ると、ゲームは違ったものになります。 おそらくそれほどではありませんが、間違いなく以前と同じではありません。

最後に、私たちにとって最も重要な機能の1つは、クライアントとサーバーの両方で同じコードを実行できることです。

開発者に機会を与えれば、彼は既存の決定を使用せずに、99の方法と理由を見つけて決定を下します。 多くの人がやったと思う。 当時、ECSフレームワークを探していました。 Entitas、Artemis C＃、Ash.net、および独自のソリューションを検討しました。これらは、私たちに来たスペシャリストの経験から書かれたものです。



スライドに書かれている内容を読もうとしないでください。それほど重要ではありません。 重要なことは、列にどれだけ緑と赤があるかです。 緑-ソリューションが要件をサポートしていることを意味し、赤-サポートしていない、黄色-サポートしているが、実際はサポートしていない。

コラムでは、ECSが潜在的に私たちのソリューションです。 ご覧のとおり、よりクールです-より多くの要件をサポートできます。 その結果、それらのいくつかをサポートしていませんでした（主にそれらが必要なかったため）、そしてそれなしではそれ以上作業できませんでした。 私たちはアーキテクチャを選び、長い間働いて、最小限のプレイ可能なバージョンを作り、そして... fakap。



最も再生不能なバージョンが判明しました。 プレーヤーは絶えずロールバックし、ブレーキをかけ、試合の途中でサーバーがハングしました。 それを再生することは不可能でした。 失敗の理由は何ですか？

理由その1、最も重要なのは経験不足です。 しかし、どのように？ 私たちはすべてを美しく行うことになっている経験豊富な人を雇いました。 はい、しかし実際には彼に仕事の一部だけを与えました。 「ここにあなたのためのゲームサーバーがあります、それに取り組んでください。」 そして、私たちのアーキテクチャ（詳細は後述）では、クライアントが非常に重要な役割を果たします。 そして、私たちが必要な経験を持っていない人に与えたのはこの部分でした。 いいえ、彼は優秀なプログラマーであり、上院議員です-単に経験はありませんでした。 つまり 彼はどのようなレーキがあるのか​​全く知りませんでした。

理由その2-非現実的な割り当て。 80 KB /フレーム。 それはたくさんですか？ 1秒あたり30フレームがあることを考慮すると、1秒で2.5 MBが得られ、5分間の試合では既に600 MBを超えています。 要するに、たくさん。 ガベージコレクターは、このメモリをすべて解放しようとします（メモリからの要求が増えると）、スパイクが発生します。 1秒あたり30フレームが必要であるため、これらのスパイクは非常に干渉しました。 さらに、クライアントとサーバーの両方で。

割り当ての主な理由は、データ配列を絶えず割り当てることでした。 ほぼ毎フレームごと。 LINQ、ラムダ式、Photonを使用。 Photonは、War Robotsで使い慣れているネットワークライブラリです。 そして、すべてがうまくいくように見えますが、データを送信または受信するたびにメモリを割り当てます。

最初の問題（カスタムコレクションに書き直し、キャッシングを行った）を見つけた場合、Photonはサードパーティライブラリであるため、Photonで実際に行うことはありませんでした。 パケットサイズを小さくすることのみが可能で、5Kバイトでした。 たくさん？ はい MTUがあります-これは、パケットを小さな部分に分割することなく、UDP経由で送信される実際の最小パケットサイズです。 約1.5 Kバイトで、5個ありました（平均して、それ以上ありました）。

したがって、Photonはパッケージを小さなものに切り分け、各ピースを信頼できるものとして送信しました。 保証付き配送。 部品が届かないたびに、彼は何度もそれを送りました。 さらに遅延が発生し、ネットワークはうまく機能しませんでした。

これらすべての割り当ては、33が必要なときに約100ミリ秒のフレームを受信するという事実につながり、そこでは、レンダリング、シミュレーション、その他のアクション-これらはすべてCPUを使用します。 これらの問題はすべて複雑です。 1つを決定することは不可能であり、すべてがうまくいきます。 それらを一度に解決する必要がありました。

そして、開発中にあった別の小さな問題-多数のリポジトリ。 5はスライド上に書かれていますが、私にはさらに多くのものがあったようです。 これらのすべてのリポジトリ（クライアント、ゲームサーバー、共通コード、設定など）は、サブモジュールによってクライアントとゲームサーバーの2つのメインリポジトリに接続されました。 一緒に働くのは大変でした。 プログラマーはGit、SVNで作業できますが、アーティスト、デザイナーなどもいます。 多くの人がアーティストやデザイナーにバージョン管理システムの使い方を教えようとしたと思います。 これは本当に難しいので、もしあなたのデザイナーがそれをする方法を知っていれば-彼の世話をして、彼は貴重な従業員です。 私たちの場合、プログラマでさえも驚いた結果、すべてを1つのリポジトリに減らしました。

これは問題の素晴らしい解決策でした。 サーバーがあるフォルダーとクライアントがあるフォルダーがあります。 サーバーは、ゲームサーバープロジェクト、コードジェネレーター、および補助ツールで構成されます。



クライアントは、Unityクライアントであり、共通のコードです。 一般的なコードは、ワールドデータ構造です。 エンティティ、コンポーネント、およびシステムシミュレーション。 このコードは、主にサーバージェネレーターによって生成されます。 サーバーによって使用されます。 つまり これは、クライアントとサーバーの共通部分です。

ライフカ。 TeamCityを取得してリポジトリに設定し、サーバーを収集して展開します。 クライアントが一般的なロジックを変更するたびに、ゲームサーバーがここで組み立てられます。これにはサーバープログラマは不要です。 通常、サーバー、クライアント、およびいくつかの機能があります。 クライアントはそれを自宅で見、サーバーは自宅で見ます。そしていつか彼らのために働くでしょう。 私たちの場合、そうではありません-クライアントはこの機能を記述でき、すべてがサーバー上で動作します。

試合は共通部分（ECSとして指定）とプレゼンテーション（これらは単一のMonoBehaviorクラス、ゲームオブジェクト、モデル、エフェクト-世界が表すすべて）で構成されています。 それらは接続されていません。



それらの間には、両方の部分で機能するプレゼンターがいます。 ご存知のように、これはMVP（Model-View-Presenter）であり、これらのパーツは必要に応じて交換できます。 ネットワークで動作する別の部分があります（スライド上-ネットワーク）。 これは、世界に関する情報のシリアル化、入力のシリアル化、サーバーへの送信、サーバーによる受信、サーバーへの接続などです。

もっと好き。 この部分を取り込んで、ネットワークではなく仮想の仮想区画に置き換えます。 クライアント内にオブジェクトを作成し、彼にメッセージを送信します。 サーバーシミュレーションを実装します。このオブジェクトは、ゲームサーバーで発生したすべての処理を実行します。 残りのプレイヤーはボットに置き換えられます。



できた ゲームを入手し、ゲームサーバーなしでテストできるようになりました。 これはどういう意味ですか？ これは、新しいエフェクトを作成したアーティストがエディターの[再生]ボタンをクリックし、すぐにマップ上の一致に到達してその動作を確認できることを意味します。 または、クライアントプログラマが書いた内容をデバッグします。

しかし、さらに進んで、ネットワーク遅延のジッターping（これは、ネットワーク上のパケットが送信された順序で到着しない場合）と他のネットワークの事物のこのレイヤーエミュレーションに接続しました。 その結果、ゲームサーバーなしで実際に試合をすることができました。 動作確認済み。

コード生成に戻りましょう。



ゲームサーバーにコードジェネレーターがあることは既に述べました。 ドメイン固有の言語がありますが、これは実際には単純なC＃クラスです。 この場合、クラスHealth。 属性でマークします。 たとえば、コンポーネント属性があります。 彼は、健康は私たちの世界の構成要素であると言います。 この属性に基づいて、ジェネレーターは新しいC＃クラスを作成します。このクラスにはさまざまなものがあります。 それらは手で書くことができますが、生成されます。 たとえば、エンティティにコンポーネントを追加する方法、コンポーネントを検索する方法、データをシリアル化する方法など。 DontSendタイプの属性があります。これは、ネットワークを介してフィールドを送信する必要がないことを示します-サーバーはそれを必要としないか、クライアントはそれを必要としません。 または、属性Mach。プレーヤーの最大ヘルス値が1,000であることを報告します。 これにより何が得られますか？ 32ビット（int）を占有するフィールドの代わりに、10ビットを送信します（3倍少ない）。 このようなコードジェネレーターにより、パケットサイズを5 KBから1に減らすことができました。



1 KB <1.5-つまり MTUに会いました。 Photonは切断を停止し、ネットワークは大幅に改善されました。 彼女の問題のほとんどすべてがなくなっています。 しかし、私たちはさらに進んで、デルタ圧縮を行いました。



これは、1つの完全な状態を送信し、その変更のみを送信する場合です。 全世界がすぐに完全に変わったということはありません。 一部のパーツのみが絶えず変更されており、これらの変更は状態自体よりもサイズがはるかに小さくなっています。 平均300バイト、つまり 当初の17倍になりました。

とにかくMTUにいる場合、これが必要なのはなぜですか？ ゲームは常に成長しており、新しい機能が登場し、それらとともにオブジェクト、エンティティ、新しいコンポーネントが登場します。 データサイズは増大しています。 1Kバイトに落ち着くと、すぐに同じ問題に戻ります。 デルタ圧縮用に書き直したので、すぐにはこれに到達しません。

今最も甘い部分。 同期する シューティングゲームをプレイする場合、ボタンをクリックすると、入力ラグが何であるかがわかります。たとえば、0.5秒後にキャラクターが動き始めます。 mobジャンルの一部のゲームでは、これは正常です。 しかし、シューティングゲームでは、ヒーローにその場で撃ってダメージを与えたいと思っています。



入力ラグが発生するのはなぜですか？ クライアントはプレーヤーの入力（入力）を収集し、ゲームサーバーに送信します（送信には時間がかかります）。 次に、ゲームサーバーはそれを処理し（再び、時間）、結果を送り返します（再び、時間）。 これは遅延です。 削除する方法は？ 予測と呼ばれるものがあります-クライアントはサーバーからの応答を待たずに、ゲームサーバーと同じことをすぐに試行し始めます。 偽物。 プレーヤーの入力を受け取り、シミュレーションを開始します。 他のプレイヤーの入力がわからないため、ローカルクライアントのみをシミュレートします。彼らは私たちのところに来ません。 したがって、シミュレーションシステムはプレーヤーでのみ実行します。

第一に、シミュレーション時間を短縮できます。 クライアントは、入力を受信するとすぐにシミュレーションを開始し、ゲームサーバーに対して数ステップ進んでいます。 この写真で、彼はティック＃20をシミュレートしているとしましょう。 この時点で、ゲームサーバーは過去のティック＃15をシミュレートします。 クライエントは、過去においても、将来においても、世界の残りの部分を見ています。 彼が20番目のティックをサーバーに送信している間、この入力が到達する間、ゲームサーバーはすでに18番目のティックまたはすでに20番目のティックのシミュレーションを開始します。 18番目の場合、彼はそれをバッファに入れ、20番目に達し、処理して結果を返します。

今、彼がティックNo. 15をシミュレートしているとします。 処理され、結果をクライアントに返します。 クライアントには、ある種のシミュレートされた15番目のティック、15番目のゲーム状態、および彼が予測したゲーム世界があります。 サーバーとの比較が開始されます。 実際、彼は世界全体を比較するのではなく、クライアントのみを比較します。なぜなら、私たちは世界のその他の部分について責任を負っていないからです。 私たちは自分自身に対してのみ責任を負います。 プレーヤーが一致した場合、すべてが正常です。つまり、正しくシミュレートされ、物理が正しく機能し、衝突は発生していません。 次に、20番目のティック、21番目のティックなどのシミュレーションを続けます。

クライアント/プレーヤーが一致しなかった場合、それはどこかで間違っていたことを意味します。 例：物理学は決定論的ではないため、位置または何かが間違って計算されています。 たぶんバグです。 その後、クライアントはゲームサーバーから状態を取得します。これは、ゲームサーバーが既にそれを確認しているためです（サーバーを信頼している-信頼できない場合、プレイヤーは不正行為をします）。 この時間分岐は現在エラーになっているためです。

新しいタイムブランチ、つまり パラレルワールド。 これら5つのティックを1つのティックでシミュレートします。 シミュレーションに5ミリ秒かかりましたが、10ティックをシミュレートする必要がある場合は、すでに50ミリ秒であり、30ミリ秒にはなりません。 最適化されて1ミリ秒になりました-10ミリ秒で10ティックが処理されるようになりました。 まだレンダリングがあるからです。

これらはすべてクライアントで機能し、必要な経験のない人にそれを提供しました。 マイナス-私たちはfakapを持っていました、そしてプラス-プログラマーは今それを正しく行う方法を知っています。



このスキームには独自の特徴があります。 左の写真のクライアントは敵を追跡しようとしています。 彼は20目盛りで、対戦相手は15目盛りです。 pingとクライアントはサーバーより5ティック先にあるためです。 クライアントは撃ち、正確に打撃を与え、ダメージを与えなければなりません。 しかし、サーバー上では画像が異なります-サーバーが20番目のティックをシミュレートし始めると、敵はすでに移動している可能性があります。 たとえば、敵が動いていた場合。 理論的には、取得すべきではありません。 しかし、それがそのように機能した場合、誰もが常にミスのためにオンラインシューティングゲームをプレイしません。 pingに応じて、ヒットする確率も変化しました。pingが悪いほど、悪化します。 したがって、彼らは異なる方法でそれを行います。

サーバーは、全世界を取得し、プレイヤーが世界を見たチークに転がします。 サーバーは、それがいつだったかを認識し、15番目のティックにロールバックして、左の画像を確認します。 彼は、プレーヤーがヒットするはずであると判断し、すでに20ティックで相手にダメージを与えます。 すべて順調です。 ほぼ。 敵が逃げて障害物の後ろに走った場合、すでに壁を通り抜けています。 しかし、これは既知の問題であり、プレイヤーはそれを知っており、心配する必要はありません。 だからそれは動作します、それについて何もすることはありません。



したがって、1秒あたり30ティック、1秒あたり30フレームに達しました。 現在、約600人のプレイヤーがサーバーで同時にプレイしています。 試合には6人のプレイヤーがいます。 約100件の一致。 サーバープログラマーはいません。必要ありません。 クライアントはすべてのロジックをC＃のUnityエディターRiderで記述し、ゲームサーバー上で動作します。 ほとんど常に。 パケットサイズを17倍削減し、メモリ割り当てを80倍削減しました。現在では、クライアントとサーバーで1キロバイト未満です。 平均pingは200〜250ミリ秒でしたが、現在は150です。200はモバイルネットワークゲームの標準であり、PCとは異なり、特にローカルネットワークですべてが高速に発生します。



別のフレームワークで記述されているものを分離して、他のプロジェクトで使用する予定です。 しかし、これまでのところ、オープンソースの話はありません。 そして、そこに補間を追加します。 これで、1秒間に30ティックが得られ、ティックごとに描画できます。 ただし、1秒あたり20ティックまたは10で十分なゲームもあるため、1秒間に10回描画すると、キャラクターはぐっと動きます。 したがって、補間が必要です。 Photonの代わりに独自のネットワークライブラリを作成しました-メモリの割り当てはありません。

まだ手で書くことはできませんが、コードを生成する部分があります。 たとえば、世界の状態をクライアントに送信するとき、彼が必要としないデータを切り取ります。 これを手作業で行い、新しい機能が表示され、このデータを切り取るのを忘れると、何かがおかしくなります。 実際、これは何らかの属性をマークすることで生成できます。

聴衆からの質問

-コード生成に何を使用していますか？ あなた自身の決定ですか？

-すべてがシンプル-手。 何かを準備することを考えましたが、自分の手で書くだけで速くなることがわかりました。 この道をたどると、当時も今もうまくいきました。

-サーバー開発者を拒否しましたが、同じコードが再利用されるため、開発時間を短縮しただけではありません。 UnityはC＃の最新バージョンをサポートしていません。内部に独自のエンジンがあります。 .NET Coreは使用できず、最新の機能、特定の構造などを使用できません。 これにより、パフォーマンスは約3分の1に低下しませんか？

-これらすべてを始めたとき、クラスではなく構造体を使用する方がずっと速く動作するはずだと考えました。 コード内でどのように見えるか、ロジックを記述するためにプログラマがこれらの構造をどのように使用するかというプロトタイプを作成しました。 そして、それはひどく不快でした。 私たちはクラスに落ち着き、現在のパフォーマンスで十分です。

-補間なしで今どのように生活していますか？ そして、スナップショットが適切なフレームに収まらない場合、どのようにプレーヤーのふりをしますか？

-補間がありますが、視覚的ではありませんが、ネットワーク上を通過するパケットに対してのみです。 18、19、20番目の州があるとしましょう。 18-, 20-, 19- , — . , .

— , ?

— 2D — , . : UDP, , : , . .

— ?

「はい、もちろん。」 - ( , , ), 2 : , .

— . ? ? 1000 , ? , ?

— , . , -, , . , 30 .

— , ?

— . , ( ), . — , , . - , , . , , , , . .

— ECS, , ? ?

— 30 , . 80 , . .

— prediction. 20- - , , - — , ? , . - ?

— : . (, 15-) 16-,17-,18- .

— ?

— , . , , . Entity ( ), . — , . ID , .

— - — , , , ? , ?

— , , . 3D , — , , - . , , . top-down, — . . , , , . .

— ?

— . これも起こります。

— , , - . - . - , , , 500 , , - - . ?

— .



, .. 20- 20- , . — , . : 20- , ? , . , — - . , . , « - , 21-, 18-». : «, - ». .

-つまり , ?

— , .

— reliable UDP — - ?

— Photon, Photon reliable UDP, unreliable, c .

— ?

— , -. , . , . , . , . 100%, , 80%, .

— ?

— , , Photon , MTU.

— ? ?

— , , , . . , . , , , .

— , , ?

— , . , . , , . , - . , . , .

— / — - . , .

— , . , ( ), -, , -. , . — , .

— , - . ?

— , . : ECS, . , ECS . , ECS . , . , , , ( , , , , , ). 2D , , 3D — . 3D , , . . - , . , - -, .

— , ECS , . , , C#?

— — .

-つまり ES ? , ECS — , , , . つまり ECS — , .

— , , . , . — , , . , O - , , .

— , ECS- ?

— -, ECS , , ( ) — , . , — . — , , . , , , ..

Pixonic DevGAMM Talksとのさらなる講演

• Consulを使用したステートフルサービスのスケーリング （Ivan Bubnov、DevOps at BIT.GAMES）;
• CICD：ダウンタイムなしの分散クラスターシステムへのシームレスな展開 （Egor Panov、Pixonicシステム管理者）;
• Quake Championsゲームのバックエンドプラットフォームでアクターモデルを使用する練習 （Roman Rogozin、バックエンド開発者Sabre Interactive）。
• Tacticoolモバイルオンラインシューターメタサーバーアーキテクチャ （Pavel Platto、PanzerDogのリードソフトウェアエンジニア）;
• ECS、C＃ジョブシステム、SRPがアーキテクチャへのアプローチをどのように変えるか （Valentin Simonov、Unityのフィールドエンジニア）;
• 開発におけるKISS原則 （Konstantin Gladyshev、1C Game Studiosのリードゲームプログラマー）;
• Cucumber : BDD- ( , Technical Product Manager, ALICE Platform).