世界を説明する前にコロニーの判断を選ぶ

世界を説明する前にコロニーの判断を選ぶ

コロニー運営プロンプトには、建物や資源の一覧だけでなく結果を伴う選択が必要です。別の選択と競合する行動を一つ、コストと出力の解決時点、存続と完了の条件を書きます。最初の試作では、住民に物資を届けながら別目標を進める計画ができるか、一つの問いに答えます。

Dayglass Outpostはプロンプト構成を説明する架空の地表コロニーです。夜明けごとにプレイヤーは2ユニットのバッテリーを水耕栽培室か中継マストに使います。室は食料を作り、中継は信号を進めます。以下の3日例は手計算です。プロンプトは実行されておらず、生成またはテスト済みビルドもありません。

最初の判断は状態から次の状態へ追える小ささにします。何を犠牲にしたか分からないまま住民、研究ツリー、天候を増やすと、プロンプトの確認は有用になるどころか難しくなります。

追加システムを頼む前に状態契約を書く

各数値にフェーズと各行動に上限があると、プロンプトは実装しやすくなります。Dayglassでは夜明けにバッテリーが戻り、手動で選ぶモジュール一つに全量を使います。選んだモジュールの後で食料を確認します。この順序で、食料が少ない日に中継を選ぶ安全性が決まります。

この表は短いジャンルプロンプトでは残る穴を埋めます。電力が戻る時点、行動を分割できるか、完了後に中継を再度使えるか、食料確認が消費の前か後かを定義します。変更するなら先に契約を直し、例を再計算します。

機能を増やす前に3日分を手計算する

コロニーの生成を頼む前に、提案ルールで経路を追います。算数で勝利条件の矛盾や意図しない近道を見つけられ、アート、住民、資源追加で診断が難しくなるのを避けられます。

結果は契約に書いた順序に依存します。モジュール出力は夕暮れより前です。もし配給後に水耕栽培するなら2日目の状態は異なります。別経路では水耕栽培の後、中継を2回使い、同じルールで3回の確認に食料が足ります。一方、1日目の選択後に2日目も中継を繰り返すと夕暮れ前の食料は0となり、在庫を減らす前に失敗します。

これはバランステストではなく手計算の説明例です。将来のビルドで使う期待状態の参照として保ち、ルールが実装された証拠にはしません。

過剰な一つの依頼ではなく、プロンプトを三つに分ける

ルールの明確化、実装、修正を分けます。各依頼を見直しやすくし、シーンを広げる前に矛盾を見つけられます。以下は架空設計用にすぐ試せるプロンプトですが、実行していません。

プロンプト1：ルールシートを依頼する

このコロニー案を簡潔なルール契約にしてください。新システムは追加しないでください。
開始状態：1日目夜明け、住民3、食料3、信号0/2、バッテリー2ユニット。
各夜明けにバッテリーを2へ戻します。プレイヤーは手動行動を正確に一つ選び、2ユニット全部を使います。Hydroponicsは食料を6追加。Relayは信号2/2未満の間だけ信号段階を1増やす。選択行動を夕暮れ前に解決します。
夕暮れ時、食料3未満なら食料を減らさず失敗。それ以外は食料3を減らします。3日目の配給後、信号2/2かつ食料確認で失敗していないときだけ成功。再起動で開始状態を完全に復元。
返す内容：(1)状態変数、(2)フェーズ順、(3)有効行動と制限、(4)成功・失敗・再起動ルール、(5)曖昧点または矛盾。
1日目Relay、2日目Hydroponics、3日目Relayを手計算してください。
テスト済みと主張せず、追加イベントを創作しないでください。

続行前に返された契約を元ルールと照合します。配給確認を移動する、未使用バッテリーを持ち越す、隠れた食料費を足す場合は、大きなビルドを依頼せずルールシートを直します。

プロンプト2：最小の試作だけを依頼する

以下のルール契約からDayglass Outpostという小さなシングルプレイヤー地表コロニー試作を作ってください。コンパクトな居住区、水耕栽培室1つ、中継マスト1つ、住民3人、食料庫を表示します。読みやすい経路のトップダウンまたはアイソメトリック運営画面にします。
現在の日数、食料、信号進捗、バッテリー、選択行動、解決結果を表示。プレイヤーは毎日手動でモジュールを一つ選びます。夜明けにバッテリーを2に戻し、どちらのモジュールも2ユニットすべてを消費。Hydroponicsは食料6を追加。Relayは信号が2/2未満の間だけ信号段階を1増やす。モジュールを解決後、夕暮れに食料3以上か確認。不足なら消費前に失敗。それ以外は食料3を減らします。3日目の確認後、信号2/2だけ成功。
再起動で1日目、住民3、食料3、信号0/2、バッテリー2/2へ戻します。
天候、作業員配置、自動化、生物、追加資源、研究ツリー、戦闘、ランダムイベント、マルチプレイヤーを省きます。選択行動の結果をその場に表示。提案デザインとして扱い、テスト結果を報告しないでください。

