サーバーへのディープダイブ - 美しさの力

カプセラの皆さんへ

クエーサーに関する話を続けましょう。これはEVE Onlineの近年の開発の基礎エコシステムで、2022年のファンフェスで登場して以来、以下を含む多くの主要な進化の基盤となっているものです。

EVE Evolved（進化したEVE）の一環であるこの発展は、集合論、グラフ理論、色彩理論に触れるものでした。しかし、現在では、フォーカスはカプセラが作成する艦船SKINに関連する技術に当てられています。これは、ただのエディタやシェーダー用ツールではないのです！実際のところ、これはサーバーパフォーマンスの未来の可能性を解き放つことの鍵となるものなのです。この件に関してチームが最近行ってきたことを理解するためには、多少の技術に関する解説が必要であることをご了承ください。

ネットコードとティックレート

マルチプレイヤーのゲームにおける最も一般的な課題の一つは、ネットワークアーキテクチャです。これは一般的に「ネットコード」と呼ばれるものです。すべてのプレイヤーへの一貫した体験の提供や不正行為の防止など、広範な状況において、ゲームクライアントへの情報送信は、全体的なパフォーマンスとゲームの楽しさにとって極めて重要な役割を果たします。ここでの重要な要素は、ティックレートです。これはゲームサーバーの更新と、接続されているクライアントへの情報送信の頻度を示すものです。

これに対するアプローチは、ゲームエンジンによって異なります。例えば、Unreal Engineは、各クライアントに最も重要な更新だけを送信する関連性重視のフィルタリングを強調しており、Source Engineは、スムーズなゲームプレイを維持するための修正回数を削減する入力予測にフォーカスしています。

アプローチを問わず、ティックレートはネットワークパフォーマンスにおいて基盤となる要素です。ほとんどのゲームは、オンラインのプレイヤー数に応じて20Hzから120Hzの間で動作します。これは、更新がクライアントあたりで毎秒20回から120回送信されるということを意味します。たとえば、60Hzでは、サーバーは16.6ミリ秒ごとに処理を行い、更新を送信することで、1秒に60回の更新を確保し、他のプレイヤーが同じ時間内に同じ情報を受け取れる余地を残さなければなりません。レイテンシーが一切なく、ゲーム状態を直接クライアントに送信する魔法のようなインターネット接続が存在する場合（本当はそんなものはありませんが、存在すると仮定します）、60Hzのサーバーはゲーム状態の更新を以下のように処理します：

60Hzサーバーの2ティック

入力予測とムーブメント補間は、魔法のゼロレイテンシーのインターネットなしでも、ほぼリアルタイムのインタラクションの錯覚を作り出すことができますが、ティックレートが低下すると遅延がより顕著になります。これは良いことのようには思えませんよね？ それではなぜティックレートを低下させたいというような状況が起こるのでしょうか？

EVE Onlineは56kモデムが使用されていた時代から存在するゲームです。大規模な宇宙戦闘の帯域幅要件を十分に低くするため、サーバーのティックレートは1秒に設定されていました。

より具体的に言うと、物理演算のティックレートは1Hzで、これはデスクトップのクライアントに更新を送信する必要性を劇的に低くします。

物理演算に影響しない要素とのその他のインタラクションは、Python Hamsterによって可能な速さで処理されます。これが意味するのは、入力が1回のティックの直前に送信された場合、極めて反応が速く感じるということです。直後に送信された場合は、1秒またはそれ以上（実際のレイテンシーを考慮した場合）かかります。そのため、技術的に言えば、キーをちょうど1秒毎に押すことでサーバーから優れた反応を得られるということですが、もちろん精神衛生上は、「ジャンプ」を1秒毎に30回クリックすることが極めて重要です。

トランキリティでの過去1年間の平均を全体的に見てみると、毎秒の動作回数は、星団内のアクティブなカプセラの数に比例することが明確となります。平均で、各セッションは毎秒およそ0.7回動作しており、EVE Onlineがどれほど効率的に必要なデータのみを送信しているかを示しています。

もちろん数字には変動があり、これらすべては平均の数字です。フリートの戦闘が処理速度の上限に到達すると、時間拡張システム（TiDi）が発動します。これについての詳細を知りたい場合、TiDiに関するアーカイブをご覧ください。

それではSKINはこれのどこに関連しているのでしょうか？

EVE Onlineのほぼすべての装飾メカニズムは、EVEのティックであるシミュレーションフレームを介して送信されています。SKINR実装以前、SKINの変更は、すべての関連するクライアントに送信される次のシミュレーションで届けられます。言い換えれば、SKINの更新は1秒に1回だけしか発生できなかったということです。UIまたはネットワークのリクエストの速度制限がなくても、SKINをどれだけ速く変更したとしても、見える更新は毎秒1回だけでした。それがシミュレーションフレームの送信の限界だったからです。

もう一つ問題があります。それはファンアウトです（最後の解説です！）。

