Roblox オフライン進行スキル

Roblox オフライン進行スキル は何をしますか？

目的

このスキルは、Robloxの信頼性の高いプレイヤーデータシステムと、ゲームから離れている時間に基づく進行計算を構築・レビューするために使用します。アーキテクチャ、実装、テスト、運用、リカバリを網羅します。これはAIエージェントのためのガイダンスであり、デプロイされた永続化フレームワークではありません。

トリガー条件

以下のタスクが関係する場合にこのスキルを使用します：

• プレイヤーデータの保存、読み込み、リセット、マイグレーション、復元、または検査
• DataStoreService、標準DataStore、OrderedDataStore、MemoryStoreService、Open Cloud DataStore、Creator Hub Data Stores Manager
• プレイヤープロファイル、通貨、インベントリ、ペット、アップグレード、区画、作物、機械、ジェネレーター、リーダーボード、永続設定
• セッション所有権、セッションロック、自動保存、リトライ、リクエスト予算、スロットリング、PlayerRemoving、BindToClose
• オフライン収益、アイドル収入、農業タイマー、生産、クールダウン、再接続後の進行
• データ損失、古い書き込み、重複報酬、破損レコード、購入レシート、スキーママイグレーション

UI、マップ、アニメーション、戦闘、または永続プレイヤーデータに触れない一般的なゲームプレイタスクではこのスキルを使用しないでください。

コアとなる事実

1. DataStoreServiceは永続的なRobloxクラウドストレージを提供します。サーバーコードからアクセスされ、Robloxサービスへの接続が必要です。
2. Creator Hub Data Stores Managerは、データを表示および管理するためのダッシュボードです。LuaUサービスやランタイムデータベースAPIではありません。
3. MemoryStoreServiceは一時的なクロスサーバーデータを提供します。エントリは期限切れになり、永続的なプレイヤープロファイルストアではありません。
4. OrderedDataStoreは順序付けられた数値（一般的に永続的なリーダーボードスコア）のためのもので、完全なプレイヤープロファイルではありません。
5. サーバーメモリはアクティブなサーバーの揮発性作業コピーです。保存が成功する前にプロセスが終了すると失われる可能性があります。
6. オフライン進行は通常、プレイヤーが戻った後にサーバーが計算するバウンデッドなキャッチアップを意味します。アクティブなサーバーなしでプライベートワールドがシミュレーションを続けることを意味するものではありません。
7. 完全に切断されたクライアントはRobloxクラウドDataStoreに書き込めません。通常の公開Roblox体験が接続なしでプレイとクラウド保存を続けられることを約束しないでください。
8. DataStoreServiceの呼び出しはサーバースクリプトまたはサーバースクリプトからrequireされるModuleScriptに属します。LocalScriptから正規のデータを保存しないでください。
9. UpdateAsyncは読み取り-変更-書き込み操作です。それ自体でセッションロックを実装するわけではありません。
10. 成功したリクエストは、返されたプロファイルが構造的に有効であることや現在のスキーマと互換性があることを証明しません。
11. ロードの失敗は、キーがないことや新しいプレイヤーと同等ではありません。
12. 対象の体験が実際にStudioで実行されていない限り、コードがRoblox Studioでテストされたと主張しないでください。

必須ワークフロー

1. 編集前に検査する

実際の体験、ファイル、スクリプト、ModuleScript、リモート、パッケージ、利用可能なStudio統合を検査します。

以下を特定します：

• すべてのDataStore名、スコープ、キービルダー、キープレフィックス、ストアアダプター
• すべてのGetAsync、SetAsync、UpdateAsync、IncrementAsync、RemoveAsync、バージョン、リスト呼び出し
• PlayerAdded、PlayerRemoving、BindToClose、自動保存タスク、購入レシートハンドラー、各プロファイルキーのすべての書き込み
• 現在のスキーマ、デフォルトテンプレート、マイグレーションバージョン、プロファイルが書き込み可能になる正確なポイント
• プロジェクトがネイティブDataStoreService、サードパーティプロファイルライブラリ、カスタムラッパーのどれを使用しているか
• 現在のプロファイル所有権、リトライ、同一キーの順序付け、シャットダウンの処理方法
• ユーザーが「オフライン」で意味すること：離脱時間のキャッチアップ、一時的なサービス停止、モックテスト、または完全に切断されたプレイ

スクリーンショット、リポジトリ名、またはいくつかの孤立したコード断片からアーキテクチャを推測しないでください。変更する具体的な理由を示す証拠がない限り、動作しているシステムを維持してください。

2. Robloxの動作を確認する

references/official-roblox-sources.mdをソースインデックスとして使用します。コーディング前に、APIシグネチャ、クォータ、サービス動作、設定、非推奨について現在のRoblox Creator Hubドキュメントを再確認してください。

エンジンの保証についてはRobloxドキュメントを使用してください。サードパーティパッケージについては、対象プロジェクトにインストールされている正確なバージョンを検査し、そのパッケージ独自のAPIを確認してください。記憶や古いサンプルからライブラリメソッドをでっち上げないでください。

3. 要件に応じてストレージを選択する

