.nbt構造ファイルがブロック名ではなくパレットのインデックスを保存する仕組み — だからこんなに小さい
建造物全体を支えるのは3つのキー、size、palette、blocksだけ。各ブロックはパレットを指す整数にすぎないので、32³の石の塊は文字列1つと32,768個の小さなエントリ(位置とインデックスが1つずつ)で済み、名前は一度も登場しない。
.nbt構造ファイル — ストラクチャーブロックが保存し、データパックが同梱するもの — は、外から見た印象よりずっと単純な形式です。建造物に必要なものはすべて少数のトップレベルキーに収まっており、ファイルがこれほど小さくなる理由は1つの設計判断にあります。
建造物を支える3つのキー
size [x, y, z] — a list of exactly three integers
palette [ { Name, Properties } … ] — every DISTINCT block state, once
blocks [ { pos, state, nbt } … ] — one entry per placed blockpaletteは、それぞれ異なるブロック状態をちょうど1回だけ保持します。 エントリはName — minecraft:oak_stairsのようなブロックID — と、そのブロック状態を保持する任意のPropertiesコンパウンド(facing: northやhalf: bottomなど)で構成されます。
blocksは名前を決して繰り返しません。 各エントリは3つの整数からなるposとstateを持ち、stateはブロックIDではなくパレットへのインデックスです。北向きのオークの階段は文字列データとして1回だけ現れ、それ以降はすべて小さな整数になります。
これが仕組みのすべてです。32 × 32 × 32のただの石の塊は、パレットエントリ1つと、位置+インデックスからなる32,768個のブロックエントリになります — minecraft:stoneという単語のコピーが32,768個あるわけではありません。パレットは建てるものの種類が増えるほど大きくなり、ブロックリストは建てる大きさが増えるほど大きくなります。この2つはまったく異なる数であり、通常大きくなるのは片方だけです。
設計時に考慮すべき2つの帰結
ブロック状態はブロックリストではなくパレットを増やします。 オークの階段はパレットエントリ1つではありません — 実際に使用した向きごとに1つずつです。4方向、上半分と下半分、直線と内側・外側の角: 同じブロックが十数個のパレットスロットを占めることもあります。つまり、細部の多い建造物はパレットが大きくなり、そうでないものは大きくなりません。大きさに関係なく。
保存された位置にだけエントリが付きます。 ブロックリストはリストであり、密な3D配列ではありません。存在しないエントリは単に存在しません — このページのビューアはグリッドを-1で埋め、座標が欠けていれば何も配置されていないものとして扱います。ただしストラクチャーブロックは他のブロックと同様に空気も保存します。除外されるのはストラクチャーヴォイドだけです。中空の建造物の保存が安く済むのは、保存前に内部をストラクチャーヴォイドで埋めた場合だけです。
nbtはブロックごとで任意
blocksの各エントリは独自のnbtコンパウンドを持てますが、ほとんどのエントリは持ちません。ここにチェストの中身、看板のテキスト、スポナーのモブ、旗の模様が入ります — パレットではなく個々のブロックに付属するのです。
この区別は重要です: パレットデータは共有され、ブロックデータは共有されません。 2つのチェストは同じブロック状態なのでパレットエントリは1つですが、それぞれが独自のnbtに自分のインベントリを保持します。ブロック状態を変えればパレットに触れることになり、中身を変えればブロックリストの1エントリに触れることになります。
1レイヤーずつ読み取る
ここにあるビューアは意図的に2Dです。レイヤーyを描画するには、ブロックリストを走査し、pos[1]がyに等しいエントリを残し、それぞれのstateをパレットで参照します。これがアルゴリズムのすべてであり、知っておく価値があります。自分でこれらのファイルを調べるときも同じ手順だからです: 構築すべき空間インデックスはなく、gzipラッパー以外の展開もありません。この形式はフィルタリングする平坦なリストです。
つまり構造ファイルは、それがワールドのどこに属するかについては何も教えてくれません。sizeはバウンディングボックスであり、posの値はその角からの相対値です。配置はストラクチャーブロックの仕事であり、ファイルの仕事ではありません。