クリックごとのルールを見えるようにする

すべてのクリックに見えるルールを持たせる

優れたポイント＆クリック型アドベンチャーのプロンプトでは、各ホットスポットの動作、インベントリ項目を使える条件、状態の変化、失敗した操作からプレイヤーが何を学ぶかを定義します。部屋1つと完結したパズル1つから始めます。明確な手がかり、少数の状況依存アクション、すべての物体とフラグを既知の状態に戻すリセットを用意します。

このガイドでは、架空の灯台の部屋のパズル「Bellglass Archive」を手作業で設計した例として扱います。以下のプロンプトひな形は実行しておらず、この部屋はプレイ可能なビルドでも、オンラインで試した事例でもありません。価値があるのは状態の仕様です。自分のシーンに合わせて応用し、生成したビルドを依頼した挙動と正確に比較できます。

次の順で進めます。ホットスポットと操作を名付け、インベントリとフラグを定義し、成功する操作を順にたどり、無効な操作への反応を決め、受け入れケースを書きます。「動くパズル」を曖昧に求めるより、プロンプトを調べやすくできます。

手がかりの部屋と状態を定義する

Bellglass Archiveの舞台はLantern Galleryという部屋1つです。目標は3つの記号の順番を明らかにして入力し、書庫の扉を開けることです。部屋には作業台の真鍮レンズ、木製の雨戸、空のレンズ台、何もない壁、3つのダイヤル板、施錠された扉があります。それぞれ別のホットスポットで操作も異なります。物体をクリックしただけで関連し得る操作をすべて自動実行してはいけません。

プロンプト、期待する操作の追跡、後のレビューが同じ事実を参照できるよう、短い状態リストを使います。

• Inventory item: brass lens, either carried or installed in the stand.
• Boolean flags: brassLensCarried, shuttersOpen, lensInstalled, clueSeen, and doorOpen.
• Ordered input: dialSequence, which starts as an empty list and stores only the current correct prefix.
• Initial state: empty inventory, every flag false, shutters and door closed, and dialSequence=[].

ワールド内の物体とインベントリ項目の関係を明確にします。レンズを設置するとインベントリからは消えますが、破壊されるわけではなく台に残ります。同様に、手がかりを見た後で雨戸を閉じると投影は隠れますが、日誌に記録した情報は消えません。こうした区別で、シーンが進行を忘れたように見えるのを防げます。

プロンプト1：部屋の仕様を定める

架空のBellglass ArchiveにあるLantern Galleryという、独自のポイント＆クリック型パズル部屋を1つ設計する。ホットスポットは作業台の真鍮レンズ、木製の雨戸、空のレンズ台、何もない壁、3つのダイヤル板、施錠された書庫の扉に分ける。開始時はレンズが台上、インベントリは空、雨戸は閉じ、扉は施錠。brassLensCarried=false、shuttersOpen=false、lensInstalled=false、clueSeen=false、doorOpen=false、dialSequence=[]とする。「調べる」「取る」「アイテムをホットスポットに使う」「ダイヤル入力」「再開」を別々の操作として定義する。各ホットスポットの状態、可能な操作、変化するフラグまたはインベントリ、見えるフィードバックを表にする。部屋、人物、収集物、記載のないパズルルールを追加しない。

この最初のプロンプトの後は、会話や別室を求める前に、提案された状態表を確認します。「調べる」と「使う」が混同されている場合や、レンズをどんな物にも向けたとき消費される場合は、物語を広げる前にロジックを直します。簡潔なルールは改訂しやすく、最初のプレイ可能な操作の具体的な基礎になります。

完結した操作ループを1つプロンプトにする

次に、各状態変化が分かるプレイ可能な部屋を求めます。クリックした結果はプレイヤーが解釈できるようにします。「調べる」は物体を説明し、「取る」はインベントリを変え、「アイテムをホットスポットに使う」は対象を判定し、ダイヤルをクリックすると正しい接頭順なら進み、誤りならリセットします。所持レンズを誤ったホットスポットに使った場合は、コストなしで失敗させます。アイテムを失ったりパズルの進行が壊れたりせず、失敗した理由と次に試す場所が分かるようにします。

