AIでカード型ナラティブゲームを作るには、各カードに物語上の役割を与えます。プレイヤーが何を伝えられるか、どの状態が変わるか、別の登場人物がどう反応するかを決めます。最初の短い循環はカード4枚、メッセージ欄2つ、返信1つ、リセットで作れます。大きなデッキや複数の分岐シーンを始めなくても、カードの意味を示せます。
以下のThe Last Postcardは、版画家Irisと、同じ町の別の場所へ引っ越した弟Eliを描くオリジナルの紙上設計です。制作もプレイテストもしていません。ルールモデルとして使い、自分のプレイ可能な版を期待状態と照らしてから、挙動をテスト済みと呼んでください。
すべてのカードで物語に伝えられることを変える
ナラティブカードは、絵枠付きの会話選択肢以上のものです。詳細を明かす、約束をする、相手が答えられる質問をする、後のシーンが知る情報を変えるなど、プレイヤーが指摘できる働きを持たせます。2枚のカードが常に同じ返信と状態を生むなら、統合するか、異なる結果を与えます。
The Last Postcardでは、家族間の行き違いの後に町の向こうへ引っ越したEliに、Irisがメッセージを一つ送ります。最初の版の手札は固定で、ランダムなドローはありません。IrisはMemory欄とReply欄を埋めて送信します。一つのメッセージ内で各カードは一度だけ使えます。

まず二つの欄の役割を分けます。MemoryカードはEliが言及できる文脈を与えます。ReplyカードはIrisの返答を決めます。Questionの条件が重要です。共有した詳細について誠実に尋ねることと、Eliに伝えていないことを尋ねることは異なります。
| カード | 欄 | 状態への効果 | 物語上の結果 |
|---|---|---|---|
| Postmark | Memory | detailShared=true にする。 | Eliは名指しされた川辺の場所と日付を思い出せる。 |
| Blank Page | Memory | detailShared=false のまま。 | このメッセージでは特定の思い出を共有しない。 |
| Promise | Reply | promiseMade=true にする。 | EliはIrisの約束を聞き、受け止められる。 |
| Question | Reply | detailShared=true の場合だけ有効。それ以外は何も起こらない。 | 有効なら、Eliは共有した場所について答える。 |
この契約では各カードに欄、前提条件、見える結果があります。また、維持すべき整合性も明確です。無効状態のQuestionカードが質問を送信したり、フラグを変えたりしてはいけません。
シーンを増やす前に有効な組み合わせを確定する
会話を書く前に有効な組み合わせを記します。有効な組は3通り、無効な組は1通りです。各有効組に短い返信を用意する方が、状態規則が文章に隠れた大きな分岐スクリプトより確認しやすくなります。
| Memory+Reply | 送信後のフラグ | Eliの返事 |
|---|---|---|
| Postmark+Promise | detailShared=true、promiseMade=true | 川辺の場所を思い出し、Irisの約束を受け止める。 |
| Postmark+Question | detailShared=true、promiseMade=false | その場所について答え、Irisに返事を促す。 |
| Blank Page+Promise | detailShared=false、promiseMade=true | 約束を受け止め、次回は具体的な思い出を共有してほしいと尋ねる。 |
| Blank Page+Question | 変化なし。この組ではメッセージを送れない。 | Questionは表示したまま無効にし、「先に思い出を共有してください」と示す。 |
返信文に、選んだカードが設定していないフラグを含めないでください。特にBlank Page+Promiseでは質問を使っていないため、質問への回答は生まれません。無効な組にも理由を添えれば、プレイヤーはカードの故障ではなく不足条件だと分かります。
この版で引き継ぐ値はdetailSharedとpromiseMadeの二つだけにします。Eliの返信後、小さな引き継ぎパネルで次のシーンに渡る値を示します。これは状態のプレビューで、二つ目のプレイ可能なシーンではありません。リセットで両方の値を消し、固定手札を戻し、欄を空にします。
最小のカードから返信までの循環をプロンプトにする
あらすじや雰囲気だけでなく、操作と状態遷移を依頼します。開始時の手札、二つの欄、各カードが変える状態、送信が有効となる条件、送信後に確認できる項目を示します。最初の出力は一度で確認できる範囲に絞ります。
プロンプト1:案をルール契約にする
The Last Postcardという、1シーンのカード型ナラティブゲームを設計してください。 プレイヤーはIrisから弟Eliへメッセージを一つ送ります。 固定カード4枚だけで開始:Postmark、Blank Page、Promise、Question。 Memory欄とReply欄を一つずつ埋めてからSendを選びます。 各カードはメッセージ内で一度だけ使えます。ドロー、捨て札、追加カードはありません。 PostmarkはdetailShared=trueにし、川辺の場所と日付を共有します。 Blank PageはdetailShared=falseのままにします。 PromiseはpromiseMade=trueにします。 QuestionはdetailShared=trueのときだけ有効です。それ以外は表示したまま無効にし、理由「先に思い出を共有してください」を表示して、何も変えないでください。 Postmark+Promise、Postmark+Question、Blank Page+Promiseを、それぞれのフラグに合う異なる返事で解決してください。Blank Page+Questionは拒否します。 返信の後、二つの引き継ぎフラグをパネルに表示します。リセットで両フラグを消し、カード4枚を戻し、欄を空にします。 状態表、メッセージの流れ、受け入れ確認項目を簡潔に返してください。 別シーン、ランダムドロー、未指定のフラグを追加しないでください。
このプロンプトはまずルール契約を求めます。対象ツールが一度ですべての規則を実装できなくても役立ちます。有効な3組すべてに返信があり、4組目が拒否され、リセット状態が明確か確認します。プレイ可能な操作を依頼する前に、ここで矛盾を直します。
プロンプト2:確認可能な操作を一つ依頼する
承認済みの契約を使い、カードメッセージ操作を一つ実装してください。 カード4枚、MemoryとReplyの欄、Send、現在の二つのフラグ、Eliの返事、Resetを一つの見やすいシーンに表示します。 Replyカードを有効にする前にMemoryカードを選ばせてください。カードの二重使用やBlank Page+Questionの送信を許可しないでください。無効理由をそのまま表示します。 Send後は使用した組を手札から移し、Eliの対応する返事を示します。 detailSharedとpromiseMadeは次シーンへの引き継ぎパネルだけに表示し、二つ目のプレイ可能なシーンを追加したり、存在するように示したりしないでください。 川辺の版画工房とアパートを舞台にし、未使用のカード効果を主張しない短い会話にします。カード選択、状態変化、リセットを見えるようにします。 指定ルールに対応できない場合は、黙って変更せず制限事項と設計引き継ぎを返してください。

