AIで分岐型ナラティブゲームを作る方法

AIで分岐型ナラティブゲームを作るには、ゲームが記憶できる選択から始めます。プレイヤーが何を決めるか、ストーリーが両方のルートをどこで再会させるか、そしてその共有シーンで何が変化するかを書き留めてください。新しい対話行は選択を認識できます。変更されたアクションは、その選択によってプレイヤーが実行できるものを与えます。

架空のLast Ferry Dispatchでは、配達員が損傷した着陸地点に関する警告を港に持ち込みます。プレイヤーは警告をステーションの事務員に記録するか、ドックエンジニアのために伝書封筒を密封したままにできます。どちらのルートも桟橋に到達します。公開通知を依頼する方法が開かれるのは、どちらか一方だけです。

対話のドラフトを書く前に、3つのエンディングを書きます

2つのシーンと1つの状態値dispatchLoggedから始めます。最初は未設定です。事務員に伝書を見せるとtrueに設定されます。封筒を密封したままにするとfalseに設定されます。桟橋へ移動する前に値を保存し、選択を即座にロックして、2回目のクリックやキー入力による上書きを防ぎます。

ブースでは、プレイヤーが選択した直後に結果を認識させます。記録されたルートでは、事務員は「ステーションログに記録しました。エンジニアに通知の要請を依頼できます」と言います。秘密のルートでは、配達員は「エンジニアのために密封したままにしておきます」と言います。どちらの選択でも、配達員が警告を届けられることが明確になるようにします。

最後の2行は同じ最終アクションを使用しています。プレイヤーがストーリーがブースで何が起きたかをまだ記憶していることを確認できるように、異なるエンディング行を与えます。これらの行が同一で終わる場合、冒頭の選択は桟橋で利用可能なものを変えるだけで、引き渡し自体からは消えてしまいます。

1つの共有シーンで以前の選択を読み取らせます

両方のルートで同じ桟橋、エンジニア、カメラ設定を維持します。警告が記録されていた場合、エンジニアは「事務員から伝書の話を聞きました」と言い、プレイヤーは公開通知を依頼するか、伝書を手渡せます。密封されていた場合、エンジニアは「それが私のための伝書ですか？封印はまだ無事です」と言います。プレイヤーはそれを手渡せます。最初のバージョンでは、このルートではメニューから通知アクションを除外します。

メニューを表示する際だけでなく、プレイヤーが通知アクションを試みる際にも保存された値を確認します。キーボードショートカットや古い選択が、欠陥のあるビルドでアクションハンドラーに到達する可能性があります。記録されていない伝書の場合、シーンを変更したりエンディングを選択したりせずに、要請を拒否します。

AIに構築できるルートマトリクスを与えます

SEELEは、書かれたアイデアからゲームプロジェクトを開始することをサポートしています。最初のリクエストでは、キャラクター、選択、状態、エンディングを一緒に説明します。ルートをチェックしている間は、プレーンなシーンやプレースホルダーのプロップスを使用します。各レスポンスが意図されたパスに表示されたら、対話を修正できます。

Last Ferry Dispatchという短いブラウザナラティブプロトタイプを作成してください。
3人のオリジナルキャラクターを使用してください：配達員、事務員、ドックエンジニア。
2つのシーンを使用してください：港湾ステーションのブース、通知ハンドセットがある桟橋。
配達員には、損傷した着陸地点に関する密封された伝書があります。
dispatchLoggedが未設定の状態でブースから開始します。
「警告を記録する」と「密封したままにする」を提供します。記録するとdispatchLoggedがtrueに設定されます。
密封したままにするとfalseに設定されます。最初の有効化が受理された時点で、値を保存し、繰り返しクリックやキー入力から選択をロックし、その認識を表示して、同じ桟橋シーンへ移動します。このランで値を保持します。
桟橋では、trueの場合、エンジニアは事務員のログに言及し、「公開通知を依頼する」または「伝書を手渡す」を提供します。falseの場合、エンジニアは無事の封印に言及し、「伝書を手渡す」のみを提供します。
通知の有効化は別途ガードします。記録された警告がない場合の通知要請は、ストーリー状態やシーンに何も行いません。
記録済み + 通知はPublic Noticeで終わります。記録済み + 引き渡しはLogged Handoffで終わります。密封済み + 引き渡しはQuiet Handoffで終わります。各エンディングの異なる結果を短い行で表示し、Restartアクションを提供します。
ポインターまたはキーボードでプレイヤーが有効化できる説明的なテキストを持つボタンを使用します。Restartは状態をクリアし、どちらの選択もコミットされていない状態で冒頭のブースに戻ります。このバージョンは3つのエンディングに限定してください。

