3つのAIプロンプトでボクセル建築ゲームの範囲を決める

ボクセル建築ゲームのプロンプトは、プレイヤーが編集できるマス、資源の変化、配置したブロックが安定する条件、勝利条件を明確にすると確認しやすくなります。まずルール仕様を決め、最小限のプレイ可能ループだけを依頼し、誰かが観察結果を得てから3つ目のプロンプトで食い違いを診断します。

このガイドでは、Mosslight Spanという一人用の橋からビーコンへ向かう架空の演習を使います。マップ、ルール、V0とV1の比較は独自の教材として手計算で解決しました。3つのプロンプトテンプレートはゲーム生成ツールに送信していません。プレイ可能なビルド、プロンプト実行、ソフトウェアテスト、プレイテスト、測定結果もありません。

実用的な成果は短い手順です。編集できる世界を1つ定義し、採掘と配置を正確にし、範囲を限定した実装を1つ依頼し、後でビルドができたら明記した確認項目と照合します。これにより「ボクセルサンドボックスを作って」という依頼を、読者が実際に評価できるものにできます。

小さく編集可能な世界を定義する

最初のボクセル範囲には目的地、障害物、資源の選択、終了を示す合図が必要です。Mosslight Spanでは、それらを細い横断路1つにまとめます。探検者は安定した手前の足場、地表セル(0,1)に石ブロック2個を持って開始します。3セルの裂け目を挟んだx=1、x=2、x=3は空きマスで、x=4には向こう側の足場と暗いビーコンがあります。目標はそのビーコンに到達することだけです。

開始画面は成功結果ではなく設計上の選択を示します。空きマス3つを埋めるにはブロックが2個足りないため、資源量を変えるか別ルートを作る必要があります。この例では、恒久的な基礎ブロックの上、安定した脇の足場(0,0,y=1)に露出した予備キューブを1個置きます。側面は操作可能な高さで開始タイルからグリッド1面分隣接しています。開始地点から移動せずにMineを1回行うと回収でき、探検者は(0,1)に残ったまま、所持数は2個から3個へ増えます。

この範囲の残りは閉じておきます。配置できるのは裂け目の3セルだけです。ブロックは手前の足場か、すでに支えられた橋の列と面で接続する必要があります。恒久足場と配置済み橋ブロックは採掘できません。敵、クラフトレシピ、他の資源、タイマー、ランダムイベント、別ルートはありません。無効な採掘、配置、移動は状態を変えません。Restartは選択した版の正確な開始状態に戻します。

これらの制限があると、要求した各行動を目に見える状態に結び付けられるためプロンプトが使いやすくなります。「ボクセル世界」だけでは、マップ、操作範囲、建築境界、目標が解釈に委ねられます。ここでは地表5セルと脇の予備資源1つで、装飾を考える前に必要な世界を定義します。

採掘、配置、支持ルールを書く

mine、place、walkのような言葉は、正確な状態変化を定義する必要があります。この紙上例では、露出した脇の予備キューブだけを採掘でき、1回の行動で済みます。プレイヤーは移動せず、別途近づく必要もありません。配置では3セルの横断ゾーン上に建築カーソルを使うので、対象へ歩かなくても1行動を消費します。移動では、支持された地面の上を直交する1セルだけ進みます。

順序が重要です。支持されていない空中に置けると資源パズルがなくなります。どの距離からでも採掘できると予備の位置に意味がなくなります。配置によって探検者も進むと行動数が変わります。プレイ可能な実装を依頼する前に細部を明記し、拒否された行動では資源も位置も黙って変わらないと伝えます。

下の仕組み図では、予備キューブを開始地点から移動せずに回収し、x=1とx=2へ配置済みです。探検者は手前の足場に残り、石キューブ1個を持ち、x=3には有効な半透明プレビューがあり、ビーコンは暗いままです。将来のビルドと照合できる具体的なループ途中の状態です。

3つのプロンプトを順番に作る

ルールを考える、世界を作る、成功を評価するという仕事を1つのプロンプトにまとめないでください。各依頼に明確な入力と出力を持たせます。最初のプロンプトで仕様を固め、2つ目で小さな実装を求め、3つ目は実際の観察が得られてから修正案を提示します。

プロンプト1：実装前にルールを固定する

