長い機能一覧でなく検証できる一手から始める

長い機能一覧でなく検証できる一手から始める

Match-3パズル向けの有用なAIプロンプトでは、プレイヤー目標、合法な交換、マッチ規則、手数コスト、補充順、終了条件を定義します。小さな盤面に規則をまとめ、見た目を整える前に一手を手計算します。4×4盤面でもタイミングの不足が見つかります。手が成立する時点、目標計の更新時点、空きマスへ入るタイルは何か。

このガイドでは、ruby、leaf、wave、sunタイルを使う架空の一人用パズル「Tideglass Conservatory」を扱います。規則と盤面は作者作成の教材です。4つのプロンプトテンプレートは記事向けに用意し、ゲーム生成器に送信していません。手計算の一手はソフト実行やプレイテストではありません。プレイ可能ビルドや測定結果も提示しません。

方法は単純です。最初の範囲を限定し、規則契約を書き、開始状態を正確に定め、一手を手で解き、境界ケース確認を依頼します。将来ビルドが期待盤面と違うとき、調べる具体的な場所ができます。

レベル規模の目標を一つ選ぶ

「Match-3ゲームを作る」はジャンルであり、最初のレベルではありません。最初のプロンプトで進行条件と終了までにプレイヤーができることを定義します。Tideglass Conservatoryでは4×4盤面、合法手4回以内に緑のleafタイルを3個消します。一人用レベルで、ブースター在庫、時間制、キャンペーンマップ、マルチプレイヤー、永続強化はありません。

これらは例の設計選択で、すべてのMatch-3ゲームが従うべき主張ではありません。別の最初の範囲を選ぶなら、プロンプトを広げる前に目標と除外内容を変えます。

プロンプト1：範囲を決める

Tideglass Conservatoryという架空の一人用Match-3パズルレベルを設計してください。最初のレベルは4行×4列の盤面で、左からA–D、上から1–4とラベルを付けます。合法手4回以内に緑のleafタイルを3個消すことが目標です。最初は盤面1つと目標1つだけ。ブースター、タイマー、キャンペーン進行、マルチプレイヤー、永続強化を除外します。プレイヤー目標、盤面要件、操作規則、成功条件、失敗条件、明示的な除外を返します。不足する判断は新システムを創作せず、未解決質問として列挙してください。

達成可能なレベル一つと、目先の行動と後の進行の区別があるか確認します。キャンペーンや複数の強化が加わるなら、タイル解決規則を書く前に外します。

交換、消去、終了状態の順を書く

「3個マッチして盤面を補充」だけでは重要な挙動が未定義です。この教材デザインでは上下左右に隣接するマスだけを選べます。交換後、横と縦に同じタイルが3個以上続く列を探します。成立しなければ元の位置へ戻し、手数を使いません。成立すれば1手を消費し、マッチした目標タイルを各1回数え、マッチ全体を消し、タイルを下へ落とし、各列に宣言したキューから空きを補充します。

補充後に盤面全体を再走査します。新たな列ができれば手数を増やさないカスケードとして解決し、安定するまで続けます。全カスケード後に勝利条件を確認し、未達成かつ手数0なら失敗です。順序を書けば同じプロンプトが別のゲームとして解釈されるのを防げます。

プロンプト2：メカニクス契約を明示する

承認済みのTideglass Conservatory範囲で、次の規則を定義します：上下左右に隣接するマスだけ交換可。交換で横または縦に同一タイルが3個以上連続する場合だけ合法。列ができない交換は戻し、手数を使いません。合法交換は手数を正確に1消費。横・縦の列をすべて探し、共有マスは和集合にして交差部を一度だけ数えます。leafの目標タイルを消去前に3個目標へ加え、その後和集合を除去します。重力を適用し、宣言した列キューから空マスを補充します。補充ごとに盤面全体を検査し、追加手数なしでカスケードを解決します。安定後にまず成功を確認し、目標未達で手数0なら失敗を確認します。解決順と簡潔な状態図を返し、曖昧さを指摘します。ブースターや特殊タイルを加えないでください。

タイミングを支配する「前」「後」「一度」「安定するまで」に注目します。交差部も確認します。横と縦の列がleaf一つを共有するなら、消去マスの和集合では一マスなので目標も一度だけ数えます。

再現可能な盤面をプロンプトへ渡す

手計算には座標と固定開始状態が必要です。表の各行は左から読み、1行目が上です。記号はR(ruby)、L(leaf)、W(wave)、S(sun)。初期盤面には横にも縦にも3連がなく、安定状態から始まります。

