それに、フォートナイトは allegedly 30ティック/秒らしいよ。

クライアントの更新は73と測定されていて、128のサーバーティックと更新レートにはちょっと合わないみたい。もしかしたら、ここ5年で変わったのかも。CSGOのプライベートサーバーも128ティックレートで動いてたよ。 https://www.youtube.com/watch?v=ftC1Rpi8mtg

例えば、Fallout 76では、他のプレイヤーがどこを見ているか、または銃をどこに向けているかがわかるんだよね。撃たなくても、ユーザーの入力に応じてモデルがアニメーションする。秒間のティック数はあまり良くないと思う。というのも、同じ場所で十数人以上が何かを撃っていると、かなりのラグが発生することで有名だから。

OSRSは0.6 TPSで動いてるんだよね…つまり、1分間に100ティック。これがどれだけ違うか、ちょっと面白いよね。

バトルフィールド4が発売されたとき、ネットワークパフォーマンスがひどかったんだよね。バトルフィールド3も良くはなかったけど、BF4はそれよりもずっと悪かった。クライアントがサーバーに30Hzでアップデートを送っているのに、サーバーが返すのは10Hzだけだったんだ。[1] これはBF3と同じだったけど、サーバーの負荷の問題もあってさらに悪化して、高Pingの補正もあんまり機能してなかった。プレイヤーからの反発があって、Battle(non)sense[2]の素晴らしい分析が注目を集めて、開発者たちはネットワークコードの改善に着手することになったんだ。結局、高ティックレートのサーバー[3][4]が導入されて、最大144Hzになったけど、俺は主に120Hzのサーバーでプレイしてた。その他にもたくさんの改善があったよ。120Hzのサーバーと30Hzのサーバーの違いは、マウスとキーボードの違いがわかる人には夜と昼の差だった。ただ、その頃にはゲームは半分死んでたけど…でも、その時まだプレイしてた15人くらいには最高だったよ。

比較として、Runescape（RS3とOldschool Runescapeの両方）は0.6ティック/秒（100ティック/分）のシステムを持ってるんだ。これがこのゲームにはうまく機能してると思う。つまり、いくつかのゲームはa) ゲームプレイのメカニクスによって高いラグに耐えられるか、b) エンジンの限界やそのラグに基づいてゲームプレイのメカニクスを進化させることができるってことだ。RS3は最初、0.6秒のティックシステムに寄りかかってた（DeviousMUDからRunescape Classic、RS2への移行の名残）けど、最終的には従来のポイント＆クリックの戦闘システムの上に能力ベースの戦闘システムを発展させた。一方、OSRSはこの0.6秒ティックシステムに合った新しいメカニクスを進化させて、ポイント＆クリックの戦闘システムとシームレスに統合してる。両方のゲームを何年もプレイしてきたけど（文字通り、ログインしてた時間が何年もある）、ティックシステムが速いFPSゲームは一般的にかなり流れるように感じるから、極端なネットワークの問題以外でティックシステムが変だと思ったことはないな。これを実現するための技術的な課題はすごいよ、TFAで説明されてる通り。

大きな長方形のバウンディングボックスか球体があって、弾がその範囲に入ったときにアニメーションが発生するってことかな。これを考えるのは面白いね。ヒットスキャン攻撃はベクトルだよね？ だから、最初の交差チェックをあまり詳細じゃないヒットボックスでやって、もし「うん、これが交差するかも」と報告されたら高解像度のアニメーションチェックをする方がパフォーマンス的に得になるのかな？ それとも、そのチェック自体が高コストすぎて、フル解像度で一回だけやる方が早いのかな？ どちらにしても、こういうのはエンジニアの興味を引くよね。

より良い比較対象は別のシューティングゲームだね。Counter-Strikeは10年間も128ティックサーバーを持ってるから。

ここからは完全に推測だけど、FPSではサーバーがクライアントに多くの計算集約的なこと、例えばフォグ・オブ・ウォーや衝突判定、視線の確認なんかを頼ってると思う。これが、ウォールハックみたいなチートが可能になる理由だよね。クライアントはゲームの全状態をローカルに持っていて、どこを見てその状態を取り出すかを知っているから、マップ上の全プレイヤーの位置を把握できるんだ。もしサーバーがクライアントに他のプレイヤーの位置を知らせず、クライアントと相手が視線内にいると判断するまで待っていたら、チートの多くは基本的に不可能になるだろうね。

