AI 放置ゲームに信頼できるセーブとオフライン進捗を追加する

動作するゲームの流れから始め、進捗の信頼性を高める

放置ゲームに必要なのは、ページを開いている間に増えるカウンターだけではありません。プレイヤーは、購入したアップグレードが更新後も残り、再訪時に妥当な進捗が得られ、その後のアップデートで積み重ねた成果が消えないことを期待します。セーブ、オフライン精算、互換性を別々の動作として扱い、それぞれを確認します。

このワークフローは説明用の温室デザインの続きであり、既存の生成・テスト済みプロジェクトではありません。クリックすると架空のコインを獲得し、購入した庭師は一人につき毎秒一枚のコインを生産します。次の庭師の価格は ceil(10 × 1.15^n) で、n はすでに雇った人数です。動作する獲得と購入の流れから始めてください。ローカルストレージとクラウドセーブを混同せずに、セーブの契約を定義し、上限付きの復帰報酬を計算し、後の一つの変更でも進捗を保ちます。

ゲームが記憶すべき内容を定める

コードを依頼する前にセーブの契約を書きます。最小構成には、スキーマのバージョン、現在のコイン残高、庭師の人数、購入済みアップグレード、収益をすでに精算した時刻までを含めます。生産速度のルールはアップグレードの定義と一緒に保管してください。表示残高の根拠となる購入情報を保存し、派生した状態の矛盾するコピーを保存しないようにします。

開発中に読みやすいセーブの要約を表示するよう依頼し、ゲームの状態と保存された状態を比較できるようにします。診断出力に個人情報を出さないでください。またローカルセーブとアカウントに基づくセーブを区別します。ブラウザストレージはブラウザのプロファイルに属し、消去されることがあります。端末間での進捗共有、安全な競争用残高、プレイヤーがサイトデータを削除した後の復旧を保証するものではありません。

次の範囲を絞った依頼を使います。

コイン、庭師、購入済みアップグレード、最後に精算した時刻について、バージョン管理されたローカルセーブを追加してください。プレイ可能な画面を表示する前に状態を復元します。読み込んだ値を検証してください。セーブがなければ新しいゲームを開始します。セーブが無効な場合は、不可能な残高を黙って生成せず、復旧時の挙動を説明してください。既存のアートと獲得ルールは変更しないでください。

重要な購入の後に保存し、ゲームに必要なら定期的な保存も定義します。ページを閉じるイベントだけに依存してはいけません。ブラウザや端末は、期待した最後のイベントを送らずに停止することがあります。

明確な上限を設け、離席中の報酬を一度だけ計算する

オフライン進捗は通常、プレイヤーが戻ったときに報酬を計算することを意味します。ブラウザを閉じた後もゲームのスクリプトを動かし続ける必要はありません。分かりやすいルールは次のとおりです。

報酬 = 対象となる保存済み生産速度 × min(max(復帰時刻 − 最後の精算時刻, 0), 8時間)

実装前に、対象となる速度の意味を決めます。この単純な設計では、離席時に保存された庭師とアップグレードによる生産速度です。基本の精算が動くまで、複雑なシミュレーションは後回しにします。

期待値の確認として、毎秒一枚ずつ生産する庭師二人なら、条件を制御した十分間でコイン1,200枚を得ます。この例の上限では、十時間離れても八時間分だけを使います。計算結果を実行ログの期待値として使ってください。

進捗を付与した後、更新によって同じ離席時間に再び報酬を与えないよう、ゲームは精算状態を更新しなければなりません。計算に使った時間と付与された報酬を示す復帰メッセージを依頼します。常時稼働するサーバーを暗示せず、計算された報酬として説明してください。

計算例：オフライン報酬

これらの例では固定の生産速度と架空のコインを想定し、明記した場合は上限を二時間とします。期待される計算であり、テスト済みゲームの測定結果ではありません。

セーブと時間の精算を別々にテストする

まず把握できる残高を獲得し、庭師を一人購入してページを更新します。残高と購入が残ることを確認してください。次にブラウザを閉じ、時間を測って待ってから戻ります。開始状態、実際の経過時間、観察した報酬、最終状態を記録します。すぐに更新し、同じ報酬が繰り返されないか確認してください。