プロンプト2：最初のプレイ可能範囲を依頼する

Lantern Galleryの状態仕様を使い、他のレベルを加えず、プレイ可能なポイント＆クリック部屋を1つ作る。「調べる」「取る」「アイテムをホットスポットに使う」「ダイヤル入力」「再開」を別操作にする。所持中の真鍮レンズを設置できるのはレンズ台だけ。他で使った場合はレンズをインベントリから除き、brassLensCarried=false、lensInstalled=trueにして、台に固定したままにする。ダイヤル板、壁、扉、その他のホットスポットで使うときは短い「合わない」表示を出して台を強調する。レンズはインベントリに残し、フラグ、dialSequence、部屋状態を何も変更しない。この拒否にコストや状態遷移はない。
lensInstalled AND shuttersOpenがtrueになったら、左から右へ壁の手がかりTideの波、Wing、Bellを表示する。clueSeen=trueにし、その後雨戸を閉じても日誌に残す。ダイヤル順Tide、Wing、Bellを受け付ける。間違った記号ではアイテムを使わずdialSequenceを消去する。正しい全順序の後だけdoorOpen=trueにする。再開では正確な初期状態に戻す。ホットスポット、インベントリ、手がかり、ダイヤル、フィードバック、再開時の反応を示す。状態変数、操作ルール、成功の追跡、失敗の追跡、受け入れケースを返す。返却されたビルドに目で見える形で表されていない結果を主張しない。

プロンプトでは各条件をプレイヤーに見える合図に結び付けています。実装内のフラグだけではレビューしにくいものです。変化したインベントリアイコン、投影される手がかり、有効な対象の強調表示、扉のアニメーションが、観測可能なチェックポイントになります。パズルに関係のないボタンや物語システムを増やさず、状態が分かる控えめな反応を求めます。

基本の部屋は、どちらの準備順でも使えるようにします。プレイヤーはレンズを設置する前に雨戸を開けても、雨戸を開ける前にレンズを設置してもかまいません。どちらも2つ目の条件が満たされた瞬間に手がかりが現れます。これは小さな分岐で、パズルが状態に基づいているか、操作順の暗記に依存しているかを確かめられます。

手がかりとダイヤル順を手で確認する

ビルドを評価する前に操作の追跡を書きます。追跡には操作、前後の状態、見える反応を記載します。成功ルートと、回復可能な間違いの簡潔な基準になります。以下の表はBellglass Archive用に作成した期待値であり、生成ゲームの結果ではありません。

次に誤ったダイヤル入力を追跡します。手がかり表示後にTide、続けてBellを選びます。2つ目の記号が期待するWingと違うため、途中の入力は空リストに戻ります。手がかりは日誌に残り、レンズは設置済み、扉は施錠状態です。準備をやり直したりアイテムを失ったりせず、もう一度試せます。

もう一方の正しい準備順も追います。レンズを取り、台に設置してから雨戸を開けます。最後の操作の前は手がかりが見えず、その後3つの記号が現れclueSeen=trueになります。手がかりを読んだ後に雨戸を閉じると投影は消えますが、日誌の記録は残ります。状態仕様では、現在見えているものとプレイヤーが学んだことを区別します。

これらの操作追跡は手で指定したもので、ソフトウェアテスト済みではありません。実際の出力をレビューする際はバージョンを記録し、新しい再開状態から各操作を実行します。見える結果を追跡と比較し、ビルドで実際に確認した後にだけ「観測済み」と記録します。状態の変化を見分けるフィードバックが足りなければ、その状態を見せるようプロンプトを改訂します。

状況ルールを1つずつ改訂する