要件	正しい開始点
耐久性のあるプレイヤー進行	DataStoreService経由の標準DataStore、またはメンテナンスされたプロファイルレイヤー
永続的な数値ランキング	OrderedDataStore
一時的な共有クロスサーバー状態	MemoryStoreService
現在のサーバーのライブプロファイル	サーバーメモリ
保存されたエントリの検査または復元	Creator Hub Data Stores ManagerとバージョンAPI
外部管理	信頼されたバックエンド経由のOpen Cloud
離脱時間の進行	永続プロファイルとサーバー側キャッチアップ計算
完全な切断型スタンドアロンプレイ	通常のRobloxクラウドDataStoreでは提供されない

プロファイルが収まり、そのフィールドに一貫性のある更新が必要な場合は、1つの安定したUserIdベースのプロファイルキーを優先してください。実際のサイズ、スループット、またはアクセスパターンの理由がある場合にのみ分割してください。プレイヤーごとにDataStoreを作成しないでください。

4. プロファイルを安全にロードし所有する

プロファイルは、選択したアーキテクチャの下で、成功したロードと排他的所有権の後にのみ書き込み可能になります。

1. サーバーがPlayerAddedを受信したときにロードを開始します。
2. 既存の永続化レイヤーを使用してプロファイル/セッションロックを取得します。
3. 有効な「キーなし」の結果を、ネットワーク障害、スロットリング、セッション競合、不正な形式のデータ、サポートされていないスキーマと区別します。
4. ペイロードを検証し、順序付けられた決定論的なマイグレーションを適用します。
5. 必要なすべての手順が成功した後にのみ、プロファイルを準備完了として公開します。
6. サーバーのゲームプレイが、制御されたメソッドを通じてサーバー所有の作業コピーを変更できるようにします。
7. プロファイルライブラリが所有権が終了したことを報告した場合、すぐに変更を停止します。

一時的なロード障害の後、書き込み可能なデフォルトプロファイルを作成しないでください。これにより、戻ってきたプレイヤーの実際のデータが上書きされる可能性があります。

5. 順序付けとバウンデッドリトライで保存する

• ネットワーク呼び出しはpcallまたはプロジェクトの確立されたエラーレイヤーで処理します。
• 一時的なエラーのみをリトライし、バウンデッドな指数バックオフとランダムジッターを使用します。
• 無効な引数や永続的な障害を永久にリトライしないでください。
• キーごとに書き込みをシリアル化します。古い遅延リトライが新しい成功した保存を上書きしてはいけません。
• リトライ可能な操作は冪等になるように設計します。なぜなら、失敗した応答により書き込み結果が不確実になる可能性があるからです。
• 新しい値が現在の保存状態に依存する場合、または同時書き込みが可能な場合はUpdateAsyncを使用します。
• SetAsyncは、排他的所有権と置換セマンティクスが確立されている場合の意図的な値全体の置換に有効です。普遍的に禁止されているわけではありません。
• UpdateAsyncのトランスフォームコールバックは決定論的で、yieldせず、外部副作用がないようにしてください。コールバック内でwait、HTTP呼び出し、リモート呼び出し、レシート許可、分析、Instance作成を決して実行しないでください。
• UpdateAsyncトランスフォームからのnil返り値は書き込みをキャンセルします。
• 現在のリクエスト予算とスロットル動作を監視します。UpdateAsyncは読み取り予算と書き込み予算の両方を消費します。
• 自動保存を分散させます。毎フレーム保存したり、小さなゲームプレイイベントごとに保存したりしないでください。

6. オフライン進行を正しく実装する

オフライン報酬システムを構築する前に、references/offline-progression.mdとexamples/offline-progress.luauを読んでください。

サーバーは以下を行う必要があります：

1. プロファイルをロードして検証する。
2. 排他的なセッション所有権を確認する。
3. 保存されたタイムスタンプとサーバー所有の生産入力を読み取る。
4. 現在のサーバー側エポック時間を取得する。
5. 非負の経過時間を計算し、設定された最大値にクランプする。
6. 検証された所有権とサーバー側定義から生産レートを導出する。
7. 設定されたオフライン効率、資格、報酬キャップを適用する。
8. 報酬とそれに対応するシミュレーションタイムスタンプをプロファイル作業コピー内で一緒に更新する。
9. アクティブなプロファイルレイヤーを通じて永続化する。
10. プレゼンテーションデータをクライアントにレプリケートする。

クロスセッション計算にはos.time()または別の文書化されたサーバー側エポックタイムスタンプを使用します。os.clock()をエポックタイムスタンプとして使用しないでください。クライアントクロック、経過時間、生産レート、作物ステージ、アセットリスト、最終請求タイムスタンプを決して信頼しないでください。

同じインターバルを2回付与しないでください。オンライン生産を二重カウントしないでください。オフラインの1秒ごとに1回のアンバウンデッドループを実行しないでください。欠落、不正な形式、ゼロ、負、未来のタイムスタンプを意図的に処理してください。

7. 開発データと本番データを保護する