長い時間の確認には制御可能なテスト時計を使い、通常の流れでは実際に閉じて戻るテストを行います。負の経過時間、現実的でないほど長い時間、空のセーブ、破損したセーブをテストしてください。結果を見る前に、それぞれどう動くべきかを明記します。負の時間によって獲得済みの通貨を差し引いてはいけません。長い時間によって上限を回避できてもいけません。

端末のローカル時刻はプレイヤーが変更できます。経過時間を範囲内に制限すれば明らかなエラーを防ぐ助けになりますが、ローカルな経済が改ざんに強くなるわけではありません。競争用または有料の経済には、別途、権威ある精算とセキュリティの設計が必要です。

再訪時のテスト表

プレイヤーをリセットせずに後のアップグレードを行う

セーブが動いたら、小さな内容変更を依頼します。

今後の購入について、庭師の基本価格をコイン十枚から八枚に変更し、成長係数 1.15 を維持してください。既存のコイン、庭師、所持アップグレード、見た目、オフライン精算を保持します。現在のセーブデータのバージョンに対応してください。新しい状態に追加フィールドが必要な場合は、古いセーブをどう移行するか示してください。

この依頼をする前に、変更前の実際のセーブと動作するビルドを保存します。そのセーブを変更後の版に読み込み、結果の残高、購入、生産速度を比較してください。新しいフィールドを加えたとき、古いセーブにそのフィールドがないというだけで全状態を破棄してはいけません。経済を変える前に、過去の購入の恩恵を維持するか決めます。

アップグレードが消える場合は、機能を追加する前に移行と読み込みを調べます。新しいボタンはセーブの互換性の証拠ではありません。

永続化の限定的な変更に SEELE を使う

SEELE は、ゲームを作成し、その後の変更を依頼するプロンプト主導のワークフローを提供しています。ここで重要な入力は、動作する経済と具体的なセーブ契約です。望ましい出力は、読み込みと精算の挙動を検査できる変更候補です。移行や新しいアップグレードを依頼する前に、最小限の永続化の変更を依頼してください。

動作するビルドと基準セーブを、評価対象の変更とは別に保管します。確認が失敗したら、読み込み、復帰、購入のどこで問題が起きたかを含め、正確な状態の差を報告してください。製品の説明だけでは、クラウドセーブ、安全な時計、移行の保証、特定のローカルストレージ実装の信頼性は証明できません。

再訪時の結果を理解できてから先に進む

信頼できる放置ゲームは、数値の由来を説明できる必要があります。何が報酬を生み、どの離席時間が数えられ、どの購入が維持されているかです。AI の支援を使ってこれらのルールを範囲を絞って変更し、実行中のゲームで各変更を判断してください。動作するセーブを犠牲にして機能一覧を増やしてはいけません。

SEELE を使い、既存のプロジェクトにローカルセーブ一つと上限付きの復帰報酬一つを依頼します。経済に別の変更を依頼する前に、動作が分かっている版を保存してください。次の到達点は、より大きな約束ではなく、プレイヤーの以前の進捗が保たれた再訪を検証することです。

よくある質問

オフライン進捗は、ブラウザを閉じている間もゲームが動くということですか？

必ずしもそうではありません。一般的な方法は状態と精算時刻を保存し、次回の訪問時に報酬を計算することです。これならブラウザのプロセスを常時動かさずにオフライン報酬を設計できます。説明する前に実際の実装を確認してください。サーバー側のシミュレーションは別のアーキテクチャであり、ローカルで計算された報酬からその存在を暗示してはいけません。

ブラウザのセーブは別の端末に移りますか？

移ると決めつけてはいけません。ブラウザのローカルストレージは通常、そのブラウザプロファイルとサイトのストレージに結びついています。端末間のセーブには、明示的な同期またはアカウントシステムに加え、競合処理とプライバシーに関する判断が必要です。ローカル永続化の例をクラウドセーブ機能として示すのではなく、テストしたデモが実際に何を使うかを読者に伝えてください。

プレイヤーがすでに遊んだ後でもアップグレード価格を変更できますか？

はい。変更後の設計で既存の購入と保存状態をどう扱うかを定義している場合は可能です。基準セーブを保存し、どの恩恵を維持するか決め、変更のリリース前に移行をテストします。価格表を上書きするだけでは、古い進捗が有効なままとは証明できません。挙動がまだ未テストの場合は、成功した更新ではなく要件として説明してください。