Behandl en fordring som en transaktion, ikke en knap tryk
En daily- dusørgrænseflade ser enkel ud: vis en kalender, fremhæv i dag, og lad spilleren kræve det. Den vanskelige del er alt bag denne knap. En klient kan sende den samme anmodning gentagne gange. To servere kan observere den samme lagrede tilstand. En datastore anmodning kan mislykkes efter en del af belønningslogikken er kørt. En spiller kan afbryde forbindelsen mellem persistens og præsentation. Hvis gennemførelsen behandler hver anmodning som tilladelse til at give, duplikat valuta og elementer er et forventet resultat snarere end en kantsag.
Den sikrere model er en serverejet transaktion. Klienten beder om at gøre krav på, men det afgør aldrig, om en belønning skyldes, hvad belønningen indeholder, eller om tilskuddet lykkedes. Serveren udleder den aktuelle belønningsperiode, indlæser den autoritative profil tilstand, validerer den konfigurerede belønning, forsøger en atomisk tilstand overgang, og først derefter returnerer et resultat klienten kan vise.
Denne adskillelse er den centrale regel: brugergrænsefladen kommunikerer hensigt; serveren ejer berettigelse og mutation.
Definer den mindste autoritative tilstand
Daglige belønninger behøver ikke en historie om hver grænseflade interaktion. De har brug for nok varig tilstand til at besvare tre spørgsmål: hvilken belønning periode blev sidst forpligtet, hvad streak position følger fra denne tilstand, og om den aktuelle anmodning kan flytte staten fremad.
En praktisk profil har normalt brug for en stabil periodenøgle, en sidst- succesful- claid nøgle, og en streak værdi. Periodetasten skal komme fra servertid og en dokumenteret nulstillingspolitik. Uanset om produktet nulstilles ved UTC midnat, ved en konfigureret regional grænse, eller efter en rullende varighed er en produktbeslutning, men beslutningen skal være afgørende på serveren. Kundeure bør aldrig afgøre støtteberettigelse.
Hold konfigurationen adskilt fra spillerens tilstand. Den indstillede kalender kan definere belønningsidentifikatorer, mængder, valutanavne, streak adfærd og aktive datoer. Spillerstaten bør henvise til en valideret konfigurationsversion eller stabil belønningsidentifikator i stedet for at kopiere vilkårlige klientbetalinger til opbevaring.
Validér fjernbetjeningen, før du rører opbevaring
Roblox sikkerhedsvejledning behandler hver værdi krydser klient- server grænse som utroværdig. For en daglig påstand, bør anmodningen være bevidst kedeligt. I mange designs serveren behøver ingen belønning beløb, streak antal, eller dag indeks fra klienten overhovedet; det kan udlede disse værdier selv.
Før datastorearbejde begynder, skal serveren anvende en lille afvisningskæde:
- bekræfte den anmodning, der er modtaget på den planlagte server RemoteEvent eller RemoteFunction
- afvise uventede typer, ekstra identifikatorer eller misdannede nyttelaster
- rate- limit krav forsøg pr. spiller på serveren;
- kontrollere spillerprofilen og den relevante funktionskonfiguration er tilgængelig
- afvise anmodninger, mens et krav på, at spilleren allerede behandles lokalt.
Rate begrænsning er ikke duplikate- Grant garanti. Det beskytter serverkapacitet og reducerer misbrug. Den holdbare garanti skal stadig overleve to servere, reli, genopretter forbindelser, og proces genstarter.
Gør støtteberettigelse og forpligtelse én atomare opdatering
En 'GetAsync ()' efterfulgt af 'SetAsync ()' efterlader et løbsvindue. To servere kan læse den samme usagte tilstand, både beslutte, at spilleren er støtteberettiget, og både skrive et tilskud. Roblox dokumenterer 'UpdateAsync ()' som den sikrere multi- server operation, fordi den læser den aktuelle værdi og genforsøger callback, når samtidig opdaterer konflikter.
Sæt beslutningen om støtteberettigelse i den atomare opdatering. Tilbagekaldelsen modtager den seneste lagrede værdi, kontrollerer om den nuværende periode allerede er indgået, og returnerer enten en ny tilstand eller "nul" for at annullere. Tilbagekaldelsen må ikke give resultat, så det bør ikke kalde eksterne tjenester, vente på tilfælde, eller udføre den synlige belønning tilskud selv.
Den forpligtede stat bør omfatte en holdbar tilskudsmarkør: belønningsperioden og den stabile belønningsidentifikator eller transaktionsnøgle, der vandt opdateringen. Hvis callback opdager, at markøren allerede eksisterer, er det korrekte resultat "allerede hævdet", ikke et andet tilskud.
Dette mønster konverterer gentagne anmodninger til gentagne læsning af samme resultat. Den første gyldige overgang vinder. Senere forsøg observere den engagerede markør og blive no- ops.
Luk kløften mellem vedholdenhed og belønning levering
Atomic profil tilstand forhindrer to krav overgange, men designet stadig har brug for en klar leveringsordre. Hvis valuta er tilføjet, før kravet markør er holdbar, kan en datastore fiasko forlade værdi ydet uden en rekord. Hvis markøren er gemt først og serveren crash før levering, kan spilleren have en forpligtet fordring uden elementet.
Den robuste svar er en idempotent tilskud rekord. Indsend en transaktion id og en leveringstilstand, derefter gøre belønning levering sikker at gentage mod denne identifikator. Valuta, opgørelse, badge, eller rettighedstjenester bør erkende, at en bestemt transaktion allerede er blevet anvendt. En recovery sti kan inspicere completed- but- undelivered records og prøve dem igen uden at skabe en anden belønning.
Ikke alle erfaringer har brug for en kompleks regnskabsbog, men alle erfaringer har brug for et eksplicit svar på spørgsmålet om partial- fiasko. "Anmodningen er sandsynligvis afsluttet" er ikke en garanti.
Reserve operationsordre under tilbageførselsforretninger
Datastore opkald kan mislykkes, og LiveOps Goblin runtime fundament bruger en sikker datastore wrapper med gentry og backoff adfærd. Gentagelse er ikke det samme som at sende den samme operation igen fra flere uafhængige opgaver. Roblox advarer om, at naive forsøg kan ombestille stateful operationer.
Brug en serialiseret fordring sti per spiller, bevare rækkefølgen af profilændringer, og holde transaktionsidentifikatoren stabil på tværs af forsøg. Prøv kun den mislykkedes operation med afgrænset backoff. Genberegn ikke en ny belønningsperiode eller transaktionsnøgle på hvert forsøg. Hvis spilleren forlader, skal holdbar inddrivelse være i stand til at fortsætte fra lagret tilstand snarere end fra en in- memory flag.
Diagnostics bør skelne afviste anmodninger, sats grænser, datastore advarsler, allerede hævdede resultater, forpligtede krav, og levering recovery. Disse begivenheder er operationelle beviser; de bør ikke afsløre hemmeligheder eller fabrikere aktivitet, når ingen analytics udbyder er konfigureret.
Hold konfigurationen sikker før den når spillet
Duplikat beskyttelse svækkes, når den eksporterede belønning kalender selv er tvetydig. LiveOps Goblin validerer umulige mængder, manglende datastore nøgler, tvetydige valutanavne, duplikerede koder, og udløb skemaer, før du producerer en versioned Roblox konfiguration.
En belønning definition bør bruge stabile identifikatorer, afgrænset mængder, kendte valuta eller opgørelse mål, eksplicitte tidsplan regler, og en version, der kan spores i diagnostik. Tomme kalendere bør forblive tomme, indtil en skaber tilføjer reelle belønninger. Demo værdier i produktionen konfiguration er mere farlige end en ærlig tom tilstand, fordi de kan blive realøkonomi mutationer.
Når en kalender ændres, beslutte, hvad der sker med spillere mid- streak. Stabil belønning identifikatorer og versioned konfiguration gør denne politik testbar. Position- kun antagelser gør det nemt for "dag tre" at henvise til forskellige belønninger før og efter en opdatering.
Test fejlene, ikke kun den lykkelige sti
En nyttig testmatrix for daily- reward bør omfatte mere end "krav én gang og modtage mønter".
- to hurtige anmodninger fra samme kunde
- anmodninger fra to serversammenhænge mod den samme gemte profil
- en fordring for en allerede indgået periode
- misdannede eksterne nyttelaster og rate- limit adfærd;
- datastore-konflikt, forbigående svigt og udtømte returstier
- afbryde forbindelsen efter forpligtelsen, men før klientbekræftelsen
- leveringsforsøg med anvendelse af samme transaktionsidentifikator
- en ændring i kalenderversionen under en aktiv streak
- en manglende eller ugyldig belønningskonfiguration
- analytics deaktiveret med diagnostik stadig fungerer.
Det forventede resultat er ikke blot "ingen nedbrud". Hver test bør hævde den endelige varige tilstand, antallet af tilskud, der anvendes, det klientsynlige resultat, og den diagnostiske begivenhed.
En kortfattet implementeringscheckliste
Det endelige design kan gennemgås med ti spørgsmål. Er støtteberettigelse afledt på serveren? Er nulstilling tid deterministisk? Er klienten sende kun hensigt? Er fjernforespørgsler valideret og server- rate- begrænset? Er kravet overgang atomare? Er den lagrede tilstand omfatter en stabil transaktion markør? Kan belønne levering gentages uden duplikering? Er relances bevare orden? Er konfigurationer versioned og valideret? Er concurrency og partial- failure test bevise præcis en varig tilskud?
Når alle ti svar er konkrete, en daglig belønning stopper med at være en skrøbelig knap håndtering og bliver en lille, forståelig LiveOps transaktion.
