マインクラフト リソース等の構造について解説 (途中その①
閉じる
閉じる

新しい記事を投稿しました。シェアして読者に伝えましょう

×

マインクラフト リソース等の構造について解説 (途中その①

2019-10-12 22:25
    (この記事はまだ作成途中です。予告なしに追加、一部変更がされる可能性があります。)

    初めに 

     このブロマガ、シリーズでは末っ子的な解釈でのマインクラフトJEのリソース又はリソースパックの構造などについて解説していきます。

     マインクラフトでブロックを設置すると一口にいっても、何個かのプロセスを経て、その結果として目に見える形でブロック設置は行われます。
    自分でリソースパックを作成・開発を行う際、この何個かあるプロセスのうち、一つでも正しい記述・構成に整えられていないものが含まれていると、想定していた結果が得られません。

     各プロセスについて正しい知識・見解を持ち、上手くいかなかった場合の傾向と対策を知ることは、リソースパック開発の効率化においてとても重要であると僕は認識しています。

     内容はかなり多岐にわたりますし、僕自身なにか覚書に残してきたわけではないので、結構な範囲での情報の漏れがあると思います。
    さらに専門的な部分で、本来の用途、事実と異なる表現をしている可能性があります。

     このブロマガはあくまで末っ子的な解釈での解説する記事です。上記のことを了承した上で、あくまで参考程度にご自身のリソースパック開発にお役立ていただければ幸いです。




    ブロック設置等を構成する各プロセス解説

     この記事では、マインクラフトでワールドデータの特定の座標のブロックIDを何かしらの手段でもって別のブロックIDに変更することをブロック設置であると仮に定義しています。
    これには、特定の座標のブロックの ●ダメージ(メタ)値変更 ●エンティティの変更 ●NBTの変更 ●バイオームの変更 ●光源レベルの変更 などは含まれません。

     マインクラフトでは、1.リソースデータの読み込み、2.ブロック設置に際して下記のプロセスを経た上で、クラフターの目に見えるようになります。


    1.リソースデータ読み込み


    1-a.リソースデータの配置。
    1-b.圧縮したブロックデータをRAMに保存、すぐに使えるようにする。


    1-a.リソースデータの配置について

     リソースパックによる変更等なければ基本的には省略されますが、あった場合読み込んだリソースパックの優先順位などを基に、バニラであるリソースデータを含めテクスチャのデータ、モデルのデータ、ブロック設置の規則のデータ、音や言語等に関するデータ等を機械的に読み込むために都合のいいように再配置、圧縮を行います。


    1-b.圧縮したブロックデータをRAMに保存

     使用しているマインクラフトのバージョンのjarファイル内のcomフォルダーの内容に従い、
    ・ブロック設置の規則
    ・モデルデータ
    ・テクスチャデータ
    をRAM 所謂メモリーに一時的に保持します。


    2.ブロック設置


    ⓪ブロックデータをRAMに保持
    ①ブロック設置に関するイベント
    ②ブロック設置の規則の指定
    ③ブロックモデルを設置
    ④ブロックの設置状況に応じて周囲を含むブロックのテクスチャを変更する。


    ⓪ブロックデータをRAMに保存

     基本的に上記1-bと同じ。ただリソースデータとは別枠で、ブロック本体のイベントのデータ、ブロック設置に関するイベントのデータ等もブロック設置には関わることになるので、これらも同様にRAMに保持されます。


    ①ブロック設置に関するイベント
     マインクラフトのブロックは(1)条件や(2)クラフター等のとる行動などにより(3)多様な種類、異なる状態のがそれぞれ指定されます。
     (1)条件
    ・クラフターのゲームモード
    ・クラフターの位置座標
    ・クラフターの目線の角度
    ・クラフターの目線の先にあるブロックの種類や状態
    ・選択しているアイテムの種類
    等です。
     (2)クラフター等のとる行動
    ・上記(1)の条件を踏まえた上でブロック設置のボタン(デフォルトであればマウス右クリック)を押す。
    ・コマンドの入力によりブロックの設置をする。
    ・クラフタ―以外のmobAIの活動。
    ・時間経過・天候によるランダム要素を含む変化活動。
    ・人工的なものを含むマインクラフト特有のギミックによる変化活動。
    等です。
     (3)ブロックの種類・状態
    上記(1)の条件を踏まえた上で
    ・設置するブロックのID
    ・同じIDでの異なる状態
     (・ブロックの向き
     (・周囲のブロックの向き、状態に合わせた種類や複数適用されるモデル
    ・自然な落下

     マインクラフトで内部的に行われるイベントは、僕の認知している現状リソースパックによってユーザーサイドから介入、変更をすることは一部を除きできません。
     ブロック設置に関するイベントに変更、追加を行うには、新規・既存のMODの開発・導入、などを行う必要があります。

    イベントに関してリソースパックでできないこと

    ・ブロックのあたり判定の変更
    ・ブロックIDの追加
    ・ブロック設置の条件の追加・変更

    イベントに関してリソースパックでできること

    ・再生する音源ファイルの追加・変更


    ②ブロック設置の規則の指定

     上記ブロック設置に関するイベントを通して、適用するブロック設置の規則【blockstates】を指定します。
    blockstatesはリソース内のassets/minecraft/blockstates内に各ブロックごとに配置されています。
    blockstatesのファイル名は基本的にデフォルトのもの以外に変更することはできません。

     バニラではない、forge MODによりブロックが追加されている場合、assets/minecraft以外の別のフォルダーに配置されます。

    例①ConquestReforged-3.0.2-mc1.12.2の場合
    assets/conquest/blockstates内

    例②cocricotMOD for 1.12.2の場合
    assets/cocricotmod/blockstates内


    ブロック設置の規則には、2019/10 packformat:4の現在、variantsmultipartの二つの形式があります。

    variantsは一つの座標につき、設置条件などによって異なる単一のモデルを適用するもの。
    multipartは一つの座標につき、設置条件などによって異なる複数のモデルを適用するもの。

     例えばアカシアの木材のフェンスの場合、フェンスの設置されている場所から北と東にブロックが接続されているモデルがあるとします。



     これをvariantsで分解して考えると、北と東にブロックを接続された状態のモデル(acacia_fence_ne)単一を適用しているとなります。



     また、multipartで分解して考えると、
    ①中央に柱のモデル(acacia_fence_post)
    ②北に向けてフェンスの側面接続時のモデル(acacia_fence_side)
    ③東に向けてフェンスの側面接続時のモデルをY軸を基準に90度回転させたもの

    の以上三つのモデルを1つの座標に同時に複数適用している ということになります。



    アカシアのフェンスでの、それぞれの形式の特徴ですが、

     variantsでは一つのブロックの変異体を全て表現するにあたり、最低で6種類(無接続、N接続、NE接続、NS接続、NES接続、NEWS接続)のモデルが必要になります。
     multipartでは1つのブロックの変異体を全て表現にするにあたり、最低で2種類(柱、側面接続)のモデルが必要になります。

     リソースパックを作成しているバージョンで、デフォルトでmultipartが適用されているblockstatesをリソースパックでvariantsのblockstatesに変更することはできます。(逆はできるか忘れた。

    また、multipartの記述ができるのはpackformat:2以降のリソースパックがつかえるバージョンでだけで、packformat:1以前のバージョン JEでいう1.9よりも前の1.8.xのバージョンではvariantsでの記述しか行えません。











    広告
    コメントを書く
    コメントをするには、
    ログインして下さい。