Roblox Offline Skill

Was macht Roblox Offline Skill?

Zweck

Verwenden Sie diesen Skill, um zuverlässige Roblox-Spieler-Datensysteme und Fortschrittsberechnungen für Zeiten außerhalb des Spiels zu erstellen und zu überprüfen. Er umfasst Architektur, Implementierung, Tests, Betrieb und Wiederherstellung. Es handelt sich um eine Anleitung für einen KI-Agenten, nicht um ein bereitgestelltes Persistenz-Framework.

Auslösebedingungen

Verwenden Sie diesen Skill, wenn eine Aufgabe Folgendes betrifft:

• Speichern, Laden, Zurücksetzen, Migrieren, Wiederherstellen oder Überprüfen von Spielerdaten.
• DataStoreService, Standard DataStores, OrderedDataStores, MemoryStoreService, Open Cloud DataStores oder Creator Hub Data Stores Manager.
• Spielerprofile, Währungen, Inventare, Haustiere, Upgrades, Grundstücke, Feldfrüchte, Maschinen, Generatoren, Bestenlisten und persistente Einstellungen.
• Sitzungsbesitz, Sitzungssperren, automatisches Speichern, Wiederholungsversuche, Anforderungsbudgets, Drosselung, PlayerRemoving oder BindToClose.
• Offline-Einnahmen, passive Einkünfte, Landwirtschafts-Timer, Produktion, Abklingzeiten oder Fortschritt nach dem Wiederverbinden.
• Datenverlust, veraltete Schreibvorgänge, doppelte Belohnungen, beschädigte Datensätze, Kaufbelege oder Schema-Migrationen.

Verwenden Sie diesen Skill nicht für unzusammenhängende UI-, Karten-, Animations-, Kampf- oder allgemeine Gameplay-Aufgaben, es sei denn, sie betreffen persistente Spielerdaten.

Kernfakten

1. DataStoreService bietet persistenten Roblox-Cloud-Speicher. Er wird von Servercode verwendet und erfordert eine Verbindung zu den Roblox-Diensten.
2. Creator Hub Data Stores Manager ist ein Dashboard zum Anzeigen und Verwalten von Daten. Es ist kein Luau-Dienst und keine Laufzeitdatenbank-API.
3. MemoryStoreService bietet temporäre serverübergreifende Daten. Einträge laufen ab und es ist kein dauerhafter Spielerprofilspeicher.
4. OrderedDataStore ist für geordnete numerische Werte gedacht, üblicherweise für persistente Bestenlistenpunkte. Es ist kein vollständiges Spielerprofil.
5. Der Serverspeicher ist die flüchtige Arbeitskopie des aktiven Servers. Er kann verloren gehen, wenn der Prozess vor einem erfolgreichen Speichern beendet wird.
6. Offline-Fortschritt bedeutet normalerweise eine begrenzte Aufholjagd, die vom Server berechnet wird, nachdem ein Spieler zurückkehrt. Es bedeutet nicht, dass eine private Welt ohne aktiven Server weiter simuliert wird.
7. Ein vollständig getrennter Client kann keine Roblox-Cloud-DataStores beschreiben. Versprechen Sie nicht, dass eine normale veröffentlichte Roblox-Erfahrung ohne Konnektivität weiterspielen und in der Cloud speichern kann.
8. DataStoreService-Aufrufe gehören in Server-Scripts oder ModuleScripts, die von Server-Scripts benötigt werden. Speichern Sie niemals kanonische Daten von einem LocalScript.
9. UpdateAsync ist eine Lese-Ändern-Schreib-Operation. Es implementiert von sich aus keine Sitzungssperre.
10. Eine erfolgreiche Anfrage beweist nicht, dass das zurückgegebene Profil strukturell gültig oder mit dem aktuellen Schema kompatibel ist.
11. Ein fehlgeschlagenes Laden ist nicht gleichbedeutend mit einem fehlenden Schlüssel oder einem neuen Spieler.
12. Behaupten Sie niemals, dass Code in Roblox Studio getestet wurde, es sei denn, die Zielerfahrung wurde tatsächlich in Studio ausgeführt.

Erforderlicher Arbeitsablauf

1. Überprüfen vor dem Bearbeiten

Überprüfen Sie die tatsächliche Erfahrung, Dateien, Skripte, ModuleScripts, Remotes, Pakete und verfügbaren Studio-Integrationen.

Identifizieren Sie:

