AIで修理ショップシミュレーターを作る方法

修理ショップシミュレーターでは、作業台をスケジューリングパズルにすることができます。2人の顧客が対応を必要としているかもしれませんが、限られた部品の供給と利用可能な作業スロットが1つしかないため、プレイヤーは順序を選ぶことを強いられることになります。複雑な経済システムや数十台のデバイスを追加する前に、短いキューと見える締切から始めましょう。

このガイドは、AI支援のプロトタイプ向けの架空のゲームデザインについて説明しています。デバイス、部品、価格、検査結果は簡略化されたゲームルールであり、実際の機器の修理手順やテスト済みゲームからの観察ではありません。

プレイヤーに競合する2つのジョブを与える

1日目の開始時、ラジオと時計がショップで待機しています。スクリプトによる検査により、各ジョブには汎用交換モジュールが1つずつ必要であることが判明します。プレイヤーにはモジュールが1つと、1日間に1つのジョブを完了できる作業台があります。ラジオのジョブは、未完了の場合、1日目の終了時に期限切れになります。一方、時計は2日目まで利用可能です。

この例では、検査はゲームフラグを明らかにしますが、実際のラジオや時計をどのように診断すべきかを確立するものではありません。決定はキューの順序に関するものです。プレイヤーが作業台をコミットする前に、部品の要件と締切を表示してください。

2つのスケジュールを比較する

20コインとモジュール1つから始めます。プレイヤーが1日目にラジオを完了した場合、ショップは30コインを受取ります。2日目の開始時、プレイヤーは10コインで追加のモジュールを1つ購入し、時計を完了して50を得ることができます。最終残高は20 + 30 − 10 + 50 = 90コインで、他のコストはモデル化されていません。

プレイヤーが最初に時計を完了した場合、ショップは50コインを受取り、1日目を70で終了します。未完了のラジオはその日の終了時に期限切れになるため、この例では2番目のジョブはなく、別のモジュールを購入する必要もありません。2日間のラジオ優先パスは20多くコインを生み出しますが、作業台をもう1日占有します。そのトレードオフは、発明されたルールの結果であり、実際の修理ショップの収益に関する主張ではありません。

エラーを強制するためにだけラジオの締切を隠さないでください。有用な計画決定は、プレイヤーが結果を比較するために必要な情報を提供しながら、追加の1日が価値があるかどうかを決定することを依然として要求します。

AIビルドリクエストでキューを指定する

ジョブの状態、在庫の変化、締切のタイミング、支払いを別々に説明してください。SEELEの機能カタログは、書かれたアイデアからゲームを開始し、調整された2Dキャラクター、シーン、インターフェース要素を生成することを説明しています。これらの広範なカテゴリは、この特定のキューやショップが生成・テストされたことを確立するものではありません。

オリジナルの小型修理ショップ管理ゲームを作成してください。
1日目は20コイン、汎用モジュール1つ、ラジオと時計の2つのジョブで開始します。
スクリプトによる検査により、各ジョブにはモジュール1つと作業台キャパシティ1日が必要であることが判明します。ラジオは30を支払いますが、未完了の場合、1日目の終了時に期限切れになります。時計は50を支払いますが、2日目の終了まで利用可能です。
1日につき最大1つのジョブのみを選択可能にし、その検査後かつ利用可能でモジュールが在庫にある場合のみ許可します。1日を完了すると、モジュールを消費し、選択されたジョブに一度だけ支払いを行い、締切が過ぎた未完了ジョブを期限切れにします。無効な作業に対しては支払いや部品の消費を行わないでください。
2日目の開始時、プレイヤーが支払える場合、作業選択前に10コインで追加のモジュールを1つ購入できるようにします。他のコストはモデル化されていません。
日数、現金、在庫、キュー、締切、ジョブの状態を表示します。キューが空になるか、2日目が閉じるまで終了します。リスタートすると、1日目、現金、在庫、ジョブが復元されます。
ブランドや実際の修理手順のない、オリジナルのイラスト付きオブジェクトを使用してください。

ツールアニメーションを追加する前に、キューと日次遷移を構築してください。各段階後に動作するバージョンを保持します：まず検査と選択、次に部品の消費と支払い、そして期限切れとリスタート。ジョブが2回支払いされる場合、そのジョブの状態と、それを引き起こした正確なクリックのシーケンスを提供してください。

利用できないジョブと在庫を可視化する

