「Minecraft」タグアーカイブ

スライム（mob）のスポーンを再考察

ここでは Java Edition の話をしますが、Bedrock Edtion（統合版）でも数値や条件は異なるものの、ある程度は参考になる考え方だと思います。

理由は、1.18 あたりのバージョンアップからスライムチャンクが機能しなくなったから。

スライムが全く湧かなくなってしまった………

理由はおそらく以下

  • Y座標が 0〜256 だったのが、1.18 で -64〜320 に広がったから。
    • ここでは特に「地下」が広がった点が、重要な要因。
  • 今まであまり歩き回っておらず、ワールドが生成されていなかったから。
  • 他の mob 湧きに影響する。

Y座標（上下座標）の話

ちなみに 1.17までで生成されたワールドも、1.18 にバージョンアップし、ユーザがログインしたタイミングで、ワールドの生成条件に従って、追加された地下についてもワールドが大幅に広がる（追加生成される）ようになった。

しかも 1.18 からは、鍾乳洞（Dripstone Caves）などのかなり大規模な洞窟バイオームが生成になった。その影響で大きな空洞が作成されるようになったため、そちらに mob が湧くようになってしまったのが影響している。

ちなみに 1.17 以前は、地上を規準としたバイオームが生成されていた（地上が河川バイオームであれば、それは地下（岩盤）まですべて河川バイオームだった）。
しかしながら、現在はそうとは限らず、別途「地下バイオーム」が設定されるようになった。
そのため地上と地下では、異なるバイオームが生成される場合がある。

ワールド生成の影響

今まで拠点を中心に、ブランチマイニングしつつ必要な建築や装置を作成していた。
そのため、個人的にあまりワールドを広げていなかった。
（まぁマイクラ経験も浅いし、これは個人的なプレースタイル都合の話なのだが。）

しかも最初はPC環境が貧弱だったことから、描画距離もかなり狭くしていた。
そのため、そもそも生成されているワールドが狭かった影響もあり、mob 湧きが制限されていた。

しかしながらプレーするにつれ、行動範囲も広がり、またPC環境も大幅に整備したことにより、描画距離を広くした。

これらの影響によりワールドも広がったため、そこに mob が湧く余地ができてしまったことも要員だと思われる。

範囲に重点を絞った mob 湧き条件の話

マルチプレイの場合、サーバ環境の設定や他のプレーヤーの行動状況にも左右される可能性があるため、一概には言えません。

ワールド生成の条件

そもそもワールドが生成されていない場所に mob は湧かないので、まずは最初に影響するのは「これ」になる。

そして生成は「描画距離」に影響し、その公式は「描画距離×2-3」とされている。

つまり Java 版の描画距離は 12 チャンクが初期値（既定値）なので、それを規準に考えると、（また水平方向の場合は 1 チャンク＝ 16 ブロック平方なので）

12×3-3=21チャンク＝336ブロック

という形でワールドが生成されている。

……と、ここまで書いたものの、基本的に次に書いている「mob の湧き条件」よりは広いので、これが mob 湧きに影響していることはかなり少ない

mob 湧きの条件

こちらは純粋な湧き条件。とはいえかなりややこしいのだが。

  • プレイヤーから「25 〜 128 ブロックの球形」範囲にスポーンする。チャンク換算でおよそ 1.6〜8 チャンクの範囲。
  • 湧き条件に適したブロックの上であること。
    • 透過ブロックや下付ハーフブロック、ブロックのない空間でないこと。
      （ただし空中や水中で湧くmob など、一部 mob については条件が異なる。）
  • mobの大きさに応じた空間。
    • mob のサイズよりも小さな空間にはスポーンできない。
  • 日光があたる場所においては、明るさ 7 以下。
    • つまり、夜または雷雨状態の中。
  • 地下の場合は明るさ 0
    • 以前は明るさ 7 以下だったが、1.18 からはこの条件に変わった。
  • バイオームに毎に設定されたスポーン確率。
    • 湧き条件がバージョン毎に調整・変更される場合あり。
  • 地域難易度。
    • ワールドのプレイ時間や月齢・難易度などを元にした複雑な計算式。
    • この項目は、概ね「mob が武器を装備した状態でスポーンする確率」といった「副次的な条件」としてよく使われるが、スライムの場合はスポーンする際の「大中小サイズ」に影響する。

…… 以上が代表的な条件。これ以外にも細かな条件がある模様。

スライム特有の湧き条件

しかもスライムの場合、バイオーム毎に設定されている mob の「スポーン確率」とは別に、さらに以下のいずれかでしか湧かない「追加条件」がある。

  • 沼地バイオーム
    • Y=50〜70、明るさ 7 以下
  • それ以外のバイオーム
    • Y=40 未満のスライムチャンク