• Jeden DataStore-Namen, -Bereich, -Schlüsselersteller, -Schlüsselpräfix und -Store-Adapter.
• Alle GetAsync-, SetAsync-, UpdateAsync-, IncrementAsync-, RemoveAsync-, Versions- und Auflistungsaufrufe.
• PlayerAdded, PlayerRemoving, BindToClose, Autosave-Aufgaben, Kaufbeleg-Handler und jeden Schreiber für jeden Profilschlüssel.
• Das aktuelle Schema, die Standardvorlage, die Migrationsversion und den genauen Zeitpunkt, an dem ein Profil beschreibbar wird.
• Ob das Projekt native DataStoreService, eine Drittanbieter-Profilbibliothek oder einen benutzerdefinierten Wrapper verwendet.
• Wie Profilbesitz, Wiederholungsversuche, Same-Key-Reihenfolge und Herunterfahren derzeit gehandhabt werden.
• Was der Benutzer mit offline meint: Abwesenheits-Aufholjagd, vorübergehender Serviceausfall, Mock-Tests oder vollständig getrenntes Spielen.

Leiten Sie die Architektur nicht aus einem Screenshot, einem Repository-Namen oder einigen isolierten Codefragmenten ab. Bewahren Sie ein funktionierendes System, es sei denn, es gibt konkrete Hinweise auf einen Änderungsgrund.

2. Roblox-Verhalten überprüfen

Verwenden Sie references/official-roblox-sources.md als Quellindex. Überprüfen Sie vor dem Programmieren die aktuelle Roblox Creator Hub-Dokumentation auf API-Signaturen, Kontingente, Serviceverhalten, Konfiguration und veraltete Funktionen.

Verwenden Sie die Roblox-Dokumentation für Engine-Garantien. Überprüfen Sie bei Drittanbieterpaketen die genaue Version, die im Zielprojekt installiert ist, und die eigene API dieses Pakets. Erfinden Sie keine Bibliotheksmethoden aus dem Gedächtnis oder von alten Beispielen.

3. Speicher nach Anforderung auswählen

Anforderung	Korrekter Ausgangspunkt
Dauerhafter Spielerfortschritt	Standard DataStore über DataStoreService oder eine gepflegte Profilschicht
Persistente numerische Rangliste	OrderedDataStore
Temporärer gemeinsamer serverübergreifender Zustand	MemoryStoreService
Live-Profil des aktuellen Servers	Serverspeicher
Gespeicherte Einträge überprüfen oder wiederherstellen	Creator Hub Data Stores Manager und Versions-APIs
Externe Verwaltung	Open Cloud über ein vertrauenswürdiges Backend
Fortschritt für Abwesenheitszeit	Persistentes Profil plus serverseitige Aufholberechnung
Vollständig getrenntes eigenständiges Spielen	Nicht von normalen Roblox-Cloud-DataStores bereitgestellt

Bevorzugen Sie einen stabilen UserId-basierten Profilschlüssel, wenn das Profil passt und seine Felder kohärente Aktualisierungen benötigen. Teilen Sie nur aus einem echten Größen-, Durchsatz- oder Zugriffsmustergrund auf. Erstellen Sie keinen DataStore pro Spieler.

4. Profile sicher laden und besitzen

Ein Profil wird erst nach erfolgreichem Laden und exklusivem Besitz unter der ausgewählten Architektur beschreibbar.

1. Beginnen Sie mit dem Laden, wenn der Server PlayerAdded empfängt.
2. Erwerben Sie die Profil-/Sitzungssperre mit der vorhandenen Persistenzschicht.
3. Unterscheiden Sie ein gültiges Fehlschlüssel-Ergebnis von Netzwerkfehlern, Drosselung, Sitzungskonflikten, fehlerhaften Daten und nicht unterstützten Schemata.
4. Validieren Sie die Nutzlast und wenden Sie geordnete, deterministische Migrationen an.
5. Veröffentlichen Sie das Profil erst als bereit, wenn alle erforderlichen Schritte erfolgreich waren.
6. Lassen Sie das Server-Gameplay die servereigene Arbeitskopie durch kontrollierte Methoden ändern.
7. Stoppen Sie Mutationen sofort, wenn die Profilbibliothek meldet, dass der Besitz beendet wurde.

Erstellen Sie niemals ein beschreibbares Standardprofil nach einem vorübergehenden Ladefehler. Dies könnte die echten Daten eines zurückkehrenden Spielers überschreiben.

5. Mit Ordnung und begrenzten Wiederholungen speichern