これは一つの判断と確認に必要な見える状態を依頼します。コロニーの全機能を一度に求めていません。ツールが異なる結果を返したらプロンプトを変える前に実際の出力を記録し、要求した挙動があると思い込まないでください。

ルールが黙って変わりやすい点を確認する

「動きますか？」のような広い質問ではなく、具体的な確認を使います。以下は将来の実ビルド向け計画です。期待結果であり、合格済みテストではありません。

各確認で正確な操作と画面表示を記録します。確認できるビルドがなければ予定チェックリストとして保ちます。表の予測とゲームの実観察は同じではありません。

証拠に基づく修正を一つ依頼する

実際のビルドがルール契約と違う場合、次のプロンプトの目的を絞ります。行った操作、期待、実際に表示された内容を正確に書きます。関係するルールだけ変え、他は保ちます。その後同じ操作順を繰り返します。曖昧な印象に応じてシステムを増やすのではなく、修正を証拠に結び付けます。

現在のビルドで観察した不一致：
操作：[日数とモジュール選択]
期待：[ルール表の状態]
観察：[ビルドで実際に表示されたもの]
この不一致の原因ルールだけを変更してください。他の資源値、行動タイミング、成功・失敗条件、画面要素を維持します。どのルールを変えたか、同じ確認手順を列挙してください。
再度その確認を実行するまで、修正をテスト済みと主張しないでください。

ビルドを実行していない場合、手計算表で「観察」欄を埋めないでください。テンプレートのままにします。経路表は後で比較する材料を示しますが、実際の観察を提供しません。

一般的なゲームメーカーにプロンプトを持ち込む

SEELE公式Free AI Game Makerページは、平易な英語で案を入力し、プレイ可能な2Dまたは3D結果を確認し、Workspaceで反復し、生成前に表示Koin費用とアカウント設定を確認する一般的な流れを説明しています。これらは一般ワークフローの詳細です。Dayglass Outpost、コロニー運営、指定資源ルールの対応を示すものではありません。

ルール契約とチェック表を自分の設計ブリーフとして持ち込みます。現在提供される結果を確認し、見える状態を期待遷移一つと比較して、修正か簡略化を決めます。ページ説明は、この例が生成された証拠にも、すべての要求ルールが一致する証拠にもなりません。

よくある質問

最初のコロニープロンプトにどの仕組みを含めるべきですか？

開始資源、プレイヤー行動一つ、そのコストと出力、行動解決時点、その後の確認条件を含めます。循環を閉じる勝敗と再起動ルールも加えます。作業員、天候、研究、自動化が確認する判断を変えないなら後回しにします。

コロニー試作は何種類の資源で始めるべきですか？

中心の判断を理解するのに必要な資源だけ使います。Dayglassには食料、バッテリー、信号があります。住民への給餌と中継完了のトレードオフが分かるためです。行動選択、生存確認、目標を変えない資源は最初の依頼から省きます。

生産と消費をどう分かりやすく表示しますか？

選択前の状態を表示し、選んだモジュールを解決してから夕暮れ確認と最後の在庫を示します。フェーズを分けると出力が遅すぎたか配給が二重に引かれたか見つけやすくなります。パネルの見た目は変えられますが、確認可能にすべき値はプロンプトで指定します。

配給確認に失敗したらどうなりますか？

プロンプトの前に失敗規則を選びます。この例では食料3未満で、何も消費する前に失敗するため、表示状態がルールと一致します。別のコロニーでは不足や部分配給を許容できますが、それが在庫とラン継続をどう変えるか明記します。

詳しいプロンプトでプレイ可能なコロニー運営ゲームを保証できますか？

いいえ。詳しいプロンプトで要求ルールを確認しやすくできますが、特定ツールが正しく実装する証明にはなりません。実際の結果を調べ、状態遷移を確認し、不一致を記録します。Dayglassの値は説明用の架空例で、テスト済み結果ではありません。

確認可能なコロニー循環を一つ作る

大きなコロニーを頼む前に、判断、タイミング、資源変化、生存確認、完了条件を記述します。経路を一つ手計算し、実際の結果を一つずつ調べ、最初の不一致で範囲を絞った修正を行います。自分の案を試す準備ができたら、無料AIゲームメーカーから始めます。現在表示される費用を確認し、できたビルドの実際の挙動を検証します。