マイクラ 1.18 の話

この記事は、今後随時追加・変更・訂正・削除する可能性あり。
また流動的な内容を取り扱っているため、間違った内容となる可能性もあり。
さらに掲載後の時間経過によって、最新版を対象とした記事でなくなる。
これらに十分注意し、記事を参照すること。

Java版(JE版、Java Edition)の記事。
統合版は若干仕様が異なる場合があるので、注意。

  • Y(上下)座標が拡大された。
  • バイオームの新設や整理が為された。

この辺の話は、調べればよく聴く話だと思うので割愛。

敵 Mob の明るさに関するスポーン条件が変更になった

今までは明るさレベルが7以下がスポーン条件だったが、これが0でないかぎり、つまり光源ブロックからの明かりが少しでも当たっていれば、敵 Mob はスポーンしなくなった。

そのため、今まで湧き潰しが甘い箇所箇所が近くにあったりすると、クリーパーが湧いたりして、いきなり背後で爆発に巻き込まれるとかあったが、このような事態は、かなり減った。

むしろ地上拠点など、湧き潰しされてる空間上での不意な「湧き」がかなり少なくなってしまったので、当初は「アップグレードのバグか?」と思ったぐらい。

鉱石分布の変更

すでにブランチマイニングされているエリア(チャンク)は、掘ってなくてもワールド(ブロックの情報)が生成済のため、それが書き換わることはない。
しかしながら、今回追加した Y=0 より下の層や未踏のエリアについては、プレーヤーの移動によって追加生成されるのだが、その際注意しなくてはならないのは、鉱石分布の変更。

特にダイヤモンド鉱石の場合、今までは Y=1~15 に分布していたが、1.18 では Y=16 以下、しかも深くなるにつれ、出やすくなるように変更された。
(ただし溶岩溜まりなどの Y 座標は 1.17.1 と同じなので、深層を掘る際のマグマダイブは従来通り注意が必要だし、横掘りや上掘り時の注意も必要)
それ以外の鉱石についても、一定数の生成頻度とは別に、出やすい高度の傾斜が追加された。
そのためブランチマイニングなどの効率重視の場合、目的の鉱物別に高度を変更する必要があるなど、適宜方針変更する必要が出るくると思う。

以下、気になったら記事追加する予定。

Spigot 1.17.1 ⇒ 1.18 アプデしてみた

Minecraft Java版も 1.18 になり、Spigot も 1.18 が公開されたので、うちの貧弱環境で動作するのかも含めて、早速アップデートしてみた。

ちなみにシングルで遊ぶのであれば、自分のPC上で「シングルプレイ」で普通に遊ぶのが、あくまで一般的なはず。
最近のゲーミングPCであれば、スペックとかも問題ないはず。

この記事は、Spigot サーバをわざわざ建てて、マルチ環境でシングルプレイするという奇特な人(私)を前提とした内容。
なので、その辺の無粋なツッコミは、なしの方向で。

もうメモリ1Gではムリです。

今まで「さくらのVPS 1Gプラン」で稼働させてましたが、1.18 へのビルド・アップグレードについては、なんとか可能。
しかしながらゲーム中の動作中、以下のような事象が発生していた。

  • 移動やブロック破壊中などの動作が、固まる。そして数秒前の状態に戻る。
  • チェストやインベントリを開くことができない。
  • 新規エリア(チャンク)移動の際、トロッコやボートなどの速い速度で移動すると固まったり、ゲームが強制切断される。
  • 普通に移動したり、ブロックを破壊していてもゲームが強制切断されることがある。
  • 強制切断後、再接続できない。

このような状態になっていると、往々にして Spigot サーバーのコンソールに、以下の過負荷警告が繰り返し表示されることがある。

> Can't keep up! Is the server overloaded? Running XXXXXms or YYY ticks behind

【意訳】
もうついていけねぇ! サーバーが過負荷じゃね? XXXXX ミリ秒または YYY ティック遅れてる。
(ティック:ゲームの処理単位、マイクラだと1/20秒単位)

つまり現実時間軸に対して、ゲーム内の処理量が多すぎて時間が追いつけていないという状態。
これが積み重なるとゲームは処理落ちを跳ばして無理矢理、時簡短縮をしたり(プレイヤーは見かけ上、コマ落ちやキャラがワープしたように、移動や操作前の状態に巻き戻されたように見える)、ゲームが強制終了してしまう。

ちなみにこの事象、1.18 ほどではないにしろ 1.17.1 でも発生していた。
それでも 1.17.1 の場合、個人的にはシングルプレイで利用するかぎり、まだ耐えられる程度だったが、1.18 では頻発するため、さすがにストレスがキビしい。