まずブースとその2つの認識を作成します。次に、桟橋が同じ変数を読み取って、挨拶、メニュー、エンディングを生成するようにします。エンディングが誤っている場合、行った2つの選択と実際に確認した行を報告します。ブリーフからプレイ可能へのテストガイドは、そのような観察をより小さな修正リクエストに変換する方法を示しています。

完全なルートとその壊れ方を確認します

ルートテーブルの各行を新しいランから開始します。エンディングを選ぶ前に、桟橋の挨拶とアクションを確認します。挨拶が正しいが誤ったオプションが表示される場合、メニューが保存された選択を読み取る方法を検査します。両方が誤っている場合、初期選択がいつ保存されたか、および桟橋がそれをリセットするかどうかを確認します。

理由を示してロックされた通知を表示しようと試みる

秘密のルートで通知を要請する方法がなかった理由を知りたい人がいると仮定します。ストーリーのルールとエンディングは固定したままにします。秘密の桟橋シーンで、画面に残る文の横に無効化された通知アクションを表示します。「通知を要請するには、事務員が警告を記録する必要があります。」オプションにホバーせずに説明が読めるようにします。

同じ開始状態から2つのバージョンを比較します。修正されたバージョンでは、引き渡しを行う前に理由を探し、ポインターとキーボードで通知を有効化しようと試みます。メッセージは前提条件を明確にしつつ、ガードがまだアクションをブロックしている必要があります。その後、記録されたルートを再生して、そこで通知がまだ機能することを確認します。これにより、プレイヤーが理解できるものの变化と、ストーリーが許可するものの变化を分離できます。

よくある質問

最初のナラティブプロトタイプには何本の分岐が必要ですか？

1つの冒頭の選択から始め、別の選択を追加する前に、到達可能な各エンディングを書き留めます。両方が共有シーンに到達でき、少なくとも1つが異なるアクションにつながる場合、2つの冒頭ルートで十分です。各新しい結果がストーリーに何を追加できるかを説明できる場合に拡張します。

共有シーンは以前の選択をどのように記憶できますか？

最初のシーンを離れる前に、選択を明示的な値に保存します。2番目のシーンが開くときと、プレイヤーがアクションを有効化するとき、その値を読み取ります。表示される対話とは別に保ち、行の編集がルートのルールを静かに変更しないようにします。

利用できないアクションは表示されたままにすべきですか？

プレイヤーが何を逃したかを理解する必要がある場合、理由とともに無効化して表示します。アクションの公開が後のルートをネタバレしたり、現在のシーンから注意をそらしたりする場合、非表示にします。どちらのバージョンでも、利用できないアクションが実行されるのを防ぐルールを維持します。

ストーリーがリスタートする際に何をリセットすべきですか？

以前の選択、エンディング、メニューによって保持された選択をクリアします。元の両方のオプションが利用可能な状態で冒頭のシーンに戻ります。逆のルートを連続で実行した後のリスタートをテストします。新しいロードからルートが正しく見えるように見えても、以前のエンディングから状態を引き継いでいる可能性があります。

プレイヤーに記憶させたい選択から始めます

冒頭の決定によって後で何が変化するかについて1文を書きます。SEELE AI Cinematic Interactive Story Generatorで、それを短いシーンプロンプトに変換します。最初のプロトタイプは、手動で追跡できるほど小さく保ちます。状態を名乗れ、共有シーンで読み取れ、意図した3つのエンディングすべてに到達できるなら、より大きなストーリーの出発点を持っています。