手計算する手では、解決前に影響列へ入る最初のタイルを指定します。AはS、BはW、CはL。空きがないDには入りません。これはこの例一回用の小さな決定的キューです。別カスケード例では、すべての新しい空きを埋める追加タイルを明示し、タイルを黙って作らないでください。

プロンプト3：開始盤面とキューを指定する

次の初期盤面をそのまま使います。上から下、列A–D：行1 R L W S、行2 L R L W、行3 W L R L、行4 R W S R。Rはruby、Lはleaf、Wはwave、Sはsunです。目標はleaf 3、手数は4。手B1↔B2では最初の補充をA:S、B:W、C:Lとし、空きのないDは補充しません。交換後の盤面、マッチマスの和集合、目標数、残り手数、重力後の各列、安定盤面を返します。開始盤面と補充タイルは変えません。追加カスケードがあるか、その理由も示します。

各トレースで座標ラベルを求めます。「緑の宝石が収まる」だけでは指定した盤面と比較できません。

一手を最初から最後まで手計算する

選んだ行動はB1↔B2です。1行B列のleafとその真下のrubyを交換します。結果、2行A–Cに横一列ができます。ほかの列はないため、異なるleafマス3つを目標に数えます。4手のうち1手を使い、残り3です。

2行A–Cを消します。A列は隙間の上のrubyが1マス落ち、Sが一番上を補充。B列はrubyが2行に落ち、Wが上へ入ります。C列はwaveが落ち、Lが上へ入ります。D列はそのままです。安定盤面は次のとおりです。

補充後の行と列を確認します。3個同じタイルが並ぶ列はありません。盤面は安定、leaf目標3/3、残り3手なので架空レベルは完了です。これは記載規則の期待状態で、ゲームやプロンプトを実行した証拠ではありません。

拒否された手とカスケードを確認する

有用なプロンプトはプレイヤーが通常ルート以外の行動をしたときの応答も尋ねます。これらは将来の実装向け受け入れ確認案で、ソフトウェアに対して実行していません。

各ケースに行動前状態、プレイヤー行動、期待する行動後状態、フィードバックを求めます。出力が複数規則を一度に変えるなら、不一致一つに絞って修正し、次の比較を有用に保ちます。

プロンプト4：受け入れケースとフィードバックを依頼する

承認済みMatch-3契約について、斜め選択、列を作らない隣接交換、横縦の交差、補充カスケード、最終手でleaf目標達成、目標未達で手数0、の確認ケースを作ります。各ケースで開始状態、行動、期待する安定状態、手数、leaf数、プレイヤーに見える表示を返してください。記載規則を変えないでください。追加補充タイルが必要なら列別キューを正確に示します。未解決ケースは成功結果を創作せず質問として記します。

テストを主張せず曖昧なプロンプトを修正する

「宝石とレベルのMatch-3パズルを作る」という短いv0では最初の手、目標、補充挙動が開いたままです。作者作成の改訂案で4×4盤面、上下左右交換、leaf目標3、合法手4回、列ができない交換の巻き戻し、最初の補充タイル固定を追加できます。範囲が限定され期待状態があるため確認しやすくなります。

このv0からv1への対比は教材として作ったシミュレーション上の明確化です。どちらのプロンプトも送信しておらず、改訂はモデル応答でも生成成功でもありません。将来の実行前に設計概要を改善する方法として使います。一つの規則を具体化し、期待状態を導き、それと比較できる出力を依頼します。

記載範囲内で製品情報を使う

SEELEの公式パズルメーカーのページは、学習可能な規則、見える手がかり、解決する行動を重視しています。手がかり・行動・結果が明確かを確認するよう案内し、例は隣接する空きマスへ記号を動かす4×4タイルパズルです。これはここでの従来型Match-3契約とは異なり、Tideglass Conservatoryや交換規則、生成結果を検証するページではありません。

次の段階では、自分のパズル案を平易な英語で説明し、生成前に表示コストを確認し、ブラウザーのプレイ可能な初版を記載規則と照合します。追加プロンプトは観察された不一致一つに絞ります。この記事の例は計画資料で、SEELEから得た結果ではありません。

検証できる小ささで最初のプロンプトを保つ

キャンペーンや強化を加える前に目標、交換規則、計上時点、補充キュー、終了順を決めます。次に解決した一手を期待状態と比べます。紙上でも規則が一致しないなら、内容追加を依頼する前に契約を直します。将来のビルドでは交換、消去、カスケード、補充、フィードバックを直接確認する必要があります。

自分のパズル概要を検討する準備ができたら、AI puzzle game makerを使い、結果を意図したメカニクスと照合します。

Match-3プロンプトのFAQ