物語グラフを作り、分岐ゲームを検証する

分岐型ナラティブゲームでは、会話を増やす前に状態モデルが必要です。シーン、持続変数を変える選択、後の行動を解放する条件、その条件が生む結末を名付けます。その後、物語の小さな一部分を依頼し、到達可能な状態の組合せをすべて確認します。以下のプロンプトでは任意の準備行動をちょうど二回、真偽値フラグを二つ、最後の確定操作を一つだけ使います。

「The Last Light at Orison Observatory」はオリジナルの架空教材用デザインです。山岳観測所、行動枠、物語フラグ、中継操作、結末は文章上の例であり、制作もテストもされていません。既存またはテスト済みゲームの報告ではなく、自分の案のひな型としてグラフを使ってください。

シーンを書く前に選択を図にする

まず小さなグラフを描きます。ノードはシーンまたは判断点、エッジはプレイヤーを別のノードへ移動させる行動、状態変数は後で選択肢や結果を変える記憶です。各選択について、開始値、実行条件、行動の効果、次のシーン、プレイヤーが見るフィードバックを記録します。

会話が二つのルートを別々に見せても、同じ状態に到達することがあります。グラフならその問題が早めに見えます。あるエッジが状態、新しい選択肢、結末のどれも変えない場合、それが雰囲気の演出か、意味のある分岐か判断します。キャラクターらしさを加える演出は残せますが、文章の言い回しだけで選択が重要だと証明しないでください。

この例は意図的に小さな構造です。観測所に入り、準備枠を二つ使い、共通の中継室へ戻り、最後のCommitでフラグを解決します。中継室に再合流すると物語を短く保てます。意味のある差はフラグが先へ運びます。

二つの選択と到達可能な四つの結果を定義する

嵐でアクセス橋が閉じる前に、プレイヤーは任意の行動枠をちょうど二つ使えます。各枠でArchive、Help、Waitから選びます。ArchiveとHelpはそれぞれ1枠を使い、各1回だけ選べます。Waitは状態を変えずに枠を一つ消費します。順序はどちらでもよく、プレイヤーは中継室へ戻る前に準備を両方完了できます。

このルールでは四つのフラグ状態、つまり準備なし、Archiveのみ、Helpのみ、両方が到達可能です。Waitを使えば分岐を強制されず、枠を未使用のまま使い切れます。二つの条件で準備の重複を防ぎつつ、Archiveの後にHelp、またはHelpの後にArchiveも選べます。各枠の後は同じ中継シーンへ戻すため、後の結果は到達不能な経路ではなく状態に依存します。

中継室では、`logFound`がtrueの場合だけ「checksumを再送」が有効になり、`keeperTrust`がtrueの場合だけ「手動再調整を依頼」が有効になります。使えない選択肢も画面に残し、短い理由とともに無効表示します。試しても何も変わりません。中継手順用のフラグや別行動枠は追加しません。既存のフラグで表現される操作を、一つのCommitで解決してから送信します。

結末は二つの準備フラグから直接決まります。

両方trueのケースでは、一つのCommitが有効な操作を順番にすべて終えてから送信する必要があります。`checksumDone`や`retuneDone`などのフラグを追加する近道は、プレイヤーとレビュー担当者が追う隠れ状態を増やします。ここでは準備フラグだけで十分です。フラグがCommitで処理する操作を決めます。この表は紙上モデルであり、プレイ可能なビルドが従う証拠ではありません。

グラフ、一つのシーン、経路監査の順に依頼する

プロンプトの役割を分けます。まずすべての経路と条件を含む状態契約を求めます。次に小さなプレイ可能シーンを依頼します。選んだツールで必要な状態を表現できないなら、構造化した設計引き継ぎを求めます。最後に観察を捏造せず全組合せを列挙する監査を依頼します。分岐型ナラティブ用プロンプトを、制作者が確認できる遷移に結びつけられます。

プロンプト1：物語グラフを返す

「The Last Light at Orison Observatory」の分岐ナラティブゲームの一部を設計してください。
これは架空のアイデアで、制作またはテスト済みのゲームではありません。

嵐が橋を閉じる前に、プレイヤーには任意の準備行動枠がちょうど二つある。
各枠で選べるのはArchive、Help、Waitのみ。
Archiveは枠を一つ使い、一度だけ選べて`logFound=true`にする。
Helpは枠を一つ使い、一度だけ選べて`keeperTrust=true`にする。
Waitは枠を一つ使い、どちらのフラグも変えない。
順序は自由。両方、一方のみ、どちらも選ばないことができる。
準備枠の後は同じ中継室へ戻る。

中継室では`logFound=true`のときのみ「checksumを再送」を有効にし、
`keeperTrust=true`のときのみ「手動再調整を依頼」を有効にする。
使用不可の行動も正確な理由を添えて無効表示し、試しても何も変えない。
中継完了用フラグも追加の中継行動枠も加えない。
どちらかのフラグがtrueなら最後のCommitを一度だけ使える。
フラグが許す操作を次の順で解決する：`logFound`ならchecksum、
`keeperTrust`なら手動再調整、その後に送信。
どちらもfalseならCommitは使えず、「避難」が送信なしで物語を終える。

ノード／エッジ表、開始状態、各選択の条件と効果、見えるフィードバック、
リセット状態、四つすべてのフラグ組合せに対する結末表を返す。
まだ曖昧なルールがあれば列挙する。経路、フラグ、結末を追加しない。

