資源ループを確認できる仕様にする

宇宙コロニーゲームのAIプロンプトは、短い生存・生産ループを1つから始めると確認しやすくなります。資源、行動コスト、タイミング、勝利条件を先に定め、状態を期待追跡と比べられる小さなプレイ可能シーンを求めます。この記事では再利用できる未実行のプロンプトひな形3つと、手計算した架空例「Kestrel Relay Shift」を紹介します。数値はゲーム単位で、工学データではありません。プロンプトは実行しておらず、ビルドやプレイテストも報告していません。追跡表は将来ビルド向けの紙上受け入れ目標で、既存ビルドの証拠ではありません。

世界を頼む前にコロニーの範囲を決める

前哨基地1つ、資源3種、目標1つから始めます。Kestrel Relay Shiftではプレイヤーが空気、バッテリー、氷を3シフト管理し、その後通信ビーコンを組み立てます。これで「最終シフト終了前に空気を0より上に保ち、必要な材料を集め、組み立てコストを払えるか」という具体的な設計上の問いが作れます。

最初の依頼は意図的に小さくします。研究ツリー、歩き回る乗員、ランダム嵐、複数居住区、近隣地点のマップはそれぞれ状態を増やし、不一致の説明を難しくします。初版には見える採氷装置、空気フィルター、ビーコン組立地点、コンパクトな居住区だけが必要です。1画面で目標を理解でき、資源バーから各行動の影響を判断できます。

これはデザイン目標の画面です。オペレーターが採掘を選び、最大2枠の作業命令の1枠が埋まり、空気とバッテリーは3のまま氷が0から1になります。役立つシーンプロンプトでは「現実的な月面基地」と頼むだけでなく、この状態遷移を名指しします。次の判断も分かります。氷をさらに集める、後で空気を濾過する、作業枠を温存する。

シーンを頼む前にルールを書く

部屋やアートの生成を頼む前に簡潔な仕様を作ります。各資源の初期値と上限、行動コスト、変化、受動効果のタイミング、失敗判定を定めます。注文に必要なコストが足りない場合、一部効果なしで拒否するかを指定します。これらの詳細がないと、実装上重要な選択が暗黙のままになります。

NASA ECLSS概要では実際の生命維持機能を説明しています。これはテーマ用の用語情報で、架空メーターやルールの裏づけではありません。

この参照表は例のタイミングと混同せず「命令は何をするか」に答えます。濾過を拒否した場合は何も変わらず、払える資源だけ消費して他方が足りず失敗することはありません。小さな一文でよくある解釈の食い違いを防ぎます。

完全なターン順は、シフトの太陽光増加を適用し、作業命令を最大2つ提示し、選んだ命令を次の選択前に解決してから、プレイヤーが選んだ時にシフトを終了します。シフト終了はシフト開始時でも、完了した任意の命令後でも選べ、作業命令枠を使いません。シフト3の終了時、ビーコンが組立済みで空気1以上なら勝利です。この教材仕様に隠れイベントやランダムロールはありません。

3シフトのシナリオを手計算で追う

プロンプトに合法なルート1つと否定確認1つがあると評価しやすくなります。下の表には選んだ行動後と各シフトの空気減少後の状態を記録しています。バッテリーと氷には上限があるため、期待状態を上記ルールから再現できます。

第1シフトは作業命令2つ、最後は1つです。2は最大値で必須数ではないため、最後の行動後にシフト終了を選べます。否定確認も有用です。初期状態で濾過を選んだ場合、氷0なので拒否し、空気3、バッテリー2、氷0を変えないようにします。

このメカニズム画面はシフト2で濾過が解決した直後の状態です。資源変化で行動が単に「よい」「悪い」でないと分かります。空気を2増やしますが、バッテリーと氷を1ずつ使います。次の採掘で最終組立に必要な氷が戻ります。将来の試作はフィルターアニメーションが説得力あるかだけでなく、遷移と照合します。

役割ごとに3つのプロンプトを使う

