航路と市場がつながる探索交易ループを設計する

ルートと市場から始める

探索交易ゲームは、プレイヤーが「どのルートを開くか」「何を持ち帰るか」「売るたびに市場価格が十分残るか」という3つの判断をつなげると計画しやすくなります。まず短い航海を1回作ります。航路を図示し、燃料を使って発見地点へ進み、決まった積荷を調査し、市場へ向かい、行動上限までに交易します。ルート、積荷、燃料、需要を同じループに関係させます。

Moonwake Reachは独自の架空の学習用デザインです。場所、商品、価格、ルールは創作です。ゲーム生成プロンプトは実行していません。Codex ImageGenのプロンプトはコンセプト画像の作成だけに使用しました。プレイ可能なビルド、ゲームテスト、測定した反復もありません。航路の計算は記載した仕様からの手計算で、観察結果ではありません。

• Start with a route and a market
• Write the voyage state
• Compare two discovery routes
• Trace the trade action
• Simulate one rule revision
• Build an acceptance checklist

島を増やす前に状態を書く

行き先が多い地図は探索的に見えても、航海で何が変わるか分かりにくいことがあります。小さな台帳に収まる有限状態から始めます。この例では航海開始時、Anchor Harbor、クレジット0、燃料3、2枠の積荷は空、需要指数2、残り行動5です。Moon Marketは既知ですが、海図にはまだ2つの発見ルートがありません。

プレイヤーは行動1回を使って海図を開きます。この行動で2つの航路計画、各区間の燃料費、Moon Marketで見える需要の合図が明らかになります。その後、片方の計画を選びます。Sail行動1回で海図に出た区間を1つ進み、行動1回と表示された燃料を消費します。必要燃料が残量を超える区間は選べず、状態は変化しません。この例ではルートはランダムにならないため、出航前に比較できます。

Surveyも行動1回を使います。場所ごとに決まった積荷を1度だけ受け取り、全量が船倉に収まる場合に限ります。Route AのTideleaf箱2つは2枠を使います。Route BのStormglass箱1つは1枠。航海中の補給、保管場所への移送、需要の持ち越しは最初の範囲に含めません。システムを減らすことでルート、積荷、市場判断のつながりを監査しやすくします。

交易ルールでは品の価格を「基本価値＋現在の需要指数」とします。売った品ごとに需要を1下げて最低0とし、次の品の価格を計算する前に更新します。練習航海ごとに需要は2へ戻ります。これは意図して決めたゲーム設定で、現実の市場の事実ではありません。

燃料と積荷の収益でルートを選ぶ

Route AはAnchor HarborからEelgrass Shoalまで燃料1、その後Moon Marketまでさらに1。Eelgrassを調査すると基本価値が各1クレジットのTideleaf箱を2つ得ます。船倉は満杯になりますが、届けた時点で燃料が1残ります。Route BはBasalt Shelfまで燃料2、市場まで1。固定のStormglass積荷は基本価値4の箱1つ。船倉は余りますが、燃料の予備は残りません。

どちらの航海も、海図、最初の航行、調査、次の航行、交易が各1行動なので5行動の予定に収まります。ルート選択は「基本価値が最も高い方を取る」だけではありません。Route Aは燃料2を使い、複数商品の価格再計算が生じます。Route Bは予備燃料を使い切って基本価値の高い箱を運びます。手計算で取引条件は見えますが、プレイヤーがどちらを好むか、バランスが良いかは分かりません。

絵やコードを依頼する前にルートと積荷を見えるようにします。実用的な航路図には港、2つの発見地点、市場、区間ごとの費用、各場所の積荷を表示します。出航前に2区間目の費用が見えないなら、リスクは選択ではなく隠されています。

需要変化の中で調査、運搬、交易を行う

同じ箱が2つあるRoute Aなら、1品ごとの価格ルールを確認しやすくなります。海図で行動1、Eelgrassへの航行で行動2と燃料は3から2へ、Surveyで行動3となりTideleafを2箱積みます。Moon Marketへの航行が行動4で燃料は1。Tradeは行動5ですが、固定された順番で2回価格を計算します。

Route Aの最終状態はクレジット5、燃料1、2枠の船倉は空、需要0、場所はMoon Market。例の目標である「行動5回以内に全積荷を届け、クレジット5以上で終える」を満たします。

Route Bは対照例になります。海図の後、Basaltへ燃料2を使って航行し燃料1が残ります。SurveyでStormglassを1箱積み、最後に燃料1を使ってMoon Marketへ着くため予備は0。箱は基本価値4＋需要2＝6クレジットで売れ、需要は1へ下がります。5クレジットの目標は達成しますが燃料0で終わります。これは別の資源バランスで、Route Bが優れている証拠ではありません。

ここでは1回の行動で両方の箱を売りますが、価格は異なります。市場は1箱目を支払い、需要を更新してから次を計算します。画面に最終合計しか出ないと、どのルールが結果を生んだか分かりません。残った箱、変化した需要表示、最初の支払いを同時に示します。

古い一括見積りを修正する

小さな反復なら、タイミングの曖昧さを1つに絞れます。不完全な架空のv0では、Trade開始時の需要をスナップショットし、同じ値をその一括取引の全品に使います。Route AのTideleafは各1＋2＝3、合計6クレジットです。取引後に需要は2から0へ下がりますが、2箱目の価格は古い需要で計算されます。