いずれにせよ、この現象はメモリ不足や処理の過負荷が原因。
1.18 にはアップグレード(ビルド・インストール)できるものの、プレイは現実的ではない
という結論。

対策、カネで解決するしかない。

そのため、急遽 VPS のプランを 1G ⇒ 2G に変更。
その結果、頻発していた負荷警告は(発生はするものの、1.17.1 の時よりも少ない状態に)収まった。

この状況から、今後のマイクラ JAVA 版は、普通にゲームするだけでも、少なくとも2G以上のプランが必須となってきそう。

ちなみに Spigot の動作スペックを少し調べてみたが、どうやら最近は 2GB 以上のメモリを最小としている模様。
もしかしたらメモリ 1G での挙動させる猛者はいるのかも知れないが、普通に Spigot をセットアップしてあくまで標準的に利用する場合、メモリ 1G での動作は無理だと思う。

あと以前の記事にも記載した通り、自分が利用しているサーバは契約自体が年間契約のものを流用した関係と、AWSなどを再契約した場合、またイチからサーバを構築しなくてはならない。
そのため今回は緊急避難的にスケールアップで対応し、契約満了までは利用することにした。

しかしながら 1G⇒2G へのプラン変更は、概ねどこの VPS サービスもそうなのだが、利用料金がほぼ倍になってしまう。正直なところ、お値打ち感はない。

なので個人的には契約満了後、AWS(EC2)に切り替え、かつ弾力的にインスタンスの開始/終了ができるようなシステムを構築する方向で、費用圧縮を考えている。

1.17.1 ⇒ 1.18

そして本題です。

まずビルド・実行にあたり、Minecraft 1.18 は java 17 のバージョンが必須となる。
そのため、まずは java のバージョンを 16 ⇒ 17にアップグレードする必要がある。

でも、何はともあれ、まずはバックアップから。

# sudo su
# cd /opt
# cp -a spigot spigot.1.17.1
# exit

自分の場合、spigotを導入している /out/spigot ディレクトリ配下を、権限そのままで、ごっそりコピー。

ちなみに apt コマンド等は Ubuntu 20.x.x の場合。
CentOS や Windows など、各自のOS環境や権限、ディレクトリ構成などによって、手順やコマンドや手順は異なる。
そのあたり、各自で適宜調べて実施する必要あり。

次にパッケージインデックスを更新。

$ sudo apt update

ついでに、他のアップグレードがある場合、必要に応じて更新。

$ sudo apt upgrade

自分の場合、最も環境変化の影響の少ないアップグレードをしている。(余計な機能は追加しない。)

本題に戻り、OpenJDK 17 をインストール。

$ sudo apt install java-17-openjdk

最後に Java 17 になったか、バージョン確認。

$ java -version

これでjava 17.x.x がバージョン表示されればOK。

次に ビルドツールを最新化。

$ cd spigot
$ rm BuildTools.jar
$ wget https://hub.spigotmc.org/jenkins/job/BuildTools/lastSuccessfulBuild/artifact/target/BuildTools.jar

このビルドツール、頻繁に更新されていて、古い BuildTools.jar だと最新版のビルドができない場合が多い。
なので BuildTools.jar は、常に最新版を使う。

必ず Spigot 公式が提供している jar ファイルをダウンロードして使用すること。
BuildTools.jar をググったりして探すと、野良サーバの jar ファイルがヒットすることがある。これがセキュリティ上とても危険。
必ず公式サイトからダウンロードしているか、URLを確認すること。

そしてビルド。

$ java -jar BuildTools.jar --rev 1.18

これによって、Spigot 1.18(Spigot-1.18.jar)がビルドされる。

次に、既存のワールドデータや設定ファイルなどを、1.17.1 ⇒ 1.18 にアップグレードしつつ、spigot サーバを一旦起動。

$ java -jar Spigot-1.18.jar --nogui --forceUpgrade

このタイミングで、現時点でのワールドデータやプレイヤーのデータがすべて書き換わる。

ちなみにこのアップグレード作業、ワールドの広さによって、かなり時間がかかる。
もしかしたら半日以上とか、かかるかも。
自分の場合、まだ数百座標単位しか展開していない。
しかしそれでも 15 分ぐらいかかった。

だからといって、上記コマンドを入力したら、絶対に途中で止めず、辛抱強く待つこと。
途中で止めると、ワールドデータが破損する可能性があり、その場合、二度と起動できなくなる可能性すらある。