配置で状態が見やすくなることは期待できますが、操作自体は確認してください。先にMemoryカードを選べますか。Postmark後にだけQuestionが無効から有効へ変わりますか。選んだ組を送信し、その組に合う返事が表示されますか。これらはビルドの確認項目であり、プロンプトだけから保証されるものではありません。
プレイテストと呼ばずに紙上で修正する
プロンプトで規則を指定しても、プレイヤーの操作が分かりにくい場合があります。この設計では、思い出を共有していないとQuestionは無効です。無効表示だけでは、どうすれば使えるか伝わりません。「先に思い出を共有してください」という理由を表示し、カードは見えるままにして、無効な操作では状態を変えない設計に修正します。
これは紙上の反復であり、ルールと期待される返事を紙上で比較します。観察済みのユーザーテスト、生成ゲームの結果、製品が条件を実装した証拠ではありません。実際のビルドでは、必要なカードをプレイヤーが見つけられるか、無効操作で両フラグが変わらないか観察します。
| 版 | 思い出未共有時のQuestion | 期待状態 | 実ビルドで確認すること |
|---|---|---|---|
| 修正前 | 理由なしで無効。 | detailShared=false、操作なし。 | 選べない理由が分かるか。 |
| 紙上修正 | 「先に思い出を共有してください」と表示して無効。 | Postmark送信までは状態変化なし。 | 理由が実際の前提条件を示し、表示され続けるか。 |
文言の変更は物語ルールを変えません。足りない文脈へ進む道筋をプレイヤーに示します。AIに試作の修正を頼むときも区別します。使いやすさのヒントがdetailSharedを勝手に設定したり、メッセージを送ったりしてはいけません。
状態、返信、リセットを確認する
クリーンな開始状態から有効な組をそれぞれたどります。Send後に選んだカードが手札から消えること、Eliの返事が組み合わせに合うこと、引き継ぎパネルに定義した二つの値だけが残ることを確認します。その後リセットして繰り返します。読みやすい返事でも、選んだカードと食い違ったり前回の実行に影響されたりすれば不十分です。