v1ではルート、積荷、行動数、基本価値、開始・終了需要は変えません。Trade内の順だけを変えます。現在の需要で品1つを価格計算して支払い、需要を減らしてから次を計算します。同じ箱2つは3と2クレジット、合計5です。差は1クレジットで、どちらの版も需要0で終わります。

これは架空の手計算で、実際のテストや測定した改善ではありません。将来のビルドで確認する点は限定的です。最初のTideleafを売った後、次の商品は需要1で計算されるか。ビルドや観察がなければ、状態は「合格」ではなく「未実施」です。

航路と市場の仕様を確認する

島、嵐、アップグレード、ランダム積荷を追加する前に、例を観察できるチェックへ変えます。短い一覧でルールの誤りと表示上の問題を区別できます。

1. Chart reveals both route branches, each printed leg cost, and the Moon Market demand signal before the player commits.
2. Route A spends one fuel on each leg and ends with one; Route B spends two then one and ends with zero. An unaffordable leg changes neither location nor fuel.
3. Survey can happen once at the chosen site. Eelgrass gives exactly two Tideleaf if both slots are open; Basalt gives one Stormglass. A cache that does not fit is unavailable without partial cargo.
4. A fresh practice run starts at demand two. Route A's first Tideleaf pays three, demand becomes one, the second pays two, and demand becomes zero. Route B's Stormglass pays six, leaving demand one.
5. Trade is one action even when it sells two crates. Both routes reach Moon Market and complete the stated objective on action five.
6. The result screen shows credits, fuel, empty cargo, demand, location, and completion together. The screen reports the designed state without claiming the route has been tested.

これらは提案する受け入れ確認項目にすぎません。記事にはビルドログ、動作中の試作からのスクリーンショット、プレイヤー観察はありません。試作ができたら入力と開始状態を記録し、期待値と実測値を比べ、未確認のケースは未検証とします。紙上の追跡が整合しているからといって未観察の仕組みが動くとは推測しません。

ルート概要を制作フローへ持ち込む

最初の制作依頼には対象プレイヤー、形式、最初の行動、航路図、資源、積荷、市場の順序、成功条件を書きます。小さく遊べる範囲と見える状態表示を依頼し、嵐、継続経済、追加目的地は最初の段階から外します。出力後、各状態遷移を文章の仕様と照合します。

現在のSEELE公式Free AI Game Makerページは、平易な言葉でゲームを依頼し、プレイ可能な2Dまたは3Dの結果を確認し、ブラウザーで試し、追加プロンプトで改善し、生成コストを確認する一般的な流れを紹介します。これらは制作と確認の手順で、Moonwake Reachや需要ルールが生成された保証ではありません。送信前にWorkspaceで選択モデル、利用可能なKoin、表示コストを確認します。

自分の探索交易ゲームを始める

プレイヤーが運べる物を変えるルート選択を1つ作り、プレイヤーが計算できるルールで市場を反応させます。地図、行動数、資源、成功条件を見える状態にします。紙上の追跡を将来の試作目標にし、実際に観察した結果だけを報告します。自分の航路概要ができたら、Free AIゲームメーカーを開いて最初の方向性を探し、遊べる出力と現在の費用を確認します。

よくある質問

探索交易のループは地図ツアーとどう違いますか？

地図ツアーは場所を見せますが、交易ループでは発見が資源判断を変えます。この例では行き先で積荷が決まり、限られた船倉に収め、ルートで燃料を消費し、品を1つ売るたび次の価格が変わります。後の選択に影響しない目的地は、ループの一部でなく飾りかもしれません。

燃料を使う長いルートに価値があるかどう判断しますか？

選択前に区間ごとの費用と目的地の固定積荷を書きます。市場到着時の燃料、積載量、基本価値、需要、行動数を比較します。Moonwake ReachではBasaltは6クレジットを生みますが燃料を3すべて使い、Eelgrassは5を生んで1残します。この架空の数字は取引条件を見せるだけで、プレイヤーの好みを知るには将来のビルドかテストが必要です。

需要は一括取引の後と商品ごとのどちらで変えるべきですか？

順序を1つ選び明記します。各販売で次の品の価格が変わるなら、現在の需要で1品を計算して支払い、需要を更新して続けます。例のv0は一括販売全体で開始時需要を固定します。v1はそのタイミングだけを変えるため、ルート、積荷、基本価格を変えずに1クレジット差を追えます。

船倉が満杯、または燃料不足のルートではどうなりますか？

効果を適用する前に行動が有効かを決めます。この例では燃料不足のSailを拒否し、移動も燃料消費も起こしません。積荷全体が船倉に入らない場合は、Surveyもできません。品を黙って落としたり売ったりしません。部分積載を許す別のゲームでは、明確なルールと確認が必要です。

Moonwake Reachは制作またはテストされましたか？

いいえ。Moonwake Reachは架空のデザインで、行動の追跡は本文のルールから手計算しました。ゲーム生成プロンプトは実行していません。Codex ImageGenのプロンプトはコンセプト画像の作成だけに使いました。ゲーム制作プロンプトとチェックリストは未実行で、プレイ可能なビルドや測定結果はありません。各確認項目は実際のビルドで観察し、証拠を記録するまで保留です。