• Behandeln Sie Netzwerkaufrufe mit pcall oder der etablierten Fehlerschicht des Projekts.
• Wiederholen Sie nur vorübergehende Fehler mit begrenztem exponentiellem Backoff und zufälligem Jitter.
• Wiederholen Sie ungültige Argumente oder dauerhafte Fehler nicht endlos.
• Serialisieren Sie Schreibvorgänge pro Schlüssel. Eine alte verzögerte Wiederholung darf keinen neueren erfolgreichen Speichervorgang überschreiben.
• Entwerfen Sie wiederholbare Operationen als idempotent, da eine fehlgeschlagene Antwort den Schreibausgang ungewiss lassen kann.
• Verwenden Sie UpdateAsync, wenn der neue Wert vom aktuellen gespeicherten Zustand abhängt oder gleichzeitige Schreibvorgänge möglich sind.
• SetAsync ist gültig für absichtliche vollständige Werteersetzung, wenn exklusiver Besitz und Ersetzungssemantik etabliert sind. Rufen Sie es nicht universell verboten auf.
• Halten Sie UpdateAsync-Transformationsrückrufe deterministisch, nicht nachgebend und frei von externen Seiteneffekten. Führen Sie niemals Wartezeiten, HTTP-Aufrufe, Remote-Aufrufe, Quittungsgewährungen, Analysen oder Instanzerstellungen innerhalb des Rückrufs durch.
• Eine nil-Rückgabe von einem UpdateAsync-Transformationsrückruf bricht den Schreibvorgang ab.
• Beachten Sie die aktuellen Anforderungsbudgets und das Drosselungsverhalten. UpdateAsync verbraucht sowohl Lese- als auch Schreibbudget.
• Staffeln Sie automatische Speicherungen. Speichern Sie nicht jeden Frame oder bei jedem winzigen Gameplay-Ereignis.

6. Offline-Fortschritt korrekt implementieren

Lesen Sie references/offline-progression.md und examples/offline-progress.luau, bevor Sie ein Offline-Belohnungssystem erstellen.

Der Server muss:

1. Das Profil laden und validieren.
2. Exklusiven Sitzungsbesitz bestätigen.
3. Gespeicherte Zeitstempel und servereigene Produktionseingaben lesen.
4. Aktuelle serverseitige Epochenzeit abrufen.
5. Nicht-negative verstrichene Zeit berechnen und auf ein konfiguriertes Maximum begrenzen.
6. Produktionsraten aus validiertem Besitz und serverseitigen Definitionen ableiten.
7. Konfigurierte Offline-Effizienz, -Berechtigung und -Belohnungsobergrenzen anwenden.
8. Die Belohnung und den entsprechenden Simulationszeitstempel zusammen in der Profilarbeitskopie aktualisieren.
9. Durch die aktive Profilschicht persistieren.
10. Präsentationsdaten an den Client replizieren.

Verwenden Sie os.time() oder einen anderen dokumentierten serverseitigen Epochenzeitstempel für sitzungsübergreifende Berechnungen. Verwenden Sie niemals os.clock() als Epochenzeitstempel. Vertrauen Sie niemals einer Client-Uhr, verstrichener Dauer, Produktionsrate, Erntestufe, Asset-Liste oder dem letzten Beanspruchungszeitstempel.

Vergeben Sie dasselbe Intervall nicht zweimal. Zählen Sie Online-Produktion nicht doppelt. Führen Sie keine unbegrenzte Schleife einmal pro Offline-Sekunde aus. Behandeln Sie fehlende, fehlerhafte, Null-, negative und zukünftige Zeitstempel bewusst.

7. Entwicklungs- und Produktionsdaten schützen

• Verwenden Sie eine separate veröffentlichte Entwicklungs- oder Staging-Erfahrung für Live-DataStore-Integrationstests.
• Aktivieren Sie den Studio-Zugriff auf API-Dienste nur für diese isolierte Testerfahrung.
• Roblox warnt davor, dass Studio auf dieselben DataStores wie die Live-Anwendung zugreifen kann. Aktivieren Sie die Einstellung niemals auf der Produktion für routinemäßige Tests.
• Verwenden Sie Mocks oder einen In-Memory-Adapter für deterministische Logiktests. Ein Mock ist kein echter Spielerspeicher und kein dauerhafter Speicher.
• Verwenden Sie Einwegkonten und Testschlüssel.
• Löschen, rückgängig machen, umbenennen oder überschreiben Sie keine Produktionsdaten ohne explizite Betreiberautorisierung, genaue Zielidentifikation und einen Wiederherstellungsplan.
• Bewahren Sie Open-Cloud-Anmeldeinformationen auf einem vertrauenswürdigen Backend auf. Legen Sie sie niemals in einem LocalScript, Client, öffentlichen Repository oder Prompt-Kontext offen.

8. Ehrlich überprüfen und berichten

Verwenden Sie references/test-matrix.md. Decken Sie Profile von Neulingen und Rückkehrern, Ladefehler, Konflikte, veraltete Besitzer, Schreibreihenfolge, Wiederholungen, automatisches Speichern, Herunterfahren, Crash-Wiederherstellung, fehlerhafte Nutzlasten, Migrationen, Offline-Obergrenzen, wiederholte Beanspruchungen und doppelte Belege ab.

Geben Sie die Validierungsstufe genau an:

• Statische Überprüfung
• Reine Unit-Tests
• Mock/In-Memory-Integrationstests
• Veröffentlichte Staging-DataStore-Tests
• Roblox Studio-Laufzeittests
• Multi-Server-/Sitzungskonflikttests