これは長い文章ではなく、完全なグラフ契約を求めています。Waitでどちらの枠も消費できること、二つの準備行動をどちらの順でも選べること、中継室が共通状態に戻ることを確認します。「どちらもなし」のケースが到達不能になっていたり、中継手順のフラグを別に追加したりしていたら、会話や絵を依頼する前に契約を直します。

プロンプト2：物語の一部分をプレイ可能にする

以下の承認済み状態契約から、小さなナラティブゲームの一部分を作ってください。
観測所への入口、Archiveシーン、Helpシーン、共通の中継室、
両フラグfalseの場合の「避難」選択肢を表示します。

任意の準備枠はちょうど二つ。各枠にArchive、Help、Waitを表示します。
`logFound`がtrueになったらArchiveを無効化し、
`keeperTrust`がtrueになったらHelpを無効化します。
ルートの順番は自由に保ちます。
中継室に両方のフラグを表示し、checksumや再調整が無効の場合、
試しても状態が変わらないよう理由を説明します。

最後のCommit操作は一つだけ。少なくとも一つのフラグがtrueのときだけ使えます。
`logFound`ならchecksum、次に`keeperTrust`なら手動再調整、
最後に送信を解決します。完了フラグや別の中継行動枠を求めません。
二つの既存フラグだけで結末を決めます。
両方falseの場合は送信なしで避難する結末を含めます。

初期状態、すべてのシーン遷移、各フラグの変化、有効／無効の行動、
結果のフィードバック、リセットの挙動を示します。
状態変化が分かる程度に会話を短くします。
対象ツールで条件や操作を表現できない場合、
操作不能な物語をプレイ可能な分岐ゲームと見せず、設計を引き継いでください。

会話とともに状態表示も求めます。このシーンでは、どの準備が完了したか、なぜ操作が無効か、Commitが実際に何をするかを読者が確認できる必要があります。プロンプトは要件を書くものであり、特定のゲームメーカーが実装する証拠ではありません。分岐のある会話が永続状態と同じだと決めつけず、返された操作を契約と比較しましょう。

プロンプト3：経路を列挙し、実際の観察と比べる

状態契約に照らして物語グラフを監査してください。プレイテスト結果を作らないでください。

次の中継室開始状態を四つ列挙してください。
1. `logFound=false`, `keeperTrust=false`
2. `logFound=true`, `keeperTrust=false`
3. `logFound=false`, `keeperTrust=true`
4. `logFound=true`, `keeperTrust=true`

各状態でCommitが有効か、どの操作をどの順で解決するか、
送信があるか、結末を報告してください。
Archive、Help、Waitで二つの準備枠から各組合せに到達できること、
ArchiveとHelpを二度ずつ選べないこと、無効操作で何も変わらないことを確認します。
リセットで両フラグを消し、二つの枠を戻すことも確認してください。

私がビルドの観察を提示した場合は、期待状態と一段ずつ比較して
最初の不一致を特定してください。
観察を提示していない場合は、提案用チェックリストのみを返し、
結果を未観察と明記します。
提示された観察が経路の成功を示さない限り、合格と主張しないでください。

監査プロンプトは不足する証拠を明示します。テスト前なら期待遷移とチェックリストを返せます。実際に観察した後なら、その手順を紙上モデルと比較して範囲を限定した修正を一つ求められます。プロンプトだけを根拠に動作を正しいと証明することはできません。

行き止まりと意味のない選択肢を見つける

初期状態からグラフをたどり、各組合せに合法な経路があるか確認します。次に、到達したシーンが状態表の予測する結果を示すか確認します。観測所の両方trueの結末は、記述ルールから導いた候補であり、測定結果ではありません。

最初の不一致から変更内容を決めます。結果に到達できないなら、結末の会話を編集する前にグラフまたは枠の意味を直します。状態は正しいが無効な選択肢が分かりにくいなら、隣に表示する理由を改善します。四つの遷移すべてが契約に一致した後で、状態モデルを変えずに物語の質感を追加しましょう。

書いたグラフを最初の制作パスに持ち込む

グラフに矛盾がなければ、焦点を絞った自然言語ブリーフをゲーム案の試行に使えます。SEELEの現在のFree AI Game Makerページは、平易な英語でのゲーム説明、2Dまたは3D結果の確認、Workspaceでの反復、表示される生成コストとアカウント選択肢の確認を案内しています。この一般的な流れは、永続する物語フラグ、条件付きの物語行動、観測所の設計を確認するものではありません。

ノード／エッジ表と四行の結末表を制作依頼に含めます。その後、返された実際の状態、選択肢、フィードバック、再開挙動を確認します。特定の条件が欠けていれば、その条件を表現するよう依頼して再確認します。選んだフローで永続フラグを示せないなら、グラフを設計引き継ぎとして保管し、プレイ可能と説明する前に適したツールで評価してください。

グラフが機能してから物語を深める

会話を増やすためだけに三つ目のフラグを追加しないでください。まず今の二つのフラグが四通りに組み合わさること、中継の選択肢が応答すること、Commitが定義順に動くこと、リセットが開始状態を戻すことを確認します。それから既存グラフでは表現できない選択を作る場合にだけ、シーンまたは変数を一つ加えます。読み方だけ違いプレイ結果が同じ分岐を増やすのではなく、新しい選択を結果に結びつけられます。

自分の物語契約を用意したら、無料AIゲームメーカーにコンパクトなグラフを入力し、結果が何を表現しているか確認して、状態遷移を一つずつ修正します。