ベーカリー経営ゲームが面白くなるのは、プレイヤーが1日の展開を正確に知らずにバッチを確定させなければならないときです。焼きすぎると顧客が空手では帰ってしまい、焼きすぎると材料が売れ残ります。最初はオーブン1台、商品1種類、短い1日分から始めましょう。これらの判断が機能するようになったら、レシピや不確実性を追加します。
このガイドでは、架空のベーカリーを用いて、1日のループをどのように仕様化するか、AIゲーム作成ツールにどのように初期案を依頼するか、そして結果が自分のルールに従っているかをどのように確認するかを示します。数値は完成したゲームの結果ではなく、例示のための設計選択です。
プレイヤーに意味のある朝の判断を1つ与える
1日の開始時に、プレイヤーが焼くパンの個数を選べるようにします。オーブンの容量と材料の在庫がバッチを制限します。その後、顧客が来店し、在庫がある限り購入し、在庫が尽きると去ります。売上、残ったパン、現金の増減のサマリーで1日を締めくくり、プレイヤーが新しい1日をスタートできるようにします。
| ルール | 最初のバージョン | 生み出される判断 |
|---|---|---|
| オーブンの容量 | バッチあたり8個 | 見える制限内で選択する |
| 材料 | 12ポーション利用可能 | リソースを確保または使用する |
| 需要 | 顧客6名、各1個 | バッチと予想売上を比較する |
| 1日の終了 | 売れたパンと売れ残ったパンを表示 | フィードバックを使って次の判断を変える |
最初のビルドを確認する際は、需要を固定に保ちます。予測可能な入力により、予期しない結果が自分の設計から来ているのか、実装エラーから来ているのかを区別しやすくなります。ランダムな需要は、後で選択をより不確実なものにできます。
構築前に1日分をシミュレーションする
この例では、パン1個につき材料1ポーション（1コイン）を消費します。1個の売上は3コインです。計算を明確にするため、当面は家賃、人件費、その他のコストは無視します。バッチ8個には材料8ポーションが必要です。6人の顧客がそれぞれ1個ずつ購入した場合、売上は18コイン、材料費は8コイン、簡略化された利益は10コインになります。2個のパンが売れ残ります。
バッチ6個の場合、同じ6件の売上は18コインになり、材料費は6コインなので、利益は12コインで売れ残りはゼロになります。これは6個が普遍的な最適解であることを意味しません。あくまで仮定された固定需要に適合しているだけです。需要が変動すると、大きなバッチは混雑した日に売上の機会損失を防ぐ一方で、閑散とした日に廃棄のリスクを負うことになります。
| バッチ | 需要6個での販売数 | 売れ残り | 売上から材料費を引いた額 |
|---|---|---|---|
| 8個 | 6個 | 2個 | 10コイン |
| 6個 | 6個 | 0個 | 12コイン |
プロンプトを書く前に、売れ残りについてどう扱うかを決めます。最初のバージョンでは、閉店時に廃棄しても構いません。翌日に持ち越す場合は、鮮度と、明日の顧客が新鮮なパンの前にそれを買うかどうかを定義します。どちらの選択でも機能しますが、1日終了時の計算はそれに一致しなければなりません。
ルールをAIへのビルド依頼に変換する
状態、アクション、終了条件をまとめて記述します。SEELEのゲーム作成機能は、記述から始めるよう設計されており、その2Dアセットワークショップは、キャラクター、シーン、インターフェース要素を共通のスタイルでカバーします。これらのカテゴリを使ってプロジェクトを枠組みし、その後、ツールが実際に作成したものを確認します。プロンプトは完成したゲームの保証ではなく、テストするための仕様です。
ブラウザ用のオリジナルの小さなベーカリー経営ゲームを作成してください。
各日の開始時、12ポーションの材料を表示し、0から8個までのバッチを許可します。各パンは1ポーションを消費し、1コインのコストがかかります。
焼成後、6人の顧客が1人ずつ来店します。パンが残っていれば、各顧客が3コインで1個を購入します。そうでない場合は、機会損失1件を記録します。
閉店時、焼いたパン、売れたパン、売れ残ったパン、機会損失、材料費、売上、売上から材料費を引いた額を表示します。売れ残ったパンは廃棄します。
同じ初期リソースで新しい1日を始めるためのボタンを提供します。
オリジナルの温かみのあるイラストのベーカリーと、明確で読みやすいコントロールを使用してください。
当面は、家賃、人件費、追加レシピ、ランダムな需要は導入しないでください。最初の試行が多すぎようとする場合は、まず1日の計算を、次にイラスト付きのシーンを依頼してください。別のシステムを追加する前に、動作しているバージョンのコピーを保持してください。修正を依頼する際は、アシスタントにゲームを「より現実的に」するよう求めるのではなく、初期状態、アクション、期待される結果を提供してください。
会計とリセットを確認する
- 8個を選択：例のルールに基づき、6個販売、2個売れ残り、機会損失ゼロ、利益10コインを期待します。
- 4個を選択：4個販売、2件の機会損失、利益8コインを期待します。在庫がゼロになった後、顧客がパンを購入すべきではありません。
- 0と8を試した後、許可された範囲外の数値を選択しようとします。ゲームはバッチを指定された制限内に保つべきです。
- 新しい1日をスタートし、在庫、顧客数、サマリーが指定通りリセットされることを確認します。前日の売れ残ったパンが再出現してはなりません。
サマリーが異なる場合、最初に誤った状態変化を特定します。例えば、8個のパンを焼いたのに材料費が6個分しか計上されていない場合、パンが焼かれた時点で材料費を記録するよう依頼します。これは売れ残ったパンも含みます。変更後、8個と4個の両方のチェックを繰り返します。
仮想的な1回の反復を計画する
固定された1日が機能するようになったら、設計変更を検討します：顧客4名の閑散日と顧客8名の混雑日を交互にします。1日のタイプは、プレイヤーがバッチを選んだ後にのみ明らかにします。これは提案されたルールであり、テストされたビルドについての主張ではありません。バッチ4個は閑散日に売れ残りを避けますが、混雑日に4件の潜在的な売上を逃します。バッチ8個は混雑日の需要を満たしますが、閑散日に4個のパンが残ります。
アシスタントに、閉店サマリーで各日のタイプを表示し、以前の会計チェックを保持するよう依頼します。選択が恣意的に感じられる場合は、有用だが不完全な情報を与える予測を追加し、それが信頼できるものとして呼ばれる前に、それがどのように生成されるかを正確に指定します。目標は、プレイヤーが情報を解釈することであり、単純な選択をより多くのコントロールの下に埋もれさせることではありません。
よくある質問
最初のバージョンには何種類のレシピが必要ですか？
ループをテストするには1種類のレシピで十分です。焼成、販売、1日の終了が一貫して機能するようになったら、2種類目を追加します。新しいレシピには、長いオーブン時間や異なる材料などの異なる制約を与え、追加された選択がプレイヤーの計画を変えるようにします。
顧客の需要は最初からランダムにするべきですか？
すべてのテストの期待される結果を予測できるように、固定の数値から始めます。その後、明確に定義された範囲やシーケンスで変動を導入します。既知の状況を再生する方法を保持してください。そうしないと、顧客数の変化が会計のバグを隠す可能性があります。
ゲームを苛立たしくせずに、売れ残りに意味を持たせるにはどうすればいいですか？
1日を締めくくる前に、コストと在庫の結果を表示し、プレイヤーが次のバッチを調整できるようにします。後で、寄付や値引き販売を明示的なルールとして実験します。各オプションが売上や他のリソースをどのように変化させるかを説明し、プレイヤーが知るはずがなかった情報に対して罰を与えないようにします。
生成されたゲームがルールを無視した場合、どうすればいいですか？
ツールに再現可能な1つの例を与えます：初期の材料、バッチサイズ、購入者数、期待されるサマリー。他のルールを変更せずに、特定の計算を修正するよう依頼します。同じ例をもう一度実行し、その後、2番目のバッチサイズとリセットを確認します。
オーブン1台と1日から始める
明確な生産制限と、見える1日終了時の結果があれば、最初の経営判断を作成するのに十分です。例の数値を使ってルールを確認し、その後、需要、レシピ、情報を変更して、ベーカリーを自分だけのものにしていきます。SEELE AI Creator Game Makerで簡潔な記述から始め、上記のチェックに対して結果を改善します。より広範なウォークスルーについては、AIでゲームを作る方法をご覧ください。