ネットワーク接続、ロビー、マッチメイキング、リーダーボード、チャットはそうだけど、実際のシミュレーションは、速いペースのシューティングゲームには多分向いてないだろうね。パフォーマンスの理由だけじゃなくて、BeamVMをハードリアルタイムとは呼ばないけど、コードのためにもそう。ゲームサーバーは通常クライアントだけど、ヘッドレス（レンダリングなし）で動いてることが多い。再利用やアーキテクチャに役立つよ。

彼らがUnreal Engineにかなり投資してるみたいで、それが全体のスタックになっちゃった感じだね。もっと速いCやRustがベアメタルで動いてるのを想像してたけど、そのUE4のコードスニペットは目に厳しいね。

Eve OnlineがErlangで動いてるってはっきり覚えてたんだけど、調べたら100%間違ってたわ。でも、「Vendetta Online」ってゲームがErlangを使ってるってスレッドを見つけたよ…詳細が書かれたブログはもう消えちゃってるみたいだけど。とにかく、楽しんでね！ http://lambda-the-ultimate.org/node/2102

今まさにこれをやってる！Elixirで実装したMMOゲームサーバーに取り組んでるんだ。すごく素晴らしくて、追加の観測性や信頼性の機能が無料で得られる。なんでこれがもっと人気じゃないのか分からない。プロジェクトを始める前に、BeamVMはパフォーマンス的にダメだって言ってた人もいたけど、それは間違いだった。多くのタイプのゲームでは、各ティックで高負荷な計算をしてるわけじゃないからね。クライアント間のインタラクションのルールをチェックしたり、簡単なAABBや視認性のチェックをするだけなんだ。

モダンなFPSゲームサーバーは、GC言語で書かれたら良いパフォーマンスは出ないよ。Erlangもかなり遅いし、Python並みのパフォーマンスだ。C#、Go、Javaとは大きく違う。もう一つの理由は、クライアントとサーバーが同じ言語で書かれなきゃいけないってこと。

マッチメイキングサーバーにはErlangが結構人気だって聞いたことあるよ。昔、Call of DutyのマッチメイキングもErlangで動いてたみたい。ただ、実際のゲームサーバーはパフォーマンスの理由でほぼ確実にC++だね。

これは他のゲームの「ロビータイムやエンドゲームのアニメーション」とは違うよ。Valorant（Counter Strikeに似てる）では、ゲームの開始時に60秒間武器やアビリティを買う時間がある。ValorantやCSは通常ベストオブ13で、各ラウンドの前には60秒の「バイ」期間があるんだ。

もちろんそうなるよね。彼らは全部インテルのハードウェアを買ったんだから。めちゃくちゃパフォーマンスのいいマルチプレイヤーサーバーを作ってるし、可能な限りの最適化を言及すべきだよね。もしAMDのスレッドリッパーサーバーを使ってたら、その機能も全部言ってたはず。

CS 1.6の頃、安定した<10msのサーバーでプレイしてたのが懐かしい。ヒューストン/ダラス/オースティン/サンアントニオ地域は、競争の激しいFPSアクションのミニユニバースみたいだった。俺の2mbpsのローダーナーケーブルモデムは、ヒューストンからダラスまでシングルデジットのピングを達成できたんだ。あの頃はモデムをゲームPCに直接繋いでた。

現代のマッチメイキングはスキルで人をグループ分けする 俺はゲームスタジオで働いてるんだけど、最近見たことは、もう誰も有線接続してないってこと。今や有線で繋いでるのはパワーユーザーだよ。99%のユーザーはモバイルかWi-Fiで、最初のホップか2ホップで10msなんだ。

それを考えてくれてよかったね。ちなみに、私はRiotでValorantの開発サイクルの一部に関わってたんだけど、この技術ブログでの目標はかなり大きなものでした。レイテンシーを維持することが目的だったんだよね。

お金を倍使えば大抵のことはうまくいくよね。問題はそれが機能するかどうかじゃなくて、経済的なことなんだ。ほとんどのゲームサーバーはシングルスレッドで、目標はドルあたりの最大プレイヤー数をサポートすることだから。コミュニティサーバーは、もっと多くのプレイヤーや高いティックレートをサポートするために、もっと計算リソースを使うことを気にしないよね。もし同時に100万人のプレイヤーがいるとしたら、Counter-Strikeみたいに選択肢が変わるかも。