初版で雨戸を開くかレンズを置くだけで手がかりが出るなら、手がかり条件だけを改訂します。部屋の配置、インベントリルール、ダイヤル順、日誌の挙動、再開は保ちます。これで変更を切り分け、後の比較に意味を持たせられます。「パズルを分かりやすくして」のような広い依頼では、残したい操作も新しい期待結果も伝わりません。

プロンプト3：手がかりの表示だけを調整する

Lantern Galleryでは、壁の手がかり表示ルールだけを改訂する。lensInstalled=true AND shuttersOpen=trueの場合に限りTide、Wing、Bellを表示する。どちらかがfalseなら壁の投影を消す。clueSeenがすでにtrueなら、雨戸を閉じても手がかりを日誌に残す。現在のシーン、ホットスポット、インベントリの挙動、誤った対象への反応、dialSequenceの挙動、扉のルール、再開は保つ。変更したルール、変更しないルール、3つの変更前後状態（レンズなしで雨戸開、レンズ設置で雨戸閉、両条件true）を返す。ヒントシステム、新しい物体、会話分岐を加えない。

改訂ごとにルールを1つだけ変え、前後の記録を簡潔に残します。元のビルドまたはプロンプト版、変更した文、開始状態、操作、結果の見える状態を記録します。依頼以上の結果が変わった場合は、新しい仕組みを黙って受け入れず、別に記録します。これで次のプロンプトが正確になり、不一致がルール、フィードバック、依頼していない追加のどれによるか判断しやすくなります。

アドベンチャーの境界ケースを確認する

受け入れケースには、前提不足、無効な対象、途中までの進行、完了、再開を含めます。「有効」かだけでなく、プレイヤーに何が見え、何が変わらないべきかを答えられるようにします。以下は将来のビルド向けの提案です。

無効な対象のケースには特に注意します。レンズはインベントリに残り、台が強調され、すべての部屋フラグとダイヤル値が元のままであるべきです。ここでいう「コストなし」とは、アイテム、資源、状態遷移を消費しないことです。短い説明表示は出してかまいません。この定義により、曖昧な失敗反応がパズル状態をひそかに変えるのを防ぎます。

隣のアイデアにあったという理由だけで永続化機能を追加しないでください。この部屋には固定された小道具と日誌に記録される手がかりがあります。部屋をまたいだ可動物体の記憶、音楽による環境変化、進行状況に応じたヒントは含みません。範囲を保てば、1つのプロンプトで1つの設計上の問いに答えられます。

制作ワークフローに概要をつなぐ

現在のFree AI Game Makerページでは、平易な英語でゲーム案を書き、プレイ可能な2Dまたは3Dの初版を生成し、ブラウザーで試し、追加プロンプトで調整する一般的な制作の流れを説明しています。無料Koinsで開始でき、生成ごとにコストを確認するよう案内しています。これらの説明から、Bellglass Archiveが生成済みであることや、ポイント＆クリック操作が記述どおりに対応していることは分かりません。

自分の部屋の案を制作フローに持ち込む際は、ホットスポット図、初期状態、有効なアイテム対象、手がかり条件、ダイヤルルール、失敗時の反応、再開状態を示します。実際の出力で何が確認できるかを見てから、受け入れケースを1つずつ試します。操作を確認またはリセットできないなら、別室を増やす前に、どうすれば見える形で再現できるかを明確にします。

読みやすいパズル部屋を1つ作る

長い冒険を頼む前に、各クリック、アイテム、条件、フィードバックを定義します。状態表、成功の追跡1つ、回復可能な失敗1つ、リセットルールがあれば、実用的なプロンプト集となり、将来のビルドの実際の挙動を確認できます。

自分のプロジェクトを形にするには、Free AIゲームメーカーを続けて利用できます。部屋1つ、パズル目標1つ、レビューしたい観測可能なルールを用意しましょう。

ポイント＆クリック型アドベンチャーのプロンプト FAQ