Traktuj roszczenie jako transakcję, a nie naciśnięcie przycisku
Interfejs daily- reward wygląda na prosty: pokaż kalendarz, podświetl dzisiaj i pozwól graczowi twierdzić. Trudna część jest wszystko za tym przyciskiem. Klient może wysłać to samo żądanie wielokrotnie. Dwa serwery mogą obserwować ten sam zapisany stan. Żądanie datastore może nie udać się po części logiki nagrody uruchomiony. Gracz może odłączyć się od trwałości i prezentacji. Jeśli implementacja traktuje każdy wniosek jako pozwolenie na przyznanie, duplikat waluty i elementów są oczekiwanym wynikiem, a nie edge case.
Bezpieczniejszy model jest transakcją należącą do serwera. Klient prosi o roszczenie, ale nigdy nie decyduje, czy nagroda jest należna, co nagroda zawiera, czy dotacja się powiodła. Serwer czerpie z bieżącego okresu nagrody, ładuje autorytatywny stan profilu, waliduje skonfigurowaną nagrodę, próbuje jednej atomowej transformacji stanu, a dopiero potem zwraca wynik, który klient może wyświetlić.
Ta separacja jest główną zasadą: interfejs użytkownika komunikuje zamiar; serwer jest właścicielem kwalifikowalności i mutacji.
Zdefiniuj najmniejszy stan autorytatywny
Codzienne nagrody nie potrzebują historii każdej interakcji z interfejsem. Potrzebują one wystarczająco trwałego stanu, aby odpowiedzieć na trzy pytania: który okres nagrody został ostatnio popełniony, co pass pozycji wynika z tego stanu, i czy obecna prośba może przesunąć stan do przodu.
Praktyczny profil zazwyczaj potrzebuje stabilnego klucza okresu, ostatniego, sukcesywnego klucza roszczenia i wartości passy. Klucz okresu powinien pochodzić z czasu serwera i udokumentowanej polityki resetowania. Czy produkt resetuje o północy UTC, na skonfigurowanej granicy regionalnej, lub po okresie toczenia jest decyzją produktu, ale decyzja musi być determinująca na serwerze. Zegary klienta nigdy nie powinny określać kwalifikowalności.
Zachowaj konfigurację odrębną od stanu gracza. Konfigurowany kalendarz może określać identyfikatory nagród, ilości, nazwy walut, zachowanie passy i daty aktywne. Stan gracza powinien odnosić się do zatwierdzonej wersji konfiguracyjnej lub stabilnego identyfikatora nagrody, a nie kopiować arbitralne ładunki klienta do przechowywania.
Walidacja pilota przed dotknięciem pamięci masowej
Wytyczne bezpieczeństwa Roblox traktują każdą wartość przekraczającą granicę klienta jako niezaufaną. W przypadku codziennego roszczenia żądanie powinno być celowo nudne. W wielu projektach serwer nie potrzebuje żadnej kwoty nagrody, numeru passy lub indeksu dniowego od klienta; może on samodzielnie uzyskać te wartości.
Przed rozpoczęciem pracy w datastore, serwer powinien zastosować mały łańcuch odrzucania:
- potwierdzić wniosek dostarczony na docelowym serwerze RemoteEvent lub RemoteFunction;
- odrzuca nieoczekiwane typy, dodatkowe identyfikatory lub nieprawidłowo ukształtowane ładunki;
- próby roszczeń rate- limit na jednego gracza na serwerze;
- weryfikuje profil gracza i dostępna jest odpowiednia konfiguracja funkcji;
- odrzucić wnioski, podczas gdy roszczenie dla tego gracza jest już przetwarzane lokalnie.
Ograniczenie stawki nie jest gwarancją duplikatu-grantu. Chroni on pojemność serwera i zmniejsza nadużycia. Trwała gwarancja musi przetrwać dwa serwery, ponownie próbuje, ponownie łączy i ponownie rozpoczyna proces.
Zakwalifikowanie i zobowiązanie jednej aktualizacji atomowej
A 'GetAsync ()' następnie 'SetAsync ()' pozostawia okno wyścigowe. Dwa serwery mogą odczytać ten sam nieżądany stan, obie decydują, że gracz kwalifikuje się do pomocy, a obie zapisują dotację. Roblox documents 'UpdateAsync ()' jako bezpieczniejszą wieloserwerową operację, ponieważ odczytuje bieżącą wartość i ponownie próbuje oddzwaniać podczas równoległych aktualizacji konfliktu.
Umieść decyzję kwalifikacyjną wewnątrz tej aktualizacji atomowej. Wywołanie otrzymuje najnowszą zapisaną wartość, sprawdza, czy bieżący okres został już popełniony, i zwraca albo nowy stan lub "zero", aby anulować. Wywołanie nie może się zwrócić, więc nie powinno wywoływać zewnętrznych usług, czekać na instancje, lub wykonać widzialną nagrodę grant sam.
Dopuszczony stan powinien zawierać trwały znacznik dotacji: okres wynagradzania i stały identyfikator nagrody lub klucz transakcji, który wygrał aktualizację. Jeśli odsyłacz odkryje ten znacznik już istnieje, prawidłowy wynik jest "już twierdził", a nie inny grant.
Ten wzór przekształca powtarzające się żądania w powtarzające się odczyty o tym samym wyniku. Pierwsza poprawna wygrana przejścia. Późniejsze próby obserwacji przypisanego znacznika i stają się nie-ops.
Zamknięcie luki między utrzymaniem a wypłatą nagrody
Stan profilu atomowego zapobiega dwukrotnym przejściu roszczenia, ale projekt nadal wymaga wyraźnego zlecenia dostawy. Jeśli waluta jest dodana przed utrzymaniem markera roszczenia, awaria datastore może pozostawić wartość przyznaną bez rekordu. Jeśli marker jest przechowywany pierwszy, a serwer awarii przed dostawą, gracz może mieć zobowiązanie roszczenia bez pozycji.
Solidna odpowiedź jest idemstrong grant record. Przekazać identyfikator transakcji i stan dostawy, a następnie dokonać dostawy nagrody bezpiecznie powtórzyć przed tym identyfikatorem. Waluta, inwentaryzacja, odznaka, lub usługi uprawnień powinny uznać, że dana transakcja została już zastosowana. Ścieżka odzyskiwania może sprawdzić podjęte - ale - niedostarczone rekordy i ponownie spróbować je bez tworzenia drugiej nagrody.
Nie każde doświadczenie potrzebuje skomplikowanego rejestru, ale każde doświadczenie potrzebuje wyraźnej odpowiedzi na pytanie o częściową porażkę. "Żądanie prawdopodobnie się zakończy" nie jest gwarancją.
Zachowaj kolejność operacji podczas ponownych prób
Wywołania Datastore mogą nie powiodły się, a fundacja runtime LiveOps Goblin używa bezpiecznego owijania datastore z powtarzającym się zachowaniem. Pobieranie nie jest tym samym, co wysyłanie tej samej operacji ponownie z kilku niezależnych zadań. Roblox ostrzega, że powtarzające się próby naiwne mogą ponownie uporządkować operacje stanu.
Użyj jednej seryjnej ścieżki roszczenia na gracza, zachowaj kolejność zmian profilu, i zachować identyfikator transakcji stabilny w nawiasach. Przywróć tylko nieudaną operację z ograniczonym backuffem. Nie rekompensuj nowego okresu wynagradzania lub klucza transakcji na każdej próbie. Jeśli gracz opuszcza, trwały odzysk powinien być w stanie kontynuować z zapisanego stanu, a nie z flagi in- pamięci.
Diagnostyka powinna odróżniać odrzucone wnioski, limity stawek, ostrzeżenia o datastorie, już zgłoszone wyniki, popełnione roszczenia i odzyskanie dostaw. Zdarzenia te są dowodami operacyjnymi; nie powinny ujawniać tajemnic ani tworzyć działalności, gdy nie jest skonfigurowany żaden dostawca analityki.
Zachować konfigurację bezpieczną przed dotarciem do gry
Duplikat ochrony jest osłabiony, gdy sam eksportowany kalendarz nagród jest niejednoznaczny. LiveOps Goblin potwierdza niemożliwe ilości, brakujące klucze datastore, niejednoznaczne nazwy walut, duplikaty kody i wygasły harmonogramy przed wyprodukowaniem zmodyfikowanej konfiguracji Roblox.
Definicja nagrody powinna korzystać ze stabilnych identyfikatorów, ograniczonych ilości, znanych celów walutowych lub inwentaryzacyjnych, jednoznacznych zasad harmonogramów i wersji, która może być śledzona w diagnostyce. Puste kalendarze powinny pozostać puste, dopóki twórca nie doda rzeczywistych nagród. Wartości demo w konfiguracji produkcji są bardziej niebezpieczne niż uczciwy pusty stan, ponieważ mogą stać się mutacje realnej gospodarki.
Kiedy zmienia się kalendarz, zdecydować, co dzieje się z graczami mid- pass. Stabilne identyfikatory nagród i konfiguracji wersji sprawiają, że testable. Pozycjonowanie - tylko założenia sprawiają, że łatwo "dzień trzeci" odnosić się do różnych nagród przed i po aktualizacji.
Testuj porażki, nie tylko szczęśliwą ścieżkę
Użyteczna matryca testowa daily- reward powinna zawierać więcej niż "roszczenie raz i otrzymać monety".
- dwa szybkie wnioski tego samego klienta;
- żądania z dwóch kontekstów serwerów w stosunku do tego samego przechowywanego profilu;
- roszczenie za okres już popełniony;
- zniekształcone zdalne ładunki i zachowanie limitu rate-;
- konflikt danych, przejściowe niepowodzenie i wyczerpane ścieżki ponownego próbowania;
- rozłącz się po zobowiązaniu, ale przed potwierdzeniem klienta;
- ponowna próba dostawy przy użyciu tego samego identyfikatora transakcji;
- zmiana wersji kalendarza podczas aktywnej passy;
- brak lub niepoprawna konfiguracja nagrody;
- analityka wyłączona z diagnostyką nadal działa.
Oczekiwany wynik to nie tylko "brak awarii". Każdy test powinien potwierdzić ostateczny trwały stan, liczbę zastosowanych dotacji, widoczny wynik klienta i zdarzenia diagnostycznego.
Zwięzła lista kontrolna wykonania
Ostateczny projekt może być zweryfikowany z dziesięciu pytań. Czy kwalifikowalność wynika z serwera? Czy reset czas determinuje? Czy klient wysyła tylko intencje? Czy zdalne żądania są potwierdzone i server- rate- ograniczone? Czy atom w przejściu roszczenia? Czy zapisany stan zawiera stabilny marker transakcji? Czy nagroda dostawy może być powtórzona bez powielania? Czy powtórzenia zachowają porządek? Czy konfiguracje są modyfikowane i zatwierdzane? Czy testy konkursowe i częściowe niepowodzenia udowadniają dokładnie jeden trwały grant?
Kiedy wszystkie dziesięć odpowiedzi są betonowe, codzienna nagroda przestaje być kruchą obsługą przycisków i staje się małą, zrozumiałą transakcją LiveOps.