各ジョブが検査待ち、準備完了、選択済み、完了、期限切れのいずれかであるかを表示します。選択されたジョブは、その日の唯一の作業台スロットを予約します。ゲームは、なぜ同時に別のジョブを選択できないかを説明する必要があります。利用可能なモジュールの数をキューの横に表示し、プレイヤーがジョブを開始できない理由を見られるようにします。

プレイヤーが1日を閉じる前にキャンセルした場合に何が起きるかを定義してください。単純な最初のルールは、モジュールを消費したり報酬を支払ったりせずに、作業台の選択を解放することです。1日が閉じられた後、完了したジョブは完了したまま残り、再び選択することはできません。

両方のスケジュールと締切を確認する

1. 初期状態：1日目、20コイン、モジュール1つ、利用可能な未検査ジョブ2つを確認します。
2. ラジオ優先：ラジオを検査して選択し、1日目を閉じます。50コイン、モジュール0、完了したラジオを期待します。2日目の開始時に10でモジュールを購入し、時計を完了して90コインを期待します。
3. 時計優先：リスタートし、1日目に時計を検査して完了します。70コインと、締切後の期限切れのラジオを期待します。ラジオは2日目には選択可能であってはなりません。
4. 制限：1日に2つのジョブを選択したり、モジュールなしでジョブを完了しようとしたりします。どちらも追加の支払いを生んだり、存在しない部品を消費したりしてはいけません。
5. 繰り返しとリセット：完了した日を2回閉じて、支払いが1回であることを確認します。リスタートし、初期の現金、在庫、ジョブの利用可能性、日数を確認します。

チェックが失敗した場合、開始状態、アクション、期待される結果を報告してください。例：「時計は1日目に完了し、ラジオの締切が過ぎました。ラジオは2日目にも選択可能のままです。1日を閉じた後、未完了の期限切れジョブを利用不可にマークしてください。」期限切れの修正後、完了したラジオが期限切れにマークされないように、ラジオ優先パスを再確認してください。

部品とキューのイテレーションを計画する

仮想的な次のバージョンとして、異なる架空の部品を必要とするランプのジョブを追加します。明示的な締切、コスト、支払いを与え、両方の部品タイプを別々に表示します。これにより、新しい質問が生まれる可能性があります：プレイヤーがランプの部品に現金を使うべきか、それとも時計のモジュールのために保持すべきか。

ルートを比較する前に、部品の購入が作業スロットを使用するかどうか、新しい部品がいつ利用可能になるか、部品が欠けているジョブに何が起きるかを決定してください。ランプを完了しても、ラジオと時計のモジュールを消費しないことをテストします。これは提案された拡張であり、テスト済みプロトタイプからの測定結果ではありません。

よくある質問

ジョブの順序を重要にするにはどうすればいいですか？

プレイヤーが見える制約、例えば異なる締切、報酬、部品の要件をジョブに与えます。例では、ラジオはより早く期限切れになりますが、時計はより多く支払います。プレイヤーが即座の報酬と両方のジョブを完了する機会を比較できるように、これらのルールを一貫して保ちます。

すべてのジョブに異なる部品を使うべきですか？

最初はそうではありません。1つの共有架空モジュールは、2つのジョブ間で在庫制約を検証しやすくします。有用な購入や割り当ての選択を生み出すときに異なる部品を追加し、どのジョブにどの部品が必要かを表示し、在庫が正しいアイテムから控除されることをテストします。

締切が過ぎた場合はどうなりますか？

例では、未完了のラジオは1日目が閉じられたときに期限切れになり、後で選択することはできません。完了したジョブは完了したままです。その変化をキューに表示します。後でペナルティや延長を設計する場合、そのタイミングを定義し、別々にテストします。

重複した支払いを防ぐにはどうすればいいですか？

利用可能な選択済みジョブが完了に遷移したときのみ支払いを行い、その遷移を処理済みとしてマークします。繰り返しのクローズやクリックでは再び支払いを行わないでください。正規の完了、2回目のクリック、期限切れのジョブ、リスタートをテストし、セーフガードが正当な最初の支払いをブロックしないことを確認します。

まず1つの意味のあるキューを構築する

2つのジョブ、1つの作業スロット、希少な部品があれば、修理ショップの計画ループを作成するのに十分です。より多くのデバイスを追加する前に、検査、選択、在庫、締切を検証します。SEELE AI Creator Game Makerで独自のショップを開発し、キューに明確な影響を与える部品や顧客を追加します。より広いワークフローについては、AIでゲームを作る方法をお読みください。