無事に起動が確認できたら、一旦停止。

> stop

Spigot を終了させる。
そして最後に –forceUpgrade オプションなしの状態で Spigot を再起動。
これで問題なく起動し、ゲームにログインインして普通に操作できれば、アップグレードは無事終了。

以上アップグレードの作業そのものは、特段難しくはない。
しかしながらアップグレード前に、サーバースペックの問題を確認・解決する必要がある。

マイクラサーバ、立ち上げの試み

この記事は、今後更新される可能性があります。

サーバのインストール手順については、ググると先達の Web 記事がいくつかヒットするので、ここでは解説していない。
あくまでプラン選択の経緯を記事にしてみた。

また、利用したマイクラサーバは Vanilla(バニラ)ではなく、今後の利用を考えて、Spigot を選択。

さくらのVPC 512MB プラン

以前は512MBなど、低スペックなVPCサーバでも利用できたようなので、元々所有していたサーバ契約を流用して、インストールを試みてみた。

ビルドは何とか成功、でも起動しない。

コンパイル時にもメモリ不足のエラーが表示されたが、無理矢理ビルドすることは可能。
しかしながら、サーバ実行(起動)の過程でメモリ不足となり、立ち上がらなかった。

さくらのVPC 1Gプラン(今ここ)

こちらのプランだと、サーバも起動できる。
ところがプレイ中、ボートやトロッコなどで高速移動すると、処理落ち(移動が巻き戻ったり、切断、例外発生によるサーバーエラー終了など)が頻発。

原因がメモリ制御なのか、処理速度(CPU)の問題なのかは不明だが、いずれにせよ、メモリ1Gであっても、新規ワールド(空間)への立ち入りや複数人でサーバに接続すると、かなり不安定になるのではと思う。

現状、拠点でブランチマイニングや、精々近所の村や洞窟探索を中心にプレイしてるので、何とか動作している。
しかしながら飽き足らなくなれば遠征することになると思う。
おそらくそれは、時間の問題かと。

結論

メモリは最低でも1G以上必要、ただし限界は近い

おそらくクラウドサービスを利用してマイクラサーバを立ち上げる場合、CPU やハードディスク容量については、一定以上のプランを利用すれば、ほぼクリアできることが判明した。

しかしながら Java を利用しているため、初期のモジュールビルドにも、マイクラサーバの実行にも、とにかくメモリを喰う。

おそらく2G以上のサービスを利用するのが安泰だと思うが、そうすると今度は、費用面が問題になると思う。
例えば、さくらインターネットの場合だと、プランを1G⇒2Gにすると、基本料金がほぼ倍になる。
ざっくりだが、年額でおよそ1万⇒2万の差。
いくつか他の VPC 事業者もみたが、ほぼ同じ傾向。

個人的にはAWS(EC2)に移行しようと思ってる

ちなみに仕事用を中心に、オンプレサーバをクラウドに移行したので、玉突きで空いたオンプレサーバをマイクラサーバにしようかとも思った。

しかしながら、オンプレサーバのディスクをSSDに換装したり、電気代などの維持費を考えると、先のクラウド移行した理由が破綻してしまう。
なので今のところは、AWS(EC2)などのインスタンスの自由度が高いクラウドにマイクラサーバを移行することを検討中。

ただし、正直なところ AWS のようなクラウドサービスは、一般的な VPC サービスに比べて、設定や操作が煩雑なのと、費用面のコストが見えにくいので、かなり躊躇している。

しかしながらインスタンス(CPU やメモリのスペック)切替が容易なところは正直魅力的だし、バッチを頑張って作れば、未使用時にはサービス停止して、費用節約も不可能ではない。

でもまぁ、さくらインターネットのVPC契約を1年契約にしてしまったため、とりあえず、解約時期までにEC2環境を整備しておこうかと考えているところ。

マイクラおじさん、はじめました。

最近この歳になって、VTuber にハマってしまい。
その影響で、今さら Minecraft にハマってしまい。

…この流れで察することができる人は、そこそこいるのではないかと。

という事で、今回は環境の話。

現在のマイクラには、C++でコーディングされた「統合版」(Bedrock Edition, 通称 BE)と「Java版」(Java Edition, 通称 JE)の2種類がある。
歴史的には「Java版」がルーツだが、ゲーム機やタブレット端末では「統合版」のみ利用可能、対して PC では「統合版」「Java版」の両方が利用できる。

なぜ「統合版」のみがスマホやゲーム機に対応したのか考えてみたが、おそらく Java Runtime Environment(JRE)がボトルネックになっているものと思われる。