| 症状 | 最初に確認するルール | 次の確認 |
|---|---|---|
| Blank Page後でもQuestionが使える。 | detailSharedの条件。 | Blank Pageでfalseのままか、無効な操作が何もしないか確認する。 |
| 約束していないのにEliが約束に触れる。 | Replyカードの状態効果。 | promiseMade=trueにするのがPromiseだけか確認する。 |
| 選んだカードが両方とも再使用できる。 | メッセージ内の一回限りの扱い。 | Send後に組を送信済みにし、二重使用を防ぐ。 |
| 次の実行に古いフラグが残る。 | リセット順序。 | 両方の引き継ぎフラグを消し、元のカード4枚を戻す。 |
| 返事が誤った文脈に触れる。 | 組み合わせから返信への対応。 | 会話を増やす前に、選んだ組を4行の結果表と照合する。 |
実際に観察した開始状態、選んだカード、フィードバック、返信、リセット後の状態を記録します。一つでも契約と異なるなら、ルールかプロンプトを一度に一つだけ変更し、同じ手順を再実行します。紙上の予測をプレイ可能なビルドの合格結果として記載しないでください。
最初の制作段階へカード契約を持ち込む
SEELE公式Free AI Game Makerページは、平易な英語でゲーム案を書き、ブラウザーで2Dまたは3Dのプレイ可能な結果を試し、追加プロンプトで改良する流れを説明しています。FAQでは、提出前にSEELE Workspaceで選択モデル、利用可能なKoin残高、表示される生成コストを確認できるとしています。これは一般的な制作手順の説明であり、カード手札、永続フラグ、条件付き会話、架空のLast Postcardルールが実装されたことを示しません。
結果を上記の受け入れ確認と比べます。カード状態やQuestionの無効条件が欠けていれば、一つに絞った変更を依頼して再確認します。必要な状態挙動のない物語レイアウトが返った場合は、動作するカード型ナラティブゲームと説明せず、別の制作工程へ渡す設計仕様として扱います。
新しい選択肢が生まれるときだけカードを追加する
有効な組3通り、無効状態、返事、引き継ぎパネル、リセットを簡単に追えるまで最初の手札を固定します。Irisが伝えられることやEliが答える内容を変える場合にだけカードを加えます。絵や文言を変えるだけなら、新しい状態変数は必要ありません。
自分のビルドが意図どおりに動いた後で、SEELEの無料AIゲームメーカーからゲーム案の制作と確認を始められます。物語の返事が原因となった選択に結び付くよう、反復ごとにカード契約を手元に置きます。
よくある質問
ナラティブゲームは最初に何枚のカードを使うべきですか?
異なる物語上の行動を表すために必要な最小数から始めます。The Last Postcardは各カードの欄、状態効果、条件が異なるため4枚です。新しい選択肢や返事が増えると分かるまで、大きな手札は待ちます。結果が増えないカードを足すと最初の循環が確認しにくくなります。
ランダムなデッキを使えますか?
使えますが、固定手札の方が最初の物語循環を考えやすくなります。ドロー順や偶然性を加える前に、同じカード組が同じフラグと返事を生むか確認できます。ランダム性が設計の中心なら、カード効果と返信規則を明確にしてから追加します。
無効なカードは消すべきですか?
通常は表示したままにし、足りない条件を説明します。この例のQuestionは、Postmarkで詳細を共有するまで手札に残したまま無効です。理由があれば次の有効な操作が分かります。カードを隠すと、質問が物語にないのか操作が未完成なのか判断しにくくなります。
メッセージを送った後に何を確認すべきですか?
各カードが割り当てられた状態だけを変えること、返事が組に合うこと、使用済みカードを二度使えないこと、リセットで引き継ぎフラグが消えることを確認します。クリーンな開始状態から有効な組をすべて繰り返します。未使用のカード効果を含むもっともらしい返事なら、状態と会話は食い違っています。
The Last Postcardの例はプレイテスト済みですか?
いいえ。カードの役割、状態条件、返事の候補を説明するためのオリジナルの架空の紙上設計です。このページのプロンプトと画像は制作済みゲームやユーザーテストを示しません。状態表は期待する設計として扱い、自分のプレイ可能版で得た観察と比較してください。