• ライブDataStore統合テストには、別の公開開発用またはステージング用の体験を使用します。
• Studio Access to API Servicesは、その隔離されたテスト体験でのみ有効にします。
• Robloxは、Studioがライブアプリケーションと同じDataStoreにアクセスできることを警告しています。ルーチンテストのために本番環境でこの設定を有効にしないでください。
• 決定論的なロジックテストにはモックまたはインメモリアダプターを使用します。モックは実際のプレイヤーセーブではなく、耐久性のあるストレージでもありません。
• 使い捨てアカウントとテストキーを使用します。
• 明示的なオペレーター承認、正確なターゲット特定、リカバリ計画なしに、本番データを削除、復元、名前変更、上書きしないでください。
• Open Cloudクレデンシャルは信頼されたバックエンドに保管してください。LocalScript、クライアント、公開リポジトリ、プロンプトコンテキストでそれらを公開しないでください。

8. 正直に検証して報告する

references/test-matrix.mdを使用します。初回および帰還プロファイル、ロード失敗、競合、古い所有者、書き込み順序、リトライ、自動保存、シャットダウン、クラッシュリカバリ、不正な形式のペイロード、マイグレーション、オフラインキャップ、繰り返し請求、重複レシートをカバーします。

検証レベルを正確に報告します：

• 静的レビュー
• 純粋なユニットテスト
• モック/インメモリ統合テスト
• 公開ステージングDataStoreテスト
• Roblox Studioランタイムテスト
• マルチサーバー/セッション競合テスト

これらは異なるチェックです。Studioまたはステージングが利用できなかった場合は、ランタイム検証が未完了であることを明記してください。

非妥協禁止事項

• LocalScriptから正規のプレイヤーデータを保存しないでください。
• クライアントから提供されたUserId、残高、価格、インベントリ、所有権、報酬レート、タイムスタンプ、経過時間、購入結果を信頼しないでください。
• 一時的なロードエラーを新しいプレイヤーとして扱わないでください。
• MemoryStoreServiceまたはサーバーRAMを永続的なプロファイルストレージとして使用しないでください。
• 新しい体験にDataStore2を使用しないでください。Robloxは現在これをレガシーライブラリとして識別しています。
• UpdateAsyncコールバックでyieldしたり、副作用を実行したりしないでください。
• 同一キーの書き込みとリトライが競合することを許可しないでください。
• 通常のリトライとしてアクティブセッションを強制的に奪わないでください。
• プロファイルライブラリによって管理されているキーに生の値を書き込まないでください。
• UpdateAsyncだけでセッションロックを実装すると主張しないでください。
• アンバウンデッドなオフラインシミュレーションループを実行しないでください。
• Open Cloud secretsを公開しないでください。
• 明示的な承認とリカバリ計画なしに本番データを破壊的に変更しないでください。
• 行われていないStudioテストを主張しないでください。

リファレンスマップ

現在のタスクに必要なドキュメントのみをロードします：

• references/architecture-and-services.md: サービスの役割、DataStore Manager、Open Cloud、ストレージ選択
• references/player-data-lifecycle.md: プロファイルライフサイクル、インメモリ作業コピー、準備完了、退出、シャットダウン
• references/session-locking-and-failures.md: セッション所有権、UpdateAsync、書き込み順序、リトライ、スロットリング、未知の結果
• references/offline-progression.md: アイドル報酬、作物タイマー、ジェネレーター、タイムスタンプ計算、キャップ、切断制限
• references/studio-testing.md: APIアクセス、ステージング、モック、安全なテスト分離
• references/schema-migrations-and-recovery.md: シリアル化、スキーマバージョン、マイグレーション、バージョン履歴、リカバリ
• references/security-and-purchases.md: リモート、サーバー権限、レシート、Open Cloud secrets、データプライバシー
• references/performance-and-limits.md: 文書化された制限、予算、スループット、運用チューニング
• references/library-selection.md: ネイティブDataStoreService、公式リファレンスコード、サードパーティパッケージ評価
• references/game-patterns.md: プロファイル、リーダーボード、区画、アイドルシステム、トレーディング、購入
• references/test-matrix.md: 検証シナリオ
• references/official-roblox-sources.md: Roblox Creator Hubソースリンクのみ
• examples/profile-template.luau: 例示的なプロファイル形状
• examples/offline-progress.luau: 純粋なバウンデッドオフライン報酬計算

必須実装応答

実装およびデバッグタスクの場合：

1. 実際のプロジェクトで見つかった既存のアーキテクチャを要約します。
2. 意図されたデータフローと最小限の安全な変更を説明します。
3. 作成または変更する正確なファイルをリストします。
4. 断片的な断片ではなく、完全でコンテキストを認識したコードを提供します。
5. セットアップ、ステージング、およびスキーママイグレーションの手順を説明します。
6. 実際のテストと残りのランタイムチェックを報告します。
7. 保証をでっち上げることなく、重要な制限とリスクを述べます。

ユーザーの要求する言語とスタイルを尊重します。動作しているシステムを維持します。無関係な機能を追加したり、スタイル上の理由で既存の永続化ライブラリを置き換えたりしないでください。