Behandeln Sie einen Anspruch als Transaktion, nicht als Knopfdruck
Eine tägliche Belohnungsschnittstelle sieht einfach aus: Zeigen Sie einen Kalender, markieren Sie heute und lassen Sie den Spieler behaupten. Der schwierige Teil ist alles hinter dieser Schaltfläche. Ein Client kann dieselbe Anfrage wiederholt senden. Zwei Server können denselben gespeicherten Zustand beobachten. Eine Datenspeicheranforderung kann fehlschlagen, nachdem ein Teil der Belohnungslogik ausgeführt wurde. Ein Spieler kann zwischen Persistenz und Präsentation trennen. Wenn die Implementierung jede Anfrage als Erlaubnis behandelt, sind doppelte Währung und Gegenstände ein erwartetes Ergebnis und kein Randfall.
Das sicherere Modell ist eine servereigene Transaktion. Der Client bittet um einen Anspruch, aber er entscheidet nie, ob eine Belohnung fällig ist, was die Belohnung enthält oder ob die Gewährung erfolgreich war. Der Server leitet die aktuelle Belohnungsperiode ab, lädt den autoritativen Profilzustand, validiert die konfigurierte Belohnung, versucht einen atomaren Zustandsübergang und gibt erst dann ein Ergebnis zurück, das der Client anzeigen kann.
Diese Trennung ist die zentrale Regel: Die Benutzeroberfläche kommuniziert Absicht; der Server besitzt Berechtigung und Mutation.
Definieren Sie den kleinsten autoritativen Zustand
Tägliche Belohnungen brauchen nicht eine Historie jeder Schnittstelleninteraktion, sie brauchen genug dauerhaften Zustand, um drei Fragen zu beantworten: Welche Belohnungsperiode wurde zuletzt festgelegt, welche Streifenposition folgt aus diesem Zustand und ob die aktuelle Anfrage den Zustand vorwärts bringen kann.
Ein praktisches Profil benötigt normalerweise einen stabilen Periodenschlüssel, einen Last-Successful-Claim-Schlüssel und einen Streifenwert. Der Periodenschlüssel sollte von der Serverzeit und einer dokumentierten Reset-Richtlinie stammen. Ob das Produkt um Mitternacht, an einer konfigurierten regionalen Grenze oder nach einer rollenden Dauer zurückgesetzt wird, ist eine Produktentscheidung, aber die Entscheidung muss auf dem Server deterministisch sein. Client-Uhren sollten niemals die Berechtigung bestimmen.
Der konfigurierte Kalender kann Belohnungsidentifikatoren, Mengen, Währungsnamen, Streifenverhalten und aktive Daten definieren. Der Spielerstatus sollte sich auf eine validierte Konfigurationsversion oder eine stabile Belohnungsidentifikator beziehen, anstatt beliebige Client-Nutzlasten in den Speicher zu kopieren.
Validieren Sie die Fernbedienung, bevor Sie den Speicher berühren
Die Roblox-Sicherheitsrichtlinie behandelt jeden Wert, der die Client-Server-Grenze überschreitet, als nicht vertrauenswürdig. Für einen täglichen Anspruch sollte die Anforderung absichtlich langweilig sein. In vielen Designs benötigt der Server überhaupt keinen Belohnungsbetrag, keine Streifennummer oder keinen Tagesindex vom Client; er kann diese Werte selbst ableiten.
Bevor die Datenspeicherarbeit beginnt, sollte der Server eine kleine Ablehnungskette anwenden:
- die auf dem vorgesehenen Server RemoteEvent oder RemoteFunction angekommene Anfrage zu bestätigen;
- unerwartete Typen, zusätzliche Identifikatoren oder fehlerhafte Nutzlasten ablehnen;
- Rate-Limit-Anspruchsversuche pro Spieler auf dem Server;
- überprüfen, ob das Spielerprofil und die entsprechende Funktionskonfiguration verfügbar sind;
- Anfragen ablehnen, während ein Anspruch für diesen Spieler bereits lokal bearbeitet wird.
Die Preisbegrenzung ist nicht die Garantie für doppelte Zuschüsse. Sie schützt die Serverkapazität und verringert den Missbrauch. Die dauerhafte Garantie muss noch zwei Server überleben, Retries, Reconnects und Prozessneustarts.
Machen Sie Förderfähigkeit und Engagement ein Atom-Update
Ein "GetAsync()" gefolgt von "SetAsync()" hinterlässt ein Rennfenster. Zwei Server können den gleichen nicht beanspruchten Zustand lesen, beide entscheiden, dass der Spieler berechtigt ist, und beide schreiben einen Zuschuss. Roblox dokumentiert "UpdateAsync()" als sicherer Multi-Server-Betrieb, da er den aktuellen Wert liest und den Rückruf wiederholt, wenn gleichzeitige Updates Konflikte haben.
Der Rückruf erhält den letzten gespeicherten Wert, prüft, ob der aktuelle Zeitraum bereits festgelegt wurde, und gibt entweder einen neuen Zustand oder "nil" zurück. Der Rückruf darf nicht nachgeben, also sollte er keine externen Dienste anrufen, auf Instanzen warten oder die sichtbare Belohnung selbst durchführen.
Der engagierte Zustand sollte einen dauerhaften Grant-Marker enthalten: die Belohnungsperiode und den stabilen Belohnungsidentifikator oder Transaktionsschlüssel, der das Update gewonnen hat. Wenn der Callback feststellt, dass der Marker bereits existiert, wird das richtige Ergebnis "bereits beansprucht" und nicht ein weiterer Grant.
Dieses Muster wandelt wiederholte Anfragen in wiederholte Lesevorgänge des gleichen Ergebnisses um. Der erste gültige Übergang gewinnt. Spätere Versuche, den engagierten Marker zu beobachten und No-Ops zu werden.
Schließen Sie die Lücke zwischen Persistenz und Belohnungslieferung
Atomic profile state verhindert zwei Claim-Übergänge, aber das Design benötigt immer noch einen klaren Lieferauftrag. Wenn Währung hinzugefügt wird, bevor der Claim-Marker dauerhaft ist, kann ein Datastore-Ausfall den gewährten Wert ohne Datensatz hinterlassen. Wenn der Marker zuerst gespeichert wird und der Server vor der Lieferung abstürzt, kann der Spieler einen festen Anspruch ohne den Gegenstand haben.
Die robuste Antwort ist ein idempotenter Grant-Record. Beauftragen Sie eine Transaktionskennung und einen Lieferzustand, dann machen Sie die Belohnungslieferung sicher, um sie mit dieser Kennung zu wiederholen. Währung, Inventar, Abzeichen oder Berechtigungsdienste sollten erkennen, dass eine bestimmte Transaktion bereits angewendet wurde. Ein Wiederherstellungspfad kann verpflichtete, aber nicht zugestellte Aufzeichnungen inspizieren und wiederholen, ohne eine zweite Belohnung zu erstellen.
Nicht jede Erfahrung braucht ein komplexes Hauptbuch, aber jede Erfahrung braucht eine explizite Antwort auf die Teilfehlerfrage. „Die Anfrage endet wahrscheinlich ist keine Garantie.
Anweisungsbefugnis bei Wiederholungen aufbewahren
Datastore-Aufrufe können fehlschlagen, und die LiveOps Goblin-Runtime-Stiftung verwendet einen sicheren Datastore-Wrapper mit Retry- und Backoff-Verhalten. Wiederholen ist nicht dasselbe wie das erneute Senden derselben Operation aus mehreren unabhängigen Aufgaben. Roblox warnt davor, dass naive Retries zustandsabhängige Operationen neu ordnen können.
Wenn der Spieler einen serialisierten Anspruchspfad pro Spieler verwendet, die Reihenfolge der Profiländerungen beibehält und den Transaktionsidentifikator über alle Wiederholungen hinweg stabil hält, nur die fehlgeschlagene Operation mit begrenztem Backoff wiederholt, keine neue Belohnungsperiode oder einen neuen Transaktionsschlüssel bei jedem Versuch berechnet, sollte eine dauerhafte Wiederherstellung aus dem gespeicherten Zustand und nicht aus einem In-Memory-Flag fortgesetzt werden können.
In der Diagnose sollten abgelehnte Anfragen, Tarifgrenzen, Datenspeicherwarnungen, bereits beanspruchte Ergebnisse, zugesagte Ansprüche und Lieferwiederherstellung unterschieden werden.
Halten Sie die Konfiguration sicher, bevor sie das Spiel erreicht
LiveOps Goblin validiert unmögliche Mengen, fehlende Datenspeicherschlüssel, mehrdeutige Währungsnamen, doppelte Codes und abgelaufene Zeitpläne, bevor eine versionierte Roblox-Konfiguration erstellt wird.
Eine Belohnungsdefinition sollte stabile Identifikatoren, begrenzte Mengen, bekannte Währungs- oder Inventarziele, explizite Zeitplanregeln und eine Version verwenden, die in der Diagnose nachvollzogen werden kann. Leere Kalender sollten leer bleiben, bis ein Ersteller echte Belohnungen hinzufügt. Demo-Werte in der Produktionskonfiguration sind gefährlicher als ein ehrlicher leerer Zustand, weil sie zu realwirtschaftlichen Mutationen werden können.
Wenn sich ein Kalender ändert, entscheiden Sie, was mit den Spielern in der Mitte des Weges passiert. Stabile Belohnungsidentifikatoren und versionierte Konfiguration machen diese Richtlinie überprüfbar. Positionsbasierte Annahmen machen es einfach für den dritten Tag, sich auf verschiedene Belohnungen vor und nach einem Update zu beziehen.
Testen Sie die Misserfolge, nicht nur den glücklichen Weg
Eine nützliche Testmatrix für tägliche Belohnungen sollte mehr als "einmal behaupten und Münzen erhalten" enthalten.
- zwei schnelle Anfragen von demselben Kunden;
- Anfragen von zwei Serverkontexten gegen dasselbe gespeicherte Profil;
- eine Forderung für einen bereits gebundenen Zeitraum;
- defekte Fernnutzlasten und Rate-Limit-Verhalten;
- Datenspeicherkonflikt, vorübergehender Ausfall und erschöpfte Wiederholungspfade;
- Trennung nach Verpflichtung, aber vor Kundenbestätigung;
- Delivery Retry unter Verwendung derselben Transaktionskennung;
- eine Änderung der Kalenderversion während eines aktiven Streifens;
- eine fehlende oder ungültige Belohnungskonfiguration;
- Analyse deaktiviert, da die Diagnose noch funktioniert.
Das erwartete Ergebnis ist nicht nur "kein Crash". Jeder Test sollte den endgültigen dauerhaften Zustand, die Anzahl der gewährten Zuschüsse, das vom Kunden sichtbare Ergebnis und das diagnostische Ereignis angeben.
Eine kurze Implementierungs-Checkliste
Das endgültige Design kann mit zehn Fragen überprüft werden. Ist die Berechtigung vom Server abgeleitet? Ist die Reset-Zeit deterministisch? Sendet der Client nur Absicht? Sind Remote-Requests validiert und Server-Rate-begrenzt? Ist der Claim-Übergang atomar? Enthält der gespeicherte Zustand einen stabilen Transaktionsmarker? Kann die Belohnungslieferung ohne Duplizierung wiederholt werden? Bewahren Retries die Ordnung bei? Sind Konfigurationen versioniert und validiert? Beweisen Gleichzeitigkeits- und Teilfehlertests genau eine dauerhafte Bewilligung?
Wenn alle zehn Antworten konkret sind, ist eine tägliche Belohnung kein fragiler Button-Handler mehr und wird zu einer kleinen, verständlichen LiveOps-Transaktion.