Java とマイクラ(というかゲーム)は愛称が良くなかった

そもそも Java は、Oracle の方針など諸々の経緯から、現在「事実上」PC 向けのプログラミング言語になりつつあり、スマホなどのモバイル機器やゲーム機などの環境、特にゲーム分野においては距離を置かれつつある。

その理由として、 JRE(いうか Java)は、スマホやゲーム機の場合、原則としてハードウェア側に Java (JRE)が「別途」インストールされていることが前提となる。
この「別途」というのが曲者。
たとえば Java のバージョンアップに対応する必要が常に生じるわけで、デバイスによってはそれが難しい場合がある。
しかも Java は(表現の適切かは、さておき)「半分コンパイルしたプログラムを半分インタープリターで動かす」つまり「ランタイムプログラム」というアーキテクチャー上、動作時のメモリと CPU の負担が大きい。

Java 版のゲームプログラム側でこれらの差異を補完することは、できなくはないとは思う。
しかし当然ながらアプリ本体が巨大化するだろうし、レガシーな機種を意識する必要が生じてしまうため、ゲームの発展を考えると、それが「足枷」にもなってしまう。

オフィスなどの業務システムについては、今まで C/C++ 言語などでの生じていた開発コストが、Java の登場と発展によって削減されたり、オブジェクト指向の概念の加速化など、プログラミングの世界において貢献した点は色々とある。
ただゲームなどの機種(スペック)差や、挙動がシビアなソフトの開発には向かなかったという事だと思う。

JRE は際限なくメモリを喰う

メモリ制御が重い

Java においてもメモリ制御は、プログラミング次第で柔軟にできる。しかしながら、この処理が正直、重い。

これはマイクラのプログラミング上の問題でもあるのだが、たとえばマイクラは、一般的な RPG などとは異なりワールドの生成が、キャラクターの移動に応じて、動的に生成される。
このワールド情報、一度生成されてしまえばデータが保存されるので、それ以降はデータの読み込みのみになり、負担は下がるのだが、それでもメモリを大量に消費したり、解放する場面がある。

こういった場面は他のゲームでもあるとは思うが、前述の通り Java はランタイムプログラム経由という構造上、その処理がどうしても遅くなってしまう。

メモリを喰う

ただでさえ JRE の動作だけでもメモリを喰うのに、マイクラ本体を稼働させるのに、さらにメモリを喰う。

これをスマホやゲーム機など、性能差のあるデバイスで採用するのは、おそらく現実的ではなかったのだと思う。

そのため「統合版」は、C++ で作成され、かつ、各デバイス毎に対応したことにより、ラグなどを生じない形でのゲームを展開することができた。
おそらく、この選択肢がより現実的だったのだと思う。

ただし Java 版にもメリットがある

それは Java にすることによって、「有志」が独自の機能を追加することが容易になった点にある。

これは自前のサーバを立てることも可能にし、自前のサーバー上でワールドを構成、しかもマルチプレイをすることが可能にした。
しかも、それぞれ別々のワールドを、ポータル(穴)を経由して接続することも可能。
それ以外にも様々なプラグインなどが展開され、独自の拡張・発展を続けている。

ちなみに「統合版」も Microsoft が独自に提供している Minecraft サーバサービス等を利用しており、それを利用すれば、マルチプレイが簡単にできる。(ただし有料サービス)

さらに「統合版」の場合、様々なイベントや追加 Mod が提供されており、いわゆる大衆的なゲーム要素を公式が提供するという、本来のゲームサービスの姿となっている。

Java 版の未来

正直なところ、個人的には悲観的に考えている。

現在 Minecraft は Microsoft が買収し、サービスを提供している。
そして開発形態も、以前は「Java 版」でアップデートされた機能を、各デバイスなどのプラットフォーム版(「統合版」になる前の姿)に移植される形だったが、現在は「統合版」で実装された機能を「Java 版」に移植するという「逆の流れ」になってしまった。

これはおそらく、開発コストなどを踏まえた結果だと思うが。Java 版の開発が後発になった事に、正直不安を感じている。

「統合版」で実装された機能が「Java 版」で実現できなくなる未来

現時点でも「統合版」と「Java 版」の間では、細かな機能や挙動が異なる部分が既に生じている。
そもそも Java は、前述の通り、このようなスタイルのゲームの開発言語としては向かない、ボトルネックになっている事がという事が立証されている。これは今後致命的になると思っている。

「『統合版』だけあればいいんじゃね?」という流れに向かうのはとても自然な気がするのだが、この考えは杞憂なのだろうか。。。