Dies sind unterschiedliche Überprüfungen. Wenn Studio oder Staging nicht verfügbar war, geben Sie an, dass die Laufzeitvalidierung noch aussteht.

Nicht verhandelbare Verbote

• Speichern Sie niemals kanonische Spielerdaten von einem LocalScript.
• Vertrauen Sie niemals clientseitigen UserIds, Guthaben, Preisen, Inventaren, Besitzverhältnissen, Belohnungsraten, Zeitstempeln, verstrichener Zeit oder Kaufergebnissen.
• Behandeln Sie einen vorübergehenden Ladefehler niemals als neuen Spieler.
• Verwenden Sie niemals MemoryStoreService oder Server-RAM als dauerhaften Profilspeicher.
• Verwenden Sie niemals DataStore2 für eine neue Erfahrung. Roblox identifiziert es derzeit als Legacy-Bibliothek.
• Geben Sie niemals nach oder führen Sie Seiteneffekte in UpdateAsync-Rückrufen aus.
• Lassen Sie niemals zu, dass Same-Key-Schreibvorgänge und Wiederholungen konkurrieren.
• Stehlen Sie niemals gewaltsam eine aktive Sitzung als normale Wiederholung.
• Schreiben Sie niemals Rohwerte über einen Schlüssel, der von einer Profilbibliothek verwaltet wird.
• Behaupten Sie niemals, dass UpdateAsync allein eine Sitzungssperre implementiert.
• Führen Sie niemals unbegrenzte Offline-Simulationsschleifen aus.
• Legen Sie niemals Open-Cloud-Geheimnisse offen.
• Ändern Sie niemals Produktionsdaten zerstörerisch ohne explizite Autorisierung und einen Wiederherstellungsplan.
• Behaupten Sie niemals Studio-Tests, die nicht stattgefunden haben.

Referenzkarte

Laden Sie nur die Dokumente, die für die aktuelle Aufgabe benötigt werden:

• references/architecture-and-services.md: Dienstrollen, DataStore-Manager, Open Cloud und Speicherauswahl.
• references/player-data-lifecycle.md: Profillebenszyklus, In-Memory-Arbeitskopien, Bereitschaft, Verlassen und Herunterfahren.
• references/session-locking-and-failures.md: Sitzungsbesitz, UpdateAsync, Schreibreihenfolge, Wiederholungen, Drosselung und unbekannte Ergebnisse.
• references/offline-progression.md: Passive Belohnungen, Ernte-Timer, Generatoren, Zeitstempel-Mathematik, Obergrenzen und Einschränkungen bei Trennung.
• references/studio-testing.md: API-Zugriff, Staging, Mocks und sichere Testisolierung.
• references/schema-migrations-and-recovery.md: Serialisierung, Schema-Versionen, Migrationen, Versionsverlauf und Wiederherstellung.
• references/security-and-purchases.md: Remotes, Serverautorität, Belege, Open-Cloud-Geheimnisse und Datenschutz.
• references/performance-and-limits.md: Dokumentierte Grenzen, Budgets, Durchsatz und Betriebsoptimierung.
• references/library-selection.md: Nativer DataStoreService, offizieller Referenzcode und Bewertung von Drittanbieterpaketen.
• references/game-patterns.md: Profile, Bestenlisten, Grundstücke, passive Systeme, Handel und Käufe.
• references/test-matrix.md: Verifizierungsszenarien.
• references/official-roblox-sources.md: Nur Roblox Creator Hub-Quelllinks.
• examples/profile-template.luau: Beispielhafte Profilform.
• examples/offline-progress.luau: Reine begrenzte Offline-Belohnungsberechnung.

Erforderliche Implementierungsantwort

Für Implementierungs- und Debugging-Aufgaben:

1. Fassen Sie die bestehende Architektur zusammen, die im tatsächlichen Projekt gefunden wurde.
2. Erklären Sie den beabsichtigten Datenfluss und die kleinste sichere Änderung.
3. Listen Sie die genauen zu erstellenden oder zu modifizierenden Dateien auf.
4. Liefern Sie vollständigen, kontextbewussten Code, keine zusammenhanglosen Fragmente.
5. Erklären Sie Setup, Staging und alle Schema-Migrationsschritte.
6. Berichten Sie über tatsächliche Tests und verbleibende Laufzeitprüfungen.
7. Geben Sie wesentliche Grenzen und Risiken an, ohne Garantien zu erfinden.

Respektieren Sie die vom Benutzer angeforderte Sprache und den Stil. Bewahren Sie funktionierende Systeme. Fügen Sie keine nicht zusammenhängenden Funktionen hinzu und ersetzen Sie keine vorhandene Persistenzbibliothek aus stilistischen Gründen.