艦船のSKINを変更する際、更新は複数の受信先に送信される必要があります。これが「ファンアウト」と呼ばれます。では、何が情報を受信する必要があるのでしょうか？ 近くに100隻の艦船がある場合はどうなるのでしょうか？ 「近く」とはどういう意味で、他の100隻は一体誰なのでしょうか？

シミュレーションフレームは、同じバブル（口語ではグリッドと呼ばれ、ワープ妨害フィールドのバブルとは異なるものです）内の艦船に更新を処理することでのみ両方の問題に対処します。ただし、このアプローチには代償があります。シミュレーションフレームあたりのデータが増えることは、そのソーラーシステムを演算しているサーバーでシリアル化とファンアウトが増えるということを意味するからです。以前、クエーサーは、艦船がどのソーラーシステムにいるかのみを追跡していましたが、SKINRをリアルタイムで機能させるためには、クエーサーはバブル間の艦船の移動も追跡する必要がありました。

これは簡単なことではありませんでした。EVE Onlineのコアシミュレーションエンジンの大規模な変更をすることで、クエーサーがそれまではできなかった形でエンジンの状態にアクセスできるようにする必要がありました。結果は衝撃的なものでした！ ソーラーシステム間のシンプルなトランジションと比較して、処理データが27倍増えたのです。

こちらは、ソーラーシステム移動とバブル移動の毎秒あたりのイベントの比較です。ワープは、「AからB」だけでなく、複数のバブルを横断することを念頭に置いてください。

そしてこれは内部トラフィックだけであり、ファンアウトの問題を考慮すらしていないのです！

ファンアウトの課題の解決

次は、「1隻の艦船が100隻の他の艦船の近くでSKINを変更する」シチュエーションに戻りましょう。クエーサーがすべてのバブルのすべての艦艇を追跡している中で、クエーサーは「近く」の意味と、どのクライアントが更新を受け取る必要があるかを理解するようになっています。次のシミュレーションフレームを待つ代わりに、クエーサーは即座に対象バブルの全員にSKIN変更を送信するということです。

これを可能としたのはパワフルなNATSのメッセージングでした。これは、毎秒EVEクライアントへと送信されるおよそ10,000件のメッセージに対応できます。装飾状態に対応できるサービスは、シリアル化して1つのSKIN更新を送信できるようになっており、それは1Hzシミュレーションティックで遅延されるのではなく、すべての近くの艦船にファンアウト（拡散）されます。

これはSKINRのプレイテストの短い動画で示されています：

ここで疑問は、クエーサーが艦艇の位置を追跡し、装飾の更新を独自に送信することがなぜ重要なのか、に変わります。それは、この技術が、EVE Onlineがメインシミュレーションエンジンから装飾機能の負荷を排除できることに他なりません。

加えて、シリアル化とクライアントへのファンアウトが必要な他のすべての装飾エフェクトを考慮した際、これはより広範な意味合いを持ちます。ここで現れる自然な疑問は、装飾以外にどの負荷をクエーサーに割り当てられるか、ということです。

限界を押し上げる

システムを試すため、SKINRの大規模テストの一環とて、SKIN切り替えのUIのリミッターを削除することで何が起こるかの確認が行われました。結果は、かなり興味深く、目に見えて分かる効果でした：

本格的なストレステストが開始され、ポテトテストサーバーで同じバブル内で500人のプレイヤーが同時にSKINを変更したのはかなり面白いものでした。これにより、システムが毎秒およそ45,000メッセージのピークに到達したのです！

このような大規模テストに参加してくれているすべての人に感謝します。このような貢献にどのような価値があるのかは見えにくいかもしれませんが、これは皆さんの参加がもたらす影響を明らかに示しています。

上記の例に戻りましょう。これは実際のところ何を達成したのでしょうか？

以前の統計では、トランキリティは一般的にサーバー全体で毎秒30,000メッセージに対応しており、平均で毎秒1回または1Hzとなっていました。一方でSKINRのテストでは、わずか500人のプレイヤーで毎秒45,000メッセージに到達しました。これはこの状況においてクエーサーが90Hzのアップデートを効果的に送信したということです。

クエーサーがノード3つだけの小規模なテストサーバーで500人のプレイヤーに90Hzのトラフィックを提供できるなら、30,000人のアクティブプレイヤーを擁するトランキリティの230のノードならば何が可能なのか？

シミュレーションフレーム自体が同じ枠組みを使用したらどうなるのか？

シミュレーションフレームが送信するのにもう1秒待つ必要がなくなったら？

これは時間拡張システムに対してどのような意味合いを持つのか？ リアルタイムで大規模な戦闘が実施される際にメタが変化するのか？

ネットワークのフィデリティが90倍に増やせるなら、デザイナーはニューエデンのパイロットにどのような新しい体験をもたらせるだろうか？

これらの質問はEVE Onlineの進化を形作っていくものです。そしてそのうちのいくつかは、2月20日15:00配信のCCP TVで回答されるかもしれませんので、ぜひご視聴ください。

o7