ルート選定
トラック1: JSON content mod
向いているケース:
- 既存 Blueprint の値変更が目的
- content-only で済ませたい
- 新しいモデルや UI は不要
主な流れ:
Emptyから始める- 必要な key だけ patch する
- 元の Blueprint path を保つ
- ゲーム再起動後に確認する
トラック2: JSON 調整パック
向いているケース:
- 複数の Blueprint patch をまとめたい
- data-driven のまま進めたい
- 一括生成や整理が必要
主な流れ:
Emptyから始める- 対象 Blueprint path を先にそろえる
- patch をまとめて生成または整理する
- 出力 path を全部確認する
トラック3: 新規建物アセット
向いているケース:
- 新しい配置物を追加したい
.timbermesh、アイコン、localization、TemplateCollectionが必要
新規建物アセットフロー
ファイルを触り始める前に、ルートA と ルートB の分岐を一枚で確認したいときはこの図を見てください。
元ファイル:
- SVG を開く
- draw.io ソース
- 正本の図エクスポートは
assets/に置き、docs サイト用のdocs/public/にはnode scripts/sync_docs_diagram_assets.mjsで同期します。
ルートA: Timberborn built-in material を使う
向いているケース:
- Timberborn 風の見た目で十分
- custom texture がなくても成立する
- Unity を極力使いたくない
主な流れ:
Example buildingを土台にする- Blender CLI で
.timbermeshを出す - 建物 Blueprint を配線する
TemplateCollectionに登録する- ゲーム内で配置確認する
ルートB: custom texture を AssetBundle で持ち込む
向いているケース:
- 元
GLBが texture-baked 型 - 元の見た目を保ちたい
- ルートAでノイズや破綻が出た
主な流れ:
- Blender CLI で
.timbermeshと texture を出す - Unity で
Materialを作る AssetBundles/Resources/...に置くMaterialCollectionを追加する- Unity CLI で bundle を build する
- Timberborn を完全再起動して再確認する
トラック4: C# DLL / UI MOD
向いているケース:
- ゲーム内設定パネルが必要
- UI から JSON を生成したい
- code-driven の挙動が必要
主な流れ:
- project と references を確認する
- starter、service、UI layer を追加する
- 次回起動用 JSON を書くのか、live に挙動変更するのかを決める
- DLL の build と読み込み path を確認する
トラック5: BepInEx / Harmony runtime patch
向いているケース:
- Blueprint や通常の mod API では届かない
- hidden な runtime logic を触る必要がある
主な流れ:
- Blueprint と通常 code mod で足りないことを確認する
- 対象 type や method を慎重に調べる
- 最小限の patch だけを入れる
- 検証負荷が高いことを明記する
重要ガードレール
- JSON 系は
Empty、新規建物はExample buildingから始める .timbermeshだけで元 texture がそのまま出ると思わない.matと.pngの basename を分けるMaterialCollectionは lower-case の正規化 key を優先する- Blueprint に値が見えないなら C# や BepInEx へ進む前提で考える
- material 側、JSON 側、DLL 側を更新したらゲーム再起動で確認する