Team Workflow
レベルオーナー制・.nbt 命名規則・マーカー契約・レビューゲイト。並行開発を壊さないためのチーム運用ルール。
複数人が同時に部屋を作ると、命名衝突・マーカー欠落・意図の不整合 が頻発する。本章では Echelon のレベルデザインを並行開発するための運用ルールを定義する。
5.1 レベルオーナー制
各部屋・区域・ボスアリーナには 単一のオーナー を置く。
オーナーの責務
編集権
- オーナーのみ が自分の
.nbtを直接編集する - 他の人は Pull Request 経由で変更を提案する
- オーナーは PR をレビューし、Intent から逸脱しないか確認する
EDG room-graph JSON の特別扱い
EDG の room-graph JSON (Mode A の rooms[] / connections[]) を編集できるのは Phase 2 オーナーのみ。これは部屋の繋がり (= Macro 動線) を変えると全体に影響するため。
5.2 .nbt テンプレートの命名規則(提案)
一貫した命名規則で、ファイル名だけで内容を推測できるようにする。
第1層の命名パターン
| パターン | 用途 | 例 |
|---|---|---|
floor1_corridor_<NN>.nbt | 廊下 | floor1_corridor_01.nbt |
floor1_combat_<NN>.nbt | 雑魚戦闘部屋 | floor1_combat_03.nbt |
floor1_miniboss_<name>.nbt | ミニボス部屋 | floor1_miniboss_kingslime.nbt |
floor1_boss_<name>.nbt | 層ボス部屋 | floor1_boss_twin_knights.nbt |
floor1_checkpoint_<id>.nbt | チェックポイント | floor1_checkpoint_mid.nbt |
floor1_negative_space_<id>.nbt | Negative Space 部屋 | floor1_negative_space_pre_boss.nbt |
一般則
<層>_<タイプ>_<識別子>.nbt- 層:
floor1/floor2/floor3 - タイプ:
corridor/combat/miniboss/boss/checkpoint/negative_space - 識別子: 連番 (
NN) または名前 (<name>)
未確定要素の扱い
phase2 §2D のミニボス2 など、未確定の要素には <TBD> を使う:
- 例:
floor1_miniboss_<TBD>.nbt(placeholder、確定後にリネーム)
5.3 マーカー契約(vanilla Structure Block DATA mode)
Echelon は vanilla の Structure Block DATA mode をマーカーとして使う。これにより、追加modなしで .nbt 内にメタデータを埋め込める。
マーカー一覧
| マーカー | 役割 | 全部屋 | ボス部屋のみ |
|---|---|---|---|
edg:connector:<id>:<N|E|S|W> | 部屋の接続点 | ✅ | ✅ |
edg:mob:<id> | 雑魚 mob スポーン | ✅ | (使わない) |
edg:boss_spawn:<id> | ボススポーン | ❌ | ✅ |
edg:arena_center | 幾何学的中心 | ❌ | ✅ (1個のみ) |
edg:party_entry:<id> | プレイヤー入場 | ❌ | ✅ |
edg:ref:<N|NE|E|SE|S|SW|W|NW> | 8方位基準点 | ❌ | ✅ (第1層) |
checkpoint:<id> | チェックポイント | (CP部屋のみ) | ❌ |
マーカー命名の制約
- 全て
edg:プレフィックスで始める (EDG 専用) <id>は部屋内で一意<N|E|S|W>は大文字・小文字区別ありarena_centerは 修飾子なし (部屋内で1個だけのため)
配置のベストプラクティス
- connector マーカーは壁の 外側 に置く (部屋同士が繋がる位置)
- mob マーカーは 床から1ブロック上 (spawn位置)
- arena_center は 幾何学的中心の床 (x.5, y, z.5 ではなく整数座標)
5.4 レビューゲイト
Echelon のワークフロー (AGENTS.md) に従い、レベルデザインにもレビューゲイトを適用する。
ゲイトの流れ
1. Planner が Intent 文書を起票 (Step 0 + Step 1 案)
↓
2. Root Codex が確認 → Advisor へ送る
↓
3. Advisor (GPT-5.6 Sol) が PLAN_APPROVED / PLAN_REVISE を返す
↓
PLAN_REVISE の場合 → 1 へ戻る (最大5ラウンド)
↓
4. Executor が .nbt を作成 (Step 4–6)
↓
5. Root Codex がゲーム内で最終検証 (Step 6 プレイテスト)
↓
6. 文書化 (Step 7) → 統合
レビュー対象
| フェーズ | レビュー対象 | 判定基準 |
|---|---|---|
| Intent レビュー | Step 0 + 1 の文書 | Lynch 5要素・Circulation 型の妥当性 |
| Micro レビュー | .nbt + マーカー配置 | マーカー契約・視線・比率 |
| Playtest レビュー | Step 6 の結果 | チェックリスト全項目 ✅ |
AGENTS.md の原則
- Root Codex が最終権威。子エージェントの結果は最終検証にならない
- 並行は独立スライスのみ。書き込み所有権が重なる仕事は並行しない
- 小さく低リスクな作業 はフルゲイトを省略できる (Root Codex が最終検証は必ず実施)
5.5 並行開発の所有権マトリクス
第1層「草原」の部屋を複数人で分担する場合の例:
| 部屋タイプ | オーナー | 備考 |
|---|---|---|
廊下 (floor1_corridor_*) | Designer A | 量産可能 |
雑魚戦闘部屋 (floor1_combat_*) | Designer B | 量産可能 |
ミニボス部屋 (floor1_miniboss_kingslime) | Designer C | 単体オーナー |
層ボス部屋 (floor1_boss_twin_knights) | Lead Designer | 最重要・単体オーナー |
| EDG room-graph JSON | Phase 2 オーナー | Macro 動線の変更権 |
所有権の重なりを避ける
- 同じ
.nbtを2人が同時に編集しない - 同じマーカー
<id>を2人が別部屋で使わない (UUID 衝突) - 同じ sidecar JSON を2人が編集しない
5.6 文書化テンプレート
Step 7 で使用する標準テンプレート:
# Room: <部屋名 / .nbt ファイル名>
## Intent
<Step 0 の一行。この部屋で何を学ばせる/感じさせるか>
## Macro
- Circulation 型: <Grid / Linear / Circle-Based / Organic / Radial / Spiral>
- 前の部屋: <.nbt または「入口」>
- 次の部屋: <.nbt または「ボス撃破で次層」>
- phase2 §2F-1 の進行位置: <雑魚x5 / G1 / ...>
## Landmarks
- この部屋から見える Landmark: <塔 / ボスシルエット / なし>
- Node の種類: <ゲート前 / 分岐 / 戦闘 / なし>
## Repetition / Alteration
- 教育順序の位置 (phase2 §2C): <1–7 の何番か>
- 初出 intent: <avoid / targeted / spread / stack / raidwide / tankbuster>
- 単独か複合か: <単独 / 複合 (2段連携)>
- 未訓練 marker の使用: <なし / 廃止 (新 marker は追加しない)>
## Micro
- サイズ (X × Y × Z): <...>
- ブロックパレット: <Grass Block + Stone Bricks + ...>
- 視線の狙い: <入口から次のゲートが見える 等>
- カバー位置: <あり (柱×4) / なし (ボスアリーナ)>
- 照明: <Lantern × 8 偶数配置>
## Markers
- edg:connector:c1:N
- edg:connector:c2:S
- edg:mob:m1
- edg:mob:m2
- edg:mob:m3
- (ボス部屋のみ) edg:arena_center, edg:boss_spawn:b1, edg:party_entry:p1
- (ボス部屋のみ) edg:ref:N, edg:ref:NE, edg:ref:E, edg:ref:SE, edg:ref:S, edg:ref:SW, edg:ref:W, edg:ref:NW
## Sidecar JSON (該当する場合)
- roomId: <...>
- weight: <N>
- occurrences: <N または N-M>
- depth: <N>
- (ボス部屋) roomType: boss_arena
- (ボス部屋) arena.radius: <balance-TBD>
- (ボス部屋) arena.referencePoints: [N, NE, E, SE, S, SW, W, NW]
## Playtest 所感
<Step 6 のチェックリスト結果。未達項目があれば戻り先ステップを明記>
## 変更履歴
- YYYY-MM-DD: 初版作成 (<名前>)
- YYYY-MM-DD: <変更内容> (<名前>)
5.7 よくある失敗と対処
| 失敗 | 原因 | 対処 |
|---|---|---|
| EDG が部屋をロードしない | マーカー欠落・重複 | §5.3 の契約を再確認 |
| プレイヤーが迷う | Landmark 不足・Indexing 破綻 | Step 2 に戻る |
| 予兆が見えない | 装飾 VFX と重なる | 攻略必須表示を別レイヤーに分離 |
| ボス戦で外周に立てる | 予兆到達距離 < radius | sidecar JSON の arena.radius を調整 |
| タンクがタゲを取れない | 脅威倍率設定漏れ | ThreatTable の職業係数を確認 |
| 並行編集でコンフリクト | オーナー制の運用漏レ | §5.5 のマトリクスを更新 |
See Also
- 7-Step Workflow — レビューゲイトの対象になる7ステップ
- Boss Arena Design — ボスアリーナ特有の契約
- Reference & Glossary — phase2 / edg-design の正式参照