マイクラのJAVA版では全く馴染みのない物がタイトルに出ていますが、BE版ではこうした機能があります。
多分、多くの人が
【 コンソール版とベッドロック版にはスポーンチャンクが存在しない 】
と言う認識だと思いますが、通常のサバイバルモードだとそんな感じですが、チートをオンにしてコマンドを使うとこの領域の指定ができます。
■ スポーンチャンクとエンティティー
スポーンチャンクというのは初期スポーン地点の周囲に発生する時間凍結の対象外の範囲になるのですが、このチャンクはJAVA版にしか無いようです。そして、興味深いのは、17X17チャンクの範囲が指定されるようですが、その場合、チャンクを開いた時に、そのチャンクの中心からどちらにずれているかで17X17ではなくなるようです
17X17の条件とはチャンク表示をした時に、チャンクのど真ん中でスポーンした場合だとその状態になりますが、南北にずれると、そのずれた場所は16チャンクになり、ズレのない場所は17チャンクになるようです。これが東西でも同様な状態になるので、短い側のチャンク数が16になるようです。
あと、レッドストーン回路の距離も延長する手段はありますが、これも距離が決まっていますし、エンティティーについては、16X16と言う認識は間違いのようで、15X15の範囲で活動するものとそうでないものがあるようです。
スポーンチャンクとは、
【 メモリから解放されないので、たとえプレイヤーが付近に
居ない場合でも、それらの装置が止まることが無くなる
特別な場所 】
にあんるので、レッドストーン回路やアイアンゴーレムトラップを置くと自動処理が延々と行われるという利点があります。ただし、1.13だと回路がある場所はとんでもなく重たくなるので、1.12系だと大丈夫だった状態が担保されるわけではないみたいです。
とりあえず、スポーンチャンクはオーバーワールドでしか生成できないので、ネザーやエンドではこうしたチャンクは生成されません。というか、こう書くとまるで作れるような話に見えますが、チート機能おおんにしてコマンドを使える状態にすると、JAVA版でも
/setworldspawn
のコマンドでスポーンチャンクを移動させる事ができますから、チートを使わない場合だと初期スポーン地点がスポーンチャンクになります。
記述としては、移動場所を指定する場合には、上記のコマンドを入力して引数無しで実行すると変更され、座標指定をした場合、その場所がスポーンチャンクになります。
どうも1.13はメモリーの消費が増えているようなので、メモリー実装量の多い環境だとJVMの引数を調整してメモリーの割当を増やしたほうがいいようです。なので、1GBでもメモリーが余る状態が1.12系でしたが、3ＧＢくらい割り当てても7割以上は消費されるので、マイクラのデフォルト指定の1GBでは全く足りていません。その為、1.13だと低スペックでもマイクラが動く事は動くと思いますが、作り込んだワールドでレッドストーン回路が多い場合だと厳しい状態になりそうです。
とりあえず、スポーンチャンクについては、プレイヤーから 128ブロック の範囲を含むチャンクでしか生じないブロックのランダムな変化や、 プレイヤーから各軸方向に 7チャンク以下の範囲でしか生じない Mob のスポーンなどは発生しないのでソレ以外の該当する事象のみ発生する感じです。
あと、アイアンゴーレムトラップを作ったもののスポーンチャンクからはみ出ているなどの状態になっている場合、チャンクローダーで延長すると状況が改善することがあるので、基本はその範囲内だと大丈夫なんですが、そうでない場合にはそうした回路での延長の必要が出てきます。
■ ティック領域
これは、BE版に実装されている機能で、スポーンチャンクみたいな領域を登録して任意の場所に生成することが出来る機能になります。
と言っても、JAVA版でスポーンチャンクの座標移動をするのと同じレベルのことに成るので、チートをオンにする必要があります。こうした内容については先日 【 ■ マイクラの体験版 】 で触れましたが、コマンドブロックの利用などと同じような状態で実行できるものになります。
BE版は高品質オプション（と言っても3Dテクスチャーパック＋MODでの高品質モードが利用できるわけではないのでそうした画質面での変化はないですが視界のチャンク数はとんでもなく大きく出来ます。）がありますが、重たい演算をする場合には結構無茶が効くようで、このスポーンチャンクのような領域の【 ティック領域 】も結構凄い指定が可能です。
前述のようにスポーンチャンクは移動はできるものの、減速として初期スポーン地点のチャンクのどの場所に発生するかで東西南北に8ブロックの範囲になるか、東西7X南北8か東西8X南北7の範囲になるかが決まるのですが、ティック領域はプレイヤーが登録しない限り存在しません。つまり、座標指定を行って任意の場所にスポーンチャンクを生成っ出来るという物凄い仕様になっています。と言ってもチートなので通常のプレイや体験版ではその恩恵は受けるKとが出来ません。
まず、スポーンチャンクもプレイヤーが遠くにいる場合には、
■ 作物の成長
■ 葉の消滅
■ 草と禁止の伝播
■ 氷の生成と融解
■ プレイヤーから128ブロック以上離れた場所での
敵対的Mobのスポーン
■ プレイヤーから240ブロック以上離れた場所での
有効対的Mobのスポーン
■ 爆発による付近のチャンクのブロックの破壊
は起きないのですが、ティック領域ではスポーンチャンクで発生する事象に加えこうした例外も包含されます。つまり、128ブロック以上離れていても敵対的Mobは湧いてしまうので、BE版の場合村から離れると安全というわけでもないようです。あと、村人のスポーン条件も物凄いことになっているのでこれも様子が異なります。あと、ネットでJAVA版のトラップ系の動画を見た場合に物凄い湧き方をシていますが、BE版では7体くらいしか沸かないので湧き効率は物凄く悪いです。
とりあえず、ティック領域はスポーンチャンクの強化版のような状態なんですが、コレに加えて、
■ プレイヤーは最大10個までティック領域の生成
（登録）が可能
■ プレイヤーはティック領域の登録と解除が可能
■ ティック領域のサイズは1～100チャンクの範囲
でプレイヤーが指定できる
■ ティック領域はすべての領域で生成可能
となっています。
この生成には tickingareaコマンドを使い、登録の場合には、
【 ワールド内の2つの座標を指定し範囲指定で四角形
のチャンクを作る 】
/tickingarea add <from: x,y,z> <to: x,y,x>
で指定を行う方法と、1-4チャンクの円の指定する場合だと、
/tickingarea add circle<center: x,y,z> <radius: int>
と言う指定を行います。また、前述のコマンドですが、
/tickingarea add <from: x,y,z> <to: x,y,x> [ 名前]
とするとティック領域の名前の指定もできるようです。ちなみに、ティック領域のリストを見る場合には、
/tickingarea list
でリストの表示が可能で、
/tickingarea remove <座標: x,y,z>
/tickingarea remove <名前>
で削除できるようです。
■ とりあえず...
スポーンチャンクは元から発生するので、その場所以外に拠点を設ける場合（JAVA版で常時演算が発生しないようにするための措置）だと、序盤にスポーンチャンクを軽くしておく必要があります。というのも、対象の条件が機能する場合にはソレが影響してしまうからです。
その為、演算を軽くして常時運用する必要がないような構造物はスポーンチャンク外に設置して、放置しておいても効果が得られるようなものだとそこに作るという選択肢があります。
その為、スポーンチャンクは常に演算が行われるのでそうした利点はありますが、その分そこにレッドストーン回路を密集させるとその場所でも重くなりますし、別の場所にトラップタワーを作ってもソレを運用すると、スポーンチャンク＋トラップタワー分の演算が発生するので、重くなります。その為、スポーンチャンクをどう運用するのか？もマイクラでは考える必要が出てきます。と言っても、それほど回路まみれにしていない場合には影響がないのですが、別の場所の拠点を発展させた場合に、スポーンチャンクの負荷も包含された状態で影響を受けるという点では代わりありません。
JAVA版だとスポーンチャンクは自動生成なので、チート無しでコマンドの利用をシない場合その移動に存在しますから、この運用方法を最初に考えたほうがいいのですが、今回紹介したようにチートをオンにしてコマンドを使うとその移動も可能になっています。
BE版では、ティック領域と言う物を指定できるのですが、JAVA版が元からスポーンチャンクが自動生成されるのに対し、BE版のティック領域はプレイヤーがチートをオンにしてコマンドで配置するものになっています。その為、スポーンチャンクというのはBE版では存在しません。
また、仕様を見ると最大で100チャンクサイズのスポーンチャンクが10個作れるようなものになっていますから、巨大な回路を自動処理で動かすというのも可能です。
ただし、JAVA版ではデスポーンしているはずのMobがスポーンしていたり、スポーンチャンクでは停止する処理がそのあま反映されるなどの状態が発生します。その為、上限については物凄く魅力的なものになっていますが、その分負荷が物凄く増えてしまうので最大の状態で運用すると相当高い負荷がかかることになります。
その為、【 フレキシブルなサイズ指定で任意の場所に複数のスポーンチャンクよりもエンティティーの挙動が多い時間凍結の対象外のエリアを作れる 】と言う利点はありますが、MOBやエンティティーの演算も入る上に、JAVA版のようにJVMの引数の指定でマイクラ自体やMOBのクラスに対してのメモリー割当てやサーバだとサーバ用のメモリー割当てなども含めたパフォーマンスの指定などが存在しませんから、マイクラの仕様に合わせたパフォーマンスの範囲内で動かすことになります。そうなると、必然的にマシンスペックを上げておかないとそうしたチャンクの演算はできなくなるのとメモリーが少ないと重くなるので低スペックなマシンでソレを追加しレッドストーン回路の自動運用（というか、理屈からすると、ジ・アイアンタイタンを10個作ってソレが常時運用するような状態もソフトがソレをおこなる状態であり、演算能力が足りていれば可能になると言う話ですから、ティック領域というのは物凄い仕様です。）を考えた場合、当然のように無理が来ます。その為、追加はできますがw－ルド内で移動した範囲が広くなると多くなる（というか、これはBEと言うよりもPEで経験されている方も多いのではないかなと思います。）のもありますから、ハイスペックなマシンでないと厳しいかもしれません。とりあえず、スペックが厳しい場合、720p表示で対応するなどの選択肢もありますが、体験版で動かした時の挙動は見込めなくなります。そうなると、先日紹介した128チャンクとか256チャンク以上の表示とティック領域の併用というのは、低スペックでは間違いなくムリですし、スペックが高くても読み込み時間がかかります。あと、演算は表示したワールドの分だけ行うことになりますから、表示されていない場所は演算対象外（と言うよりもマップ自体がないのでMobのスポーンもエンティティーの演算も発生しない）になりおますが、前述の条件を見ると、ワールド内のマップの枚数が増えていくほど重くなる可能性がある仕様とも言えます。そうなると、バイオーム探しでマップの枚数が増えてくるとその分負荷が増えてしまうので、それに加えてレッドストーン回路の演算が常に上乗せになると、ハイスペックなマシンで演算させないと厳しくなるというわけです。
仕様から考えると100x100チャンクのスポーンチャンクのようなのを10個も作れるわけですから、速いマシンであるほどプレイヤーが別の作業を行っている時に自動処理を行ってくれる回路を同時起動出来るようになりますが、通常のBE版のような軽さはなくなるので、その点は注意が必要です。
■ Appendix
ゲームを遊ぶ場合にGPUの選択が変わってきますが、速度を持っ止める場合には、2GPU以上でSLIやCross Fireを使って速度を出す方法があります。この仕様ですが、ゲームだと何でも効果があるように思われるかもしれませんが、グラフィックライブラリによって出来ることが違ってきます。ゲームのAPIというと、Direct XやMantleなどがありますが、ゲームの場合、モバイル製品でも見かけるOpen-GLというものがあります。DirectXはゲームと言うよりもWINDOWSのマルチメディア制御用のAPIなのでゲームや3D単体ではなくそうした物がまとまったパッケージ（なので、3Dを制御するDirect 3Dや平面を処理するDirect 2Dなどがあります。）なので少し違うのですが、Open-GLもゲームAPIではなく、任意の開発言語で3DCGを用いた処理を行う場合に無償で利用できるオープンソースな3DCGライブラリですから、ゲーム用のAPIというわけではなく3Dの処理をするためのグラフィックライブラリになります。
仕様が異なるというのはありますが、GPUにおいても使用が少し事なり、3DCGツールを用いた処理をする場合ですが、この場合、Open-GLの場合だと単体で高速なGPUを実装しないと速度が出ないので、基本的にSLIやCross Fireなどの複数のGPUを用いた高速化が出来ません。その為、2つのGPUを個別で使うような利用方法になります。その為、SLIやCoross Fireを使う場合だと、Direct X12やMantleなどのゲームAPIに限定されます。マイクラはOpen-GLを採用したゲームですから、GPU性能を求めると、単体で高速なもののほうが効果があるのですが、これはOpen-GLの仕様がそうなっているからというのもあります。
その為、使っているAPIが何であるか？で内容が変わってきますが、SLIやCorss Fireを使って高解像度＋高品質でゲームを動かした場合にパフォーマンスがシングルGPUよりも上がるものもありますが、そうでないものもあるので注意が必要です。あと、処理においてGPU依存度が高い処理なのか、CPU依存度が高い処理なのか？で内容が変わってくるのですが、マイクラのようにデバッグモードを走らせてみると、結構な量のメモリー消費量になっていることがあります。JAVA版の1.12だと1GB未満で動く状態もあるので、JVMの引数を調整せずにJAVAのみを64bitにして運用すれば大丈夫な状態もありましたが、1.13は数倍のメモリーの消費量になっているので、流石に同じような状態になっていません。つまり、メモリーはどの程度消費しているのか？も重要ですし、そのソフトを使った場合にタスクスケージューラーを起動すると、CPUの負荷はどうなっているのか？も注視したいところです。
つまり、GPUの負荷が高い状態があまり続かずCPUの負荷が高い場合、その環境ではGPUのパフォーマンスには申し分がなく、プロセッサ依存度が高い処理は環境的に無理が来ているので、そうした条件で考えるとプロセッサのグレードアップをシたほうが快適になると言えます。また、メモリーの割当もタスクスケジューラーでどの程度消費しているのか？を見た場合に無理が来ているようだと同仕様もありませんから、メモリー実装量が少ない場合にはゲームだけで無理が来ている場合には、外付けのハードウェアエンコーダタイプの製品を使わないと録画で失敗する可能性もありますしLIVE配信のように負荷が増える場合には、リソース不足になる恐れもあります。
その為、ゲーム単体で無理が来ている場合にはゲームDVRでの録画とかOBSやX-Spritやffmpegを使った配信などは難しいと言えます。
とりあえず、マイクラはOpen-GLをグラフィックライブラリで使っているので、SLIやCrossFireの構成ではパフォーマンスが上がらないので、その構成でパフォーマンスが上がるソフトとは少し異なる仕様になっています。
マイクラの場合、CPU、メモリー、GPUのバランスが取れていないとダメで、そのいずれかがダメだと足を引っ張ることになります。
【 CPU 】
Intel Core 2、AMD Aシリーズ以前の場合、デュアルコアで
2.5GHz以上あればまだしも、それ未満やノートPCではまと
もに動かないので、下限はその辺りになります。ただし、そ
の状態だとレッドストーン回路を山程作ると負荷が高すぎて
ゲームになりませんからGPUの性能がGTX 1060以上を想
定すると、
Haswell以降のCore i3
Sandy Bridge以降のCore i5
Ryzen 5 1400
以上でなければCPUが足を引っ張ることになります。
古いプロセッサだとHyperThredingを切らないとパフォー
マンスが上がらないというのがありましたが、Brodwell以降
のCore i7・i3(およびCore i9)ではHT有効時のシングルスレ
ッド性能の低下が軽微であるため、オフにする必要は薄れ
ています。
また、AMDのRyzen 7・5やRyzen ThreadripperもHTと同じ
機能(SMT)が搭載されているが、こちらも無効にする必要も
ありません。
とりあえず、マイクラの場合、Optifineを使うと4コア動作に
なるのですが、1.7などはシングルコア動作だったので古い
バージョンだと色々と無理が来ます。また、メニーコアでク
ロックが高めなもののほうが優位性があるのは多くの条件
で一致していますが、ゲームが4コア動作でもライブ配信を
する場合にはそのソフトの処理にコアを使いますし、動画を
ソフトウェアエンコーダで記録する場合も、コレとは別にスレ
ッドを消費します。そうした理由を考えると、メニーコアのプ
ロセッサでスレッドが足りなくなる状態（と言うよりもCPUの
負荷率が100%になり処理が重くなる状態）を回避したほうが
いいので、ゲームだけではなくそうした用途だとスレッド数が
少ない製品は選択肢に入りません。
【 GPU 】
GeForce GTX 1050
Radeon RX 560
Core i 8000番台のIGP
Ryzen 2000番台Gシリーズ内蔵グラフィック
辺りでも動きますが、2012年までのPCのチップセット内蔵G
PUでは描画能力不足（これはCPU性能も含めて低いので
システムの処理能力の問題）で、描画距離8chunk以下でさ
えまともにプレイできません。
あと、QuadroやFire ProのほうがOpen-GLが優れていると
言うのは確かなんですが、マイクラだと使い方によっては
GeforceやRADEONのほうが向いている場合があります。
ゲームを遊ぶ場合、バニラとMODを用いた二種類の遊び
方がありますが、前者だとOpen-GLが効きますが、後者だ
とコンシューマのボードのほうが効いてきます。その為、ど
の辺りの処理が最適なのか？を考えてGPUを選択するこ
とになりますが、影MODの処理だとGeforceやRADEONの
ほうがパフォーマンスが高くなるようです。
コストと作業によってパーツの選択が変わりますが、GPU
性能は高くしたほうがいいようです。
【 メモリー 】
マイクラ自体は4GBあれば動くと言われていますが、この
数値がバックグラウンドで動いているソフトまで含めての
話ではないので前述のようにライブ配信や録画をすると
ムリが来ます。ブラウザやSkypeを同時に開いてLIVE配
信とかを行うと結構凄まじいメモリー消費量になるので、
結果として、16GB以上を用意しておく必要があります。
また、表示チャンク数やMODの実装量によって負荷が変
わってきますからメモリーは多く実装したほうがいいと言
えます。FireFoxやChromeを開いて長時間利用していると
結構なメモリー消費量に成るので、それとSkypeとMOD入
りのマイクラを行うととんでもないメモリー消費量になりま
すから、結果的にマイクラのみをオフラインで遊ぶとかサ
ーバでブラウザなどを開かずに遊ぶ状態とライブ配信で
は異なりますし、PC内部でマイクラの録画を行って動画
でアップする場合の条件と単体での動作では全く違いま
す。その為、メモリー実装量が少なくても動くというのは
時代錯誤と誇大妄想の類ですから、そうした間違いを吹
聴している輩を見ても無知な未経験者の猛言なので相手
にしないほうが良いです。とりあえず、この部分は容量が
不足するとHDDやSSDなどのストレージにアクセスが開
始されるので露骨に重くなりますから容量の確保はして
おいたほうが賢明です。
のような条件がありますが、BE版だとパフォーマンスを上げる選択肢は画質を下げるしかないのですが、JAVA番だと、JVMの引数の変更でメモリーの割当ての量を増やすと条件が変わります。
ちなみに、4GB以上のメモリーというのは、64bit版での話になるので、JAVAも64bit版をインストールすることになります。そのうえで割当の量を変更するとデフォルトの状態（JAVAが32bitなのでWOW64でムダにリソースを消費しており、メモリー割当が1GBなので末期な状態で動いている状態）よりも改善します。あと、バニラだとOptifineを入れると4スレッド動作になるので軽くなるのですが、これとJVMの引数の項目の変更（これは記述を間違うとマイクラが動かなくなるので注意。）をするとパフォーマンスが改善します。
その為、マシンを構成しているパーツ構成に注意が必要になりますが、JAVA版だとJVMの引数で調整をすることでパフォーマンスの改善が可能になります。この時に割当の容量を大きく出来るのですが、その他のソフトを同時期どうしても大容量のメモリーを割り当てるkとオが可能な条件で考えると、メモリー実装量の多さは重要だと言えます。
低スペックなマシンでもマイクラは動くのですが、とりあえず、当たり前のプレイとかMODでの動作を想定するとある程度のスペックのマシンにしておいたほうが出来ることは多くなります。
あと、
【 ゲームの動作に必要なスペックというのはゲームだけ
動かした場合のお話 】
なので、同時に
■ CromeやFirefoxを長時間利用する
■ Skypeの利用
■ 配信ソフトの利用
を行った場合、当然のように負荷が上昇します。通常はメモリーの消費量は処理の合算で考えるので、8GBの環境でゲームが動くと仮定しても、前述のようなカメラの映像だけ流すような配信を2時間くらい行ってもメモリー消費が結構凄い事になりそうな何かだと8GBでゲームまで動く条件になるとは考えにくいわけです。つまり、
【 ゲームの負荷を間引いた状態で動かしてみて、その状
態でどの程度の負荷がかかるのかを見て、その後、ゲ
ーム単体を動かしてどの程度の負荷になるのかを確認
し、その負荷の合算をしたものがその処理に掛かる負
荷になる 】
わけです。その為、
■ ゲーム実況動画を作るためにデスクトップ録画をする
■ ゲーム実況のライブ配信をするために配信ソフトと
Skypeとブラウザを同時起動させ別のソフトも動い
ている状態
だと 【 既に字面を見るだけでもゲーム単体の負荷であるわけがないのは誰が見ても分かる話 】 ですから、その分だけスペックを上げましょうということになります。コレはマイクラだけではなく、別のゲームで同じことをする場合でも負荷の考え方は同じですし、作業時に、Blenderでモデリングを行い、UV展開後にテクスチャーペイントである程度描いて、スペキュラーやでフューズの書き込みをGIMPで行う時にソフトの同時起動をすればその分メモリー消費量とCPUの負荷などがj報奨するのと内容的には全く同じです。
とりあえず、低スペックだとJAVA版の場合にはスポーンチャンクと自分の周辺の演算が入るので、処理が嵩み始めると厳しくなりますし、アイアンゴーレムトラップをスポーチャンクに作り、湧き効率のいい天空トラップタワーを作るだけでも結構不可が上昇するので厳しくなります。
あと、視界のチャンク数を増やすと凄まじく重くなるのでその辺りも気をつけたいところです。実況動画やライブ配信をされている方のマシンスペックを見ると【 4Kｎ高画質モードでファイナルファンタジーを遊ぶような構成 】のようなのを時々見かけますが、少なくともFHDの最高画質で60fpsが出るようなスペックの人が結構多いのも特徴です。
つまり、マイクラ遊ぶ環境というよりも、動画編集やライブ配信用の機材として考えた場合の最低限のスペックだとそんな感じで、UnityやUnreal Engineを使って、1080pのゲームを作っるとしても結構良さげに動きそうな何かになっています。つまり、コレよりも少し低めの環境でもライブ配信だとラグい状態だったり、【 落ちる 】なんてことがあるのですから、行う作業でマシンスペックが異なるというのも自然な内容だと言えます。この配信とかを行う場合だと、負荷が増えて当たり前なので、ゲームだけを立ち上げてローカルで遊ぶだけの負荷よりも高付加になるのは当然な内容と言えます。その為、BGAのローエンドの構成だと本来の遊び方ができない（というか、建築でワールドを作り込んだり、レッドストーン回路が増えるだけで無理が来る）と言う問題があります。
その為、【 JAVA版のマイクラをするだけでもある程度スペックを上げておいてOptifineを入れておいたほうがいい 】のですが、そこに配信とかが入る場合には、【 軽いゲームでもスペックをある程度上げておかないと無理が来る 】ので注意が必要です。その為、マイクラの処理においても長期に渡りワールドを作って配信されてる方の
【 間違いなく重たいワールド 】
だとマシンスペックが低いと配信もゲーム録画も行わない状態で無理が来ますし、その条件を満たすだけでもそれ相応のスペックにしておく必要があります。実際にゲーム実況動画やライブ配信というのは、それプラスαなのでハイスペックなマシンの選択が必要になるというわけです。このことを踏まえると、ティック領域の仕様の上限まで拡張した場合だと、JAVA版よりも確実に重くなるので、低スペックでも大丈夫と言う条件は消えるわけです。ただし、JAVA版のようなメモリー割当などのカスタマイズは出来ないのでスペックを上げておくことで対応するしかなさそうです。