一般的にスライムトラップを作成する場合、（拠点近くにあれば別だが）沼地バイオームをわざわざ探し、そこに設置するのは面倒。
そのため、通常のバイオームの地下（Y40以下）にトラップを作成することが多いと思う。

あと、これは自分が個人的に感じているだけの話なのだが

（確証はないが）どうも他の mob の湧き条件に比べると「低い」気がしている。
というのも、湧き条件とは別にスライムの場合「大きさ」が影響しているのではないかと。
スライムの場合、大中小があり、それぞれ 2.0808、1.0404、0.5202ブロックのサイズとなっている、しかも小数点以下見ていただくと判る通り、それぞれ 3、2、1 ブロック立方のサイズが必要。

これと「地域難易度」が影響しあって、以下のような状況が発生しているのではないかと。

規準となる湧き場所（洞窟内）にて
mob の湧き条件で「スライム」湧きが「確立」
↓
地域難易度にて「大サイズ」
↓
3ブロック立方の十分な湧き空間が存在しない
↓
スライムの湧き「失効」

これが影響して、洞窟内には結果的に1ブロック四方で湧くことのできる他の mob が沢山湧いてしまっているのではないかと思っている。

対策

つまり、スライムチャンクを設置した場合、最低でもその周囲８チャンクについては、地下も含めて湧き潰しが必須となる。

またスライムの湧き条件が Y=40 未満のスライムチャンク（または Y=50〜70、明るさ 7 以下の沼地バイオーム）のため、スライムトラップを作成する場合、岩盤までにある洞窟はすべて湧き潰しを行う必要が出てくる。

また同じく、河川や海にいるイカやタラ・鮭・熱帯魚などの mob なども影響しそうなため、これら水中についても湧き潰しをする必要がありそう。

基本的な湧き潰しとしては、松明を建てるのが最も効率的だと思う。
ただしスライムについては、明るさに関係なく、空間さえあれば洞窟内でも湧いてしまう。

そのため、スライムトラップで確実にすべてのスライムを湧かせたいのであれば、トラップの周囲８チャンク内にある洞窟という洞窟は、すべて埋め戻す必要があるという事になる。

（まぁ実際のところ、それはさすがに時間の無駄。なので松明だけで置き、多少空間のある洞窟があって、そこにスライムが湧いてしまっても、無視するということになるとは思うが。）

要するに

ゲーム進行により開拓が進んで、さらに 1.18 になって、色々と「めんどくせー」ってなった、というお話。

マイクラ 1.19 にアプデしてみた。

こちらの記事は今後随時追記していきます。

こちらは Java Edition に関する記事です。統合版とは仕様が異なる点がある場合がある等、ご注意ください。

大型アプデからおよそ１ヶ月経過したので、アプデしてみた。

ちなみに１ヶ月空けたのは、自鯖で spigot 使ってたり、大バグを警戒しての理由。
あと、Dynmap や OptiFine, Forge といったプラグインや mod の 1.19 対応を待っていたから。

アプデの話

基本的には、1.17 ⇒ 1.18 にアプデした時と手順は同じ。
今回 Java のアプデは必要なかったので、そのぶん手順は減ったけど、modのアプデが、現時点では一部間に合っていない。

Forge

41.0.100 の話

１ヶ月経過してもβ版

いつ安定版になるんやろか。

やっちまった

Spigot をアプデして、クライアントはノーマルな状態で動かしたら問題なかったのだが、その後β版 Forge をインストールしたところ、起動時に見事クラッシュ。

おそらくその出かけた普通の自分の場合、手懐けたネコの種類（ネコの柄）が、すべて Tabby になってしまっている。
でもって data コマンドで調べてみたところ、CatType というネコの種類を指定する値がどうも見つからない。
おそらくこれが原因で CatType=0 つまりTabby になってしまっている模様。

これがクラッシュの影響なのか、β版を入れた影響なのかは判らない。

OptiFine との同居不可

1.18.2 の環境では Forge の中に OptiFine も同居できたが、1.19 対応の現バージョンでは同居不可。起動時に Java がクラッシュする。

追加された仕様とかの話

泥ブロックとかカエルとか古代都市の話は、他サイトの記事で沢山取り扱われているので割愛。

チェスト付きトロッコ・ホッパー付きトロッコ・かまど付きトロッコ・TNT付きトロッコ、破壊時にトロッコと別々に分解されなくなった

なので一度これらの合体トロッコを作成すると、永久にそのまま使うことになる。
これが意外と鬱陶しい。

というのも、ここ数年のバージョンは（地下が深くなったり、バイオーム分布の影響で？）地下廃坑がかなり多く生成されやすくなった感じがするので、地下の湧き潰しがてらブロック収集していると「チェスト付きトロッコ」が割と見つかる。