{game_name}という小さな一人用ボクセル建築ループを設計する。地表の座標は{grid_and_start}、目標は{goal}、開始時の所持品は{inventory}とする。編集できるブロック、採掘範囲の正確な仕様、採掘による所持品の変化、配置が合法となる条件、支持の伝播、合法な移動、厳密な勝利状態とリスタート状態を定義する。提示したマップでは開始タイルから面隣接する露出予備資源を、移動なしのMine 1回で回収し、座標と行動コストを返す。(1)座標表、(2)行動／状態表、(3)所持品ゼロと未支持セルの境界ケース、(4)合格確認5件を返す。依頼していない仕組みを加えない。実装案の前に矛盾を指摘する。

Mosslight Spanでは、入力を横断路の5セル、x=4の暗いビーコン、開始ブロック2個とします。予備資源を(0,0,y=1)に置き、操作高さで開始地点(0,1)に隣接させ、移動なしのMine 1回で回収するよう指定します。各行動後の所持数をモデルに言い直させます。仕様に帰り道、遠隔採掘、別の資源源が追加されたら、次のプロンプトを使う前にルールを訂正します。

プロンプト2：最小限のループだけを依頼する

承認済みのボクセルルール仕様{approved_contract}だけを、コンパクトなプレイ可能ループとして実装する。開始タイルから面隣接する予備資源を移動せずに回収するMine 1回を含め、すべての座標、所持数、行動コストを守る。有効／無効な配置、所持数の変化、支持された移動、ビーコン勝利、再開について、文字なしで見えるフィードバックを含める。仕様で許可した場所だけ編集可能にする。敵、クラフト、追加資源、ランダムイベント、マルチプレイヤー、2つ目の目標、大きな世界を追加しない。操作方法、短い実装要約、各合格確認について観察可能な証拠のチェックリストを返す。未実装または未観察はすべて未検証とする。

ループを1つに制限するのは設計上の選択であり、生成結果の保証ではありません。資源と支持ルールを確認できる状態にした後で、制作担当者は景観を加えられます。実装要約と検証チェックリストを依頼しても、依頼文自体を合格の証拠として扱わないでください。

プロンプト3：観察後にだけ修正する

承認済みの期待状態：{expected_state}。人が提供した実際の観察：{observed_state_or_blank}。提供された観察だけを期待ルールと比較する。観察が空欄なら人用チェックリストを返し、結果を診断しない。観察がある場合は最初の不一致、それに関係するルール、対処できる最小の単一変数の変更を特定する。再実行すべき合格確認と、変更しない先行確認を記す。新しい観察が提供されるまで修正が機能したと主張しない。

3つ目のプロンプトは結果を作り上げないよう意図的にしています。後のビルドがブロック2個で止まった場合、有用な観察には開始時の所持数、予備資源の対象、採掘前の探検者位置、採掘後の予備資源状態、配置拒否が含まれます。その情報があれば、レビュー担当者は操作範囲の問題と資源数や支持の問題を区別できます。情報がなければ、修正を断言せず状態を記録します。

橋の資源ループを手計算する

架空の比較では変数を1つだけ変えます。V1には露出した予備キューブがあり、V0にはありません。開始時の所持数とルートを含め、ほかはすべて同じです。表はエンジンやモデルが生成した結果と主張せず、資源不足を見えるようにします。

V1ルート全体はMine 1回＋Place 3回＋Move 4回＝計8行動です。最終状態は連続する橋3セル、空の所持品、向こう側の足場にいる探検者、点灯したビーコンです。これは記述したルールから計算した期待結果で、測定結果ではありません。V0の手順は、キューブ1個の変更が重要な理由を示します。それがなければ3つ目の配置コストを払えません。

後で版を作る場合は、終了状態だけでなくイベント順も確認します。配置前に予備資源を回収し、橋を渡る前に3つすべてを配置し、探検者がx=4へ入ったときだけビーコンが点灯します。視覚的な報酬が先に現れたら、画像やコードが別ルールを定義していると決めつけず、発動条件を仕様と比較してください。

将来のビルドを実際の観察と照合する

有用な合格確認では、開始状態、行動1つ、期待する変化を指定します。このマップでは、(0,1)からMineを1回行うと(0,0,y=1)の露出した予備資源だけを回収し、探検者は移動せず所持数が2から3になることを最初に確認します。次に、隣接しない、または覆われたブロックが採掘できないこと、x=1からx=3へのPlaceがブロックを順にちょうど3個消費すること、V0の3つ目の配置が所持数ゼロで拒否されることを確かめます。