長いプロンプト1つにルール創作、シーン演出、全実装、自己採点をまとめて依頼しないでください。各出力に明確な受け入れ確認があるよう仕事を分けます。以下は架空仕様で使えるひな形です。すべて未実行で、例の出力は手作業で定めた期待値で、モデルの返答ではありません。

テンプレートA：ルールを確定する

「Kestrel Relay Shift」というコンパクトな宇宙コロニーゲームの仕様を設計する。
この架空状態だけを使う：空気3/6、バッテリー2/4、氷0/3、ビーコン未組立。シフト3回、1シフトの作業命令は最大2つ。
作業命令前にシフト1と3だけバッテリーを1増加、上限4。
採掘は命令1枠を使い氷を1増やす。上限3。
濾過は氷1とバッテリー1を使い、その後空気を2増やす。上限6。どちらかのコスト不足なら状態変化なしで拒否。
ビーコン組立は氷2とバッテリー1を使い、1度だけ組立済みにする。繰り返せない。
シフト終了は作業命令ではない。プレイヤーが選ぶと空気を1下げる。空気0で即敗北。シフト3の後、ビーコン組立済みかつ空気1以上の場合だけ勝利。
状態表、行動表、ターン順、矛盾または曖昧さを返す。嵐、追加資源、建物、行動を創作しない。

期待出力は開始状態、上限、行動コスト、太陽光タイミング、シフト終了時点、終了条件が保たれた簡潔な仕様です。数値の変更、命令2つを必須とすること、行動前の空気減少、濾過費用の一部だけ差し引くことがなければ受け入れます。追加仕組みが出たら、基準へ黙って足さず依頼から取り除きます。

テンプレートB：プレイ可能なシーンを1つ依頼する

承認済みのKestrel Relay Shiftルールを使い、新しいルールセットでなく、小さなプレイ可能コロニーシーンを指定する。
[承認済みルール仕様をここに貼る]
宇宙服のオペレーター、居住区、採氷装置、空気フィルター操作盤、ビーコン組立地点をコンパクトな前哨基地1つに配置する。読みやすい三人称カメラと状態表示1画面を使う。
シフト1の太陽光増加後から開始：空気3/6、バッテリー3/4、氷0/3。プレイヤーが採掘を選ぶ。氷が1/3になり、作業命令の最大2枠のうち1つが埋まり、他資源は変わらないように示す。
シーン説明、見える操作、前後状態、次の選択肢を返す。UIラベルを最小限にし、システムを追加しない。

期待出力は選んだ装置、採掘行動、氷0→1が特定できる画面規模のシーンです。資源値を保ち、すぐ結果を表示し、別の命令またはシフト終了を選べる場合に受け入れます。操作対象が隠れる美しい風景だけでも、プレイ空間のない状態パネルだけでも不十分です。

テンプレートC：固定追跡を検証する

以下の期待追跡とKestrel Relay Shiftルール仕様を照合する。
[承認済みルール仕様をここに貼る]
シフト1後の期待値：空気2、バッテリー3、氷2、ビーコン未組立。
シフト2後の期待値：空気3、バッテリー2、氷2、ビーコン未組立。
シフト3後の期待値：空気2、バッテリー2、氷0、ビーコン組立済み。勝利。
初期状態（空気3、バッテリー2、氷0）で濾過も試す。状態変化なしで拒否すること。
各遷移を入力状態、命令、コスト、出力状態、合否で返す。ルールと期待値が合わなければ、最初の不一致を特定し、どちらを正とするか質問する。仕様を黙って書き換えない。

期待出力は行ごとの比較と初期濾過拒否です。各コストが1回だけ適用され、空気が指定時点だけ減り、最初の不一致を上書きせず名指しする場合に受け入れます。このひな形を後で実ビルドに使うなら、実際の状態を加えます。それまでは「期待値」は手計算で、観測値ではありません。

ひな形は順に使います。仕様を固定し、その中で1つのシーンを求め、追跡を比較します。プロンプトを移る際はルール文を同一に保ちます。コストを変えたら先に期待状態を更新します。後の比較が変動する目標でなく、ルール1つの変更を測れるようになります。

