ゲームサーバーについて調べたWSNet2, Nakama, MagicOnion + LogicLooper

C# Unity プログラム
モチベーション

ソシャゲみたいなゲームを作りたいとき、インゲームのロジックをサーバー側に持たせられるとチート対策とかが楽になる(はず)。なのでゲームロジックをサーバー側に書ける(サーバー側でゲームループが存在する)フレームワークを個人的に調べました。これはその備忘録的なやつです。 ググった結果、3種類のフレームワークが出てきたのでそれぞれを簡単に比較します。なお、私はソーシャルゲームの実装をしたことはないし、実際に動かしたりはせずドキュメントを軽く読んだりした程度なので、参考程度でお願いします。間違っていたらごめんなさい。マサカリは優しく投げてください。

比較

それぞれのフレームワーク名と、ゲームロジックを記述できる言語は以下の通りです。

ゲームサーバーにゲームロジックを書く都合上、速度が早い方がいいのとソシャゲはメンテによるダウンタイムが許容されがちなので、スクリプト言語ではなくコンパイラ言語で比較することにしました(とはいえJavaScriptも最近は十分早いし、この基準は微妙かも)。

そのため、サーバーサイドの言語はC# または Go で書くことになります。ただGoは Let’s Encryptでもあったようにメモリ操作によるバグを作ってしまう可能性があるので、Nakamaは一旦選択肢からはずして調べることにします。私がGoを書きなれていないだけなので、この問題は人によっては無視できますし、このタイミングでGoで書きたいからNakamaを選ぶ、というのもありだと思います。

WSNet2 と MagicOnion + LogicLooper の比較
  • WSNet2
    • Dashboard が付いており、サーバーや部屋の状態が見える。プレイヤーのキックなどもできる。
    • WebSocket ベース。
    • API サーバー的な使用はできなさそう。
  • MagicOnion + LogicLooper
    • Unity との連携があって楽。
    • API サーバーとしても使える。
    • Http2
    • Unity と連携がすごい代わりに環境構築が大変。Git の管理も考えないといけない。
    • Dashboard 機能はない。自分で作る必要がある。
      • Blazor とか MessagePipe を使ったりすれば良さそうだけど、やり方がいまいち分からない。

比較するとWSNet2の利点はDashBoard機能、MagicOnion + LogicLooperの利点はUnityとの連携機能とAPIサーバーとしても使える、というところでしょうか。

性能的な話ではWSNet2はプレスリリースで.xlarge (vCPU 4、メモリ 8GiB) のサーバで 1 台あたり約 6,000 人の同時接続が可能と謳っているので十分そうです。MagicOnion の方には具体的なものは見つけられませんでしたが、UniRxやUniTaskを作っているCySharpさんなので信頼して大丈夫だと思います。

個人的にはリアルタイムサーバーの管理画面はそれほど重要ではないと考えています。特定のバトルの再現などをするにはどちらにせよ自分で作る必要があると思いますし、MagicOnion を選択して問題ないと思います。
私はとりあえずMagicOnion＋LogicLooperを使ってみようと思います。

以下余談


ソシャゲのAPIサーバーとしてはGS2というサービスもあります。APIサーバーにはゲームロジックは書かないのでGS2で十分カバーできるかつ1から機能を作らなくて済むので十分選択肢にはいる、というか個人開発なら積極的に活用すべきだと思います。

あと素人考えでは、WebSocketが使える普通のWebサーバーに1秒で60回処理するループを入れればゲームサーバーになりそう。ただ、車輪の再発明であることは間違いないですし、パフォーマンスなどを考慮すると、賢い選択肢ではないですね。

あとゲームサーバーで調べるとAgonesというのがめっちゃ出てきます。ただ、Agonesはゲームサーバーのインフラ管理をするやつです。ゲームサーバーをkubernetesで管理するときに使うもので、ゲームサーバーそのものではないです。最初この辺がわかってなくて時間を浪費しました。

逆に言えば上記の3つのフレームワークと組み合わせることができるはずです。




書き終わった後に気づいたんですが、もしかしてLogicLooperを使うならサーバー側はなんでも良いんですかね？

neue cc - AlterNats - ハイパフォーマンスな.NET PubSubクライアントと、その実装に見る.NET 6時代のSocketプログラミング最適化のTips、或いはMagicOnionを絡めたメタバース構築のアーキテクチャについて

この記事の中でLogicLooperをMagicOnionから剥がして使うとか書いてますし。 何ならLogicLooperとMagicOnionの間にNATSを噛ませているのでMagicOnion側、つまりUnityと通信するサーバー側は文字通り何でも良い(C#のサーバーである必要さえない)ように思えます。しいて言えばWebSocketかなにかでUnityとリアルタイム通信が可能なことぐらい？秒間何回もAPI叩くわけにもいかないですし。