【Minecraft Server】備忘録 : Java/統合版クロスプレイ環境で快適に遊ぶためのサーバ軽量化設定など
コマナズです。前の記事に引き続いて、Minecraftサーバの運用者をターゲットにしたお話をします。
背景
近頃はMinecraftの統合版（スマホ、Switch1/2、PS4/5 ) のユーザが急激に増ています。一方で、利便性の面やMOD等のカスタマイズ性から、Java版のプレイヤーも十分な数存在します。そこで、GeyserMC を使って Java版 と 統合版 のプレイヤーを同じサーバで一緒にプレイさせたいケースも増えてきています。
その中で今回のテーマは、GeyserMC でSwitch版 / PS版ユーザを参加させる際の、パフォーマンスの課題点について解説します。
前提
- この記事は、Minecraft 1.21.x (Java Version) 時点の内容を記載しています。
- Switch版から外部サーバへアクセスする方法の解説は、以下のサイトで仕組み付きで解説していますのでおすすめです。 www.radical-dreamer.com
課題 : Switch / PSプレイヤーが頻繁にサーバから落ちてしまう
GeyserMC によるJava版 / 統合版クロスプレイサーバを運用した際に、ある課題が起きていました。それは、「Switch/PS版ユーザが頻繁にサーバから落ちてしまう」課題です。
Switch版やPS版といった、コンソール環境では、以下のような様々な課題が山積みで、完全な解決は困難です。
- 非公式の海外サーバ ( BedrockConnectサーバ) を経由するため、根本的にスマホ・タブレットよりもラグを抱えやすい
- Switch版 / PS版ユーザは BedrockConnect 接続と呼ばれる非公式な手段でしか外部サーバへのまともなアクセス手段がありません
- スペックの限界 (とくにSwitch1) があり、処理が重くなりやすい
- 無線環境であることが多く、有線と比較してラグがある
- PC版プレイヤーほど高速通信環境の整備に熱心でないユーザが多い
そのため、通常はプレイヤー側で「描画距離を短くする」「描画品質を見直す」「通信環境を見直す」など設定して、なんとか入れるようにお願いすることが一般的です。それでも、「なんとかしてSwitchやPS版ユーザにもサーバで快適に遊んでほしい」という思いから、サーバ側で設定できそうな項目を色々試したりしました。様々な設定がある中で、比較的簡単にできること、かつ有用だと思われる策を試したりしました。
もしかしたら他にも色々検証している方がいるかも知れませんが、備忘録として残しておきます。「もっとこんな設定もいいよ！」とかあれば教えていただけるとありがたいです。
改善案
策として有効そうなものを挙げてみます。
不必要なプラグインは抜く
なんだかんだ忘れがちなのがコレ。特に、「goBrush」「Voxel Sniper」のような地形生成のみでしか使わないような重量級プラグインはサーバが重くなる原因です。地形生成中はすごく便利ですが、サーバ運用期間中は抜いておいたほうが良いでしょう。もちろん必要なプラグインはしっかり入れましょう。
Spigotではなく、PaperMC / Purpurのような軽量化されたサーバを利用する
サーバを運用する前に見直しておきたい部分はここです。そもそもPaperMCやPurperはSpigotを軽量化 (メモリ消費量削減、サーバ負荷削減など) したサーバプログラムです。もしまだSpigotを使われている方はこれを機に見直すのもありかもしれません。
- PaperMC : https://papermc.io/
- Purpur : https://purpurmc.org/
spigot.yml の設定で view-distance や simulation-distance を下げる
今回試してみて特に影響が大きい設定でした。
設定するとサーバ側の描画距離が短くなってしまうため、「遠くが見えなくなってしまう」というデメリットがあります。Java版プレイヤーであれば「bobby」MODなどクライアント側の描画距離で表示するMODを導入するようにすれば、この課題はある程度は回避可能です。
適度に軽量化するのであれば、view-distance はデフォルトの10 (7未満はおすすめしません)、 simulation-distanceは 6 くらいがおすすめです。
world-settings:
default:
view-distance: 10
simulation-distance: 6
Bobby : modrinth.com
この他にも、同じymlファイルでいえばMobの湧き率を調整するなどの効果も大きいです。ただ、ゲーム性に関わったりするので、あまりおすすめはできなさそうでした。
server.properties の network-compression-threshold を調整する
気持ち改善するかな？というような設定です。
この設定は、ネットワーク通信の圧縮率を設定します。パケットのサイズが設定したしきい値を超えたなら圧縮され、それ以下ならそのまま送信する設定です。デフォルトは256ですが、2倍近い512とかに設定してもいいと思います。通信内容の圧縮化をすることで、通信サイズが小さくなって一見良さそうですが、かえってラグの原因になるので適度な調整が良さそうです。
network-compression-threshold=512
必要十分なサイズのメモリ割当を行う
おそらくまず考えそうなところなので、念のため。例えば、50人入るようなサバイバルサーバで4GBしかない、というようなケースではメモリの増設が効果的になるケースはあります。ある程度まではメモリの増設は効果がありますが、必要以上に増やしすぎるとこの効果はかなり限定的になるばかりか、かえって悪影響を及ぼすことがあります。なぜなら、定期的にメモリを開放する際に、一度に処理が走りすぎてかえって負荷が高くなるリスクがあるためです。
| メモリサイズ | ユースケース |
|---|---|
| 2GB | 少人数の仲間内の小さなサーバ (このケースなら、Realmsの方が簡単)、評価用のサーバ |
| 4GB | 10人規模の通常のバニラサーバ |
| 8GB | 中規模のバニラサーバ |
| 16GB | 大規模のバニラサーバ、小規模なMODサーバ |
| 32GB以上 | 大規模なMODサーバ |
以上です。他にも有効そうな設定があったらコメントとかで教えていただけるとありがたいです。
おまけ : 「CubeCraft」だけは特殊？ なサーバ事情
ここからはおまけの情報共有です。
Switchからクロスサーバにアクセスする場合は、任意の「特集サーバ」にアクセスし、そこを踏み台にして BedrockConnect 経由でアクセスする、という手段となります。しかし、正確には任意ではありません。この「特集サーバ」のうち、唯一「CubeCraft」にアクセスした場合だけ BedrockConnect にアクセスできません。この場合は普通に CubeCraft のサーバに入ってしまう現象がありました。
理由はわかりませんが、おそらくCubeCraft自身が Java / 統合版クロスサーバの仕組みを独自で持っていることが要因であると考えられます。なにより現在は CubeCraft 自身が GeyserMC のプロジェクトを統括している大元である関係もあるようです。興味ある人は以下のサイトも見てみてください。