結果画面は紙上の合格条件を示します。マストが点灯し、オペレーターは作業枠1つを使い、資源値は追跡表の最後と一致します。将来のシーンプロンプト向けの視覚目標であり、生成ビルドがこの状態に達した証拠ではありません。

ゲーム全体でなく最初の不一致を調べる

将来のビルドが紙上追跡と異なれば、最初に違う状態で止めます。行動、前後資源、シフト番号、太陽光またはシフト終了が解決済みか記録します。その遷移に関係するルールだけを直します。「もっとうまく動くように」と全プロンプトを繰り返すと無関係な挙動をいくつも変え、次の結果を比較しにくくなります。

この診断表は症状を最初に確認するルールへ対応づけます。実ビルドでは画面または構造化した前後ログを保存し、ビルド版を記載します。この記事の手計算例には比較対象の観測ビルドはありません。手法を完成して見せるために作り出さないでください。

制作ワークフローへ仕様を渡す

ルールと期待状態を書いた後、誰が行動し、プレイヤーが何をして、何が変わり、結果で何を示すかを短いゲーム案にします。現在のFree AI Game Makerページでは、平易な英語入力、プレイ可能な2D/3D初版、ブラウザーテスト、追加プロンプトによる改良を説明しています。これは一般的なワークフローの説明で、Kestrelの厳密なルール順守を保証しません。

小さな初回制作では、読みやすい命令1つと直ちに見える状態反応を求めます。実際に表示されたものを確認し、仕様と比較してから焦点を絞った修正を1つ頼むか決めます。送信前にWorkspaceで選択モデル、利用可能なKoin残高、表示生成コストを確認します。記事の追跡は確認目標の準備で、結果確認の代わりにはなりません。

Free AIゲームメーカー

確認できるルールから始める

役立つ宇宙コロニーのプロンプトは、範囲の限定されたループ、正確な資源コスト、ターンタイミング、合格条件から始めます。仕様を書き、シーンを1つ頼み、将来の状態を手計算追跡と比較します。不一致があれば最初のルールを直し、同じ順を再実行します。Kestrelは架空の紙上例ですが、コロニーシステムを増やす前に実際の次期試作を明確な目標にできます。

よくある質問

最初の宇宙コロニーゲームのプロンプトには何を含めますか？

目標1つ、開始状態、資源上限、合法行動、正確なコストと効果、行動順、ターン終了時の圧力、勝敗条件を含めます。期待するルートと拒否操作確認も1つずつ加えます。遷移を調べやすくなるまで他システムを外しておきます。

AIツールはプレイ可能なKestrelゲームを生成しましたか？

いいえ。Kestrelは独自の架空ルール検討例で、3シフトのルートは手計算しました。この記事のプロンプトは未実行のひな形です。生成ビルド、プレイ可能な結果、プレイテスト、観測されたプレイヤー行動は主張していません。

ルール、シーン、検証プロンプトを分ける理由は何ですか？

各プロンプトに1つの役割を与えます。ルール用はコストとタイミングを明確化、シーン用は制約内の見える操作を求め、検証用は期待状態を比較します。問題がルールの曖昧さ、読みづらいシーン、追跡の不一致のどこから来たか見つけやすくなります。

濾過に必要な資源が足りないとどうなりますか？

記載したKestrelルールでは、氷1とバッテリー1が両方ある場合だけ濾過できます。拒否しても部分変化はなく、空気、バッテリー、氷は元の値を保ちます。これは架空デザインの選択で、ビルダーに推測させずプロンプトへ直接書く必要があります。

コロニーのプロンプトが大きすぎるとどう分かりますか？

レビュー担当者が現在状態、利用可能な行動、1回の行動後の期待結果を言えないなら、最初の依頼にシステムを入れすぎています。1画面と短い追跡で中心ループが説明できるまで仕組みを減らし、明確になってから追加します。