続けて支持と移動を別々にテストします。橋の新しいブロックは手前の足場または直前の支持済みブロックにつながり、未支持の対象は所持数を変えずに拒否される必要があります。探検者は行動1回で直交セルを1つだけ移動し、支持された地面だけに入ります。橋の完成後、移動4回でx=4に到達するとビーコンが点灯します。Restartで選んだ版の予備資源、所持数、プレイヤー位置、暗いビーコンを復元します。

実際に見た内容を記録します。版、行動、実行前の状態、入力、結果位置、所持数、対象セルの状態、勝利フィードバックです。確認していなければ未検証と記します。書かれた合格テストは後で証拠を集める計画であり、挙動がすでに存在する証拠ではありません。

ボクセル仕様をWorkspaceに持ち込む

ルールの範囲が固まったら、短い仕様をゲーム制作ワークフローに渡せます。現在の公式Free AI Game Makerページには、島の世界を作るためにブロックを置いたり壊したりするVoxel Sandbox Builderのスターターカードが掲載されています。これは幅広いスターターカードの説明であり、Mosslight Span、この橋ルール、支持挙動、これらのプロンプトによる結果を確認するものではありません。

公式のFree AI Game Makerページでは、平易な文章でゲームを説明し、ブラウザーでプレイ可能な2Dまたは3Dの初回結果を確認し、追加プロンプトで改善する一般的な流れを説明しています。送信前に選択モデル、利用可能なKoin残高、表示された生成コストも確認するよう案内しています。範囲を限定したルールを持ち込み、実際に出力された結果を確認して上記の項目と照合します。観察する前にボクセル固有の実装や横断の成功を仮定しないでください。

案をまとめ始める場合は、Free AIゲームメーカーを使ってください。最初の依頼は小さく保ち、反復する前に生成結果を確認し、続ける前に表示コストを確かめます。これは一般的な製品への引き継ぎであり、Mosslight Spanのプロンプトやマップを実行したという主張ではありません。

よくある質問

ボクセル建築ゲームのAIプロンプトには何を含めるべきですか？

編集可能範囲、プレイヤーの開始位置、使えるブロック、正確な採掘範囲、配置ルール、支持条件、移動、目標、再開時の挙動を明記します。そのうえで小さな状態変化表と合格確認を求めます。詳細を決めると、自由形式のボクセルサンドボックスを広く依頼するより将来の結果を確認しやすくしつつ、ビジュアルテーマには自由を残せます。

ビルド用プロンプトを書く前に採掘範囲を定義する理由は何ですか？

範囲は行動数を変えるからです。Mosslight Spanでは露出した予備キューブが開始タイルに面隣接し、移動なしのMine 1回で回収できます。プロンプトで範囲を定めないと、実装が別途近づく行動を要求したり遠隔採掘を許可したりして、ルートと行動数が変わる可能性があります。ここでの正確な範囲は後でテストする架空のルールとして扱います。

例では横断に必要なブロックをどう確保しますか？

V0はブロック2個から始まり3個必要なため、所持数ゼロで3つ目の配置が拒否されます。V1では開始タイルから移動せず1行動で回収できる露出した予備キューブを1個加えます。これでブロック3個が横断路を埋め、支持された移動4回でビーコンへ届きます。8行動という数は手計算であり、ビルド結果ではありません。

Mosslight Spanのプロンプトは実行されましたか、またはゲームはテストされましたか？

いいえ。Mosslight Spanとルールは独自の架空演習で、プロンプトテンプレートはこの記事用に書いたものの、ゲーム生成ツールには入力していません。表は手計算です。プレイ可能なビルド、プロンプト実行、ソフトウェアテスト、プレイテスト、測定結果、オンライン事例はありません。

将来のビルドが手順と異なる場合はどうすればよいですか？

版、プレイヤー位置、所持数、対象セル、行動、結果フィードバックを含め、最初に異なる状態を記録します。その観察を対応する合格確認と比較し、ルールまたは実装の詳細を1つ変えて同じ手順を繰り返します。観察がなければ推測した結果を書くのではなく、チェックリストで観察を集めます。