これが今まではチェストとトロッコに分解できたので、それぞれ別用途に流用できたけど、今後は永久に「チェスト付きトロッコ」のままなので、使い道が限定されてしまった。

個人的にチェスト付きトロッコの使い道は、現状ほぼゼロ。
そのため当面は死蔵品。今後チェスト付きトロッコを使うような仕掛けを作る機会は…あるのかなぁ…

マイクラ 1.18.1 の話

この記事は、今後随時追加・変更・訂正・削除する可能性あり。
また 1.18 の頃の話も含まれている。
そのためこの記事はマイナーバージョンの変化も含めて、一つの記事で流動的な内容を取り扱っているため、他のバージョンとは挙動などが異なる場合あり。
さらに掲載後の時間経過によって、最新版を対象とした記事でなくなる。
これらに十分注意し、記事を参照すること。

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

  • Y（上下）座標が拡大された。
  • バイオームの新設や整理が行われた。

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

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

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

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

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

鉱石分布の変更

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

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

雨・雷雨が頻繁になった

1.17.1 において 雨・雷雨がほとんど降らなかったが、1.18 では、割と頻繁に降るようになった。

落雷も 1.17.1 に比べると、かなり頻繁に発生するようになったので、木造の設備や植生などについては、火災対策が重要になると思う。

遠くのブロックが霞むようになった

1.18 からは描画距離の設定や考え方が変更されたようで、単にアップグレードすると、遠くの景色が霞むようになった。

おそらくこれは、ＰＣのスペックによって左右されるのだと思うが、非力な環境だと、この霞み具合がさらに広がった。

（1.18.1 にて改善されました。1.17.1 とほぼ同じ描画距離になったと思います）

オオカミの字幕が変？

普通に吠えて（元気で）も「オオカミが息切れする」と表示される。（字幕のバリエーションがトンでる？）

水流や溶岩など環境音の聞こえ方が変わった？

溶岩や水流などの環境音に指向性が追加された？
以前は 360° どの方向を向いていても、環境音は聞こえていたのだが、1.18 になってから後方の環境音が聞こえなくなった。

また以前は他のブロックの先にある音が、結構数ブロック以上離れた遠い距離からも聞こえていたものが、1.18 ではかなり近くのブロックに来ないと聞こえなくなった気がする。

また「聞こえない＝字幕にも表示されない」ため、調子にノってマイニングしていると、いきなり「溶岩ドバァ」とか溶岩遊泳とか落下の憂き目に遭ってしまう。

水流

プレイヤーの向いてる方角によって聞こえたり、聞こえなくなるような効果が追加された？

溶岩

地中にある（渓谷や洞窟などの空間がない）溶岩ブロックについて、音が聞こえなくなった？
併せて字幕も表示されなくなった？

マップについて

マイクラはプレイヤーの移動にあわせて、seed値に沿って動的にワールドが生成されていく。

厳密にはプレイヤーの移動にあわせて、プレイヤーの存在する位置周辺のチャンク（感覚的には遠景でみえる景色の数チャンク先）が生成される。

そして前バージョンで生成されたワールドについては、アプデ以降も基本的には変更されない。

逆に未踏破のエリアは、新バージョンの設定で生成されることになるため、いきなりバイオームが変化するような場所が生じることもある。

また 1.18 では地下も拡張されたため、1.17で生成された地下世界の下に、1.18 で追加された深層地下が広がっている。

【以下、引き続き気づいた点について、随時記事を追加・変更する予定。】

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 分ぐらいかかった。

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

バージョンによっては、上記アップグレードコマンドにて操作終了後、何もしていないのにメモリ不足などの例外エラーで終了したり、コマンドの入力挙動がモッサりして不安定になることがある。
自分の環境では、1.18.1 アップグレードの際に発生した。
ただ今のところアップグレード時のみ生じている問題で、OSごと再起動し Spigot を通常起動させた状態では安定。
少しゲームプレイしたかぎり、問題も起きていない。むしろ動作が軽くなった気がする。現状様子見。

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

> stop

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

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

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

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

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

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

さくらのVPC 512MB プラン

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

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

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

さくらのVPC １Ｇプラン（今ここ）

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

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

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

結論

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

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

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

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

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

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

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

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

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

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

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

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

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

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

現在のマイクラには、C++でコーディングされた「統合版」（Bedrock Edition, 通称 BE）と「Java版」（Java Edition, 通称 JE）の２種類がある。
歴史的には「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 は、前述の通り、このようなスタイルのゲームの開発言語としては向かない、ボトルネックになっている事がという事が立証されている。これは今後致命的になると思っている。

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