マップメーカーマニュアルブックプリセット

ルール、リセット手順、目的のメモ、そしてワールド内に置いておきたい QA チェックリストに、ぜひこのプリセットをお使いください。

このスクリーンショットの流れでは、マニュアルが散らばったテキストファイルではなくアイテムプリセットとして扱われるので、Command Pack の残りと一緒に保存しておけます。素のコマンドスニペットでは、この部分はたいてい隠れてしまいます。プレイヤーに見えるテキスト、バージョン依存のコンポーネント、そしてコピーして使える出力は、コマンドが Workbench を離れる前にすべて噛み合っている必要があります。

アイテムをより大きなコマンドチェーンに組み込む前に、このプリセットを確認用の場としてご利用ください。ツールチップがアイテムの効果をプレイヤーへ伝えているか、custom_data などの目に見えないコンポーネントがコマンドのロジックを支えているか、そしてコピーした出力が選択中の Minecraft バージョンにいまも適合しているかを確かめます。ゲーム内の結果をあえて簡素にしているのは、品質確認の最初の問い、すなわち「このコマンドは記事で説明したアイテムスタックを本当に配布しているのか」に答えるためです。

最新の Java 版のアイテムコマンドは、古いチュートリアルでは NBT として書かれていた多くの詳細を、アイテムコンポーネントとして表現します。とくにアイテムに名前、説明文 (lore)、エンチャント、レアリティ、カスタムモデルデータ、ポーションの中身、または unbreakable 状態を使う場合は、編集中も選択したバージョンをつねに表示しておいてください。

マニュアルに構成コマンドを詰め込みすぎないようご注意ください。コマンドは Project に保存しておき、この本ではテスターに何を実行すればよいのかを案内するだけにとどめます。

コマンドの検証が済んだら、マップやデータパックを動かす予定と同じバージョンファミリーで実行してください。コンポーネントが未対応であったり、対象として選んだプレイヤーの範囲が広すぎたり、データで担保されていない挙動をアイテムのテキストが約束していたりすると、きれいにコピーしたコマンドであっても設計を誤っていることがあります。スコアボード、ルート、ショップ、NPC、リセット系のコマンドを追加する前に、安定したバリアントを Project に保存しておきましょう。

• 生のコマンドテキストを編集する前に、まず Workbench のフィールドから操作してください。
• 表示テキストは、インベントリのツールチップに収まる長さに保ってください。
• 見える名前に頼らず、コマンドのロジックには custom_data をお使いください。

マニュアルを、リセット、テレポート、ゲームルールのプリセットと組み合わせて、完結したマップテストパックを作りましょう。

アイテムを使い回す場合は、スコアボード、ルートテーブル、NPC、リセット系コマンドを追加する前に Project エントリとして保存してください。こうしておけば、マップが大きくなってもアイテム定義を見直せる状態を保てます。

同じマップフロー向けのプレイヤー用プロンプトについては、マニュアルを NPC 会話向けの Written Book プリセット や プレイヤーフィードバック向けの actionbar プリセット と組み合わせてください。