Teraz widzicie, że takie podejście uprościłoby niektóre odczyty z tabeli 4.

Możecie pomyśleć, że powinniśmy przechowywać nowo obliczone dane po zapisaniu nowego wpisu rejestru. Może to wyglądać na dobre rozwiązanie w teorii, ale poskutkowałoby brakiem spójności danych i degradacją wydajności. Przykładem może być fakt, że system byłby zajęty ponownym obliczaniem i przechowywaniem danych ze względu na potrzebę odczytu, a następnie zapisu. Musimy zrównoważyć proces obliczania podczas gry, by zapewnić odpowiednią wydajność wszystkim graczom.

Przykładem niespójnych danych są obliczenia na koniec gry. Infrastruktura naszego serwera i wsparcie platformy do obsługi spóźnionych wiadomości. Załóżmy, że istnieje przejściowy problem w dwóch centrach danych (A i B), a wiadomość dotycząca przyznania graczowi doświadczenia mini zostaje wysłana z A, ale nie dotarła jeszcze do B. Scenariusz wyglądałby następująco: gracie chwilę przed północą. Wygrywacie w środę o godz. 23:59. Procesor zestawiający był skonfigurowany tak, by pracować codziennie dla danych do bieżącego dnia. Rozpocznie o północy, przetworzy wartości całkowitego doświadczenia do czwartku, godz. 00:00. Dane zostają zapisane w drugiej tabeli, a nowe odczyty doświadczenia wyszukiwałyby ostatnią zachowaną wartość i sumowałyby wszystkie po czwartku, godz. 00:00. Spóźniona wiadomość zostaje dostarczona, ale gra była ukończona w środę o godz. 23:59, co spowoduje zapisanie wpisu z doświadczeniem z taką właśnie godziną. Tabela zestawień będzie zawierać ten wpis, a zapytanie o późniejsze dane nie pokaże tego wpisu. Niekompletne dane stanowią problem. Co z wiadomościami, które przyjdą kilka dni później? Mamy specjalny system monitorowania i powiadamiania, który niemal zawsze gwarantuje, że nowe informacje zostaną przetworzone w odpowiednim czasie przed następnym zestawieniem.

Obliczanie poziomów mini

Spójrzmy na tabelę całkowitego doświadczenia. Zauważcie, że nie ma tam obliczeń dotyczących poziomów. Bierzemy tylko sumę uzyskanego doświadczenia. Oddzielnie występuje tabela statyczna, którą twórcy gry zaprojektowali w taki sposób. Mini zaczyna na poziomie 1, po zyskaniu 1 PD otrzyma poziom 2, a potem musi zdobyć 3 PD, by awansować na poziom 3.

Połączenie dwóch zestawień pozwala obliczyć faktyczny poziom mini w czasie rzeczywistym, obliczając sumę bieżącą, co daje nam ostateczne dane:

Twórcy gry mogą dowolnie zmieniać ilość doświadczenia, jaka jest niezbędna do awansowania na wyższy poziom. Mogą zadecydować, że za trudno jest awansować na niższych poziomach i zmniejszyć potrzebne PD. Oznacza to, że liczba PD mini na ich obecnym poziomie zostałaby nieco zwiększona i potrzebowałyby mniej, aby osiągnąć następny. Wszystko bez zmian wprowadzonych w danych graczy zapisanych w bazie danych. Działa to również w drugą stronę. Twórcy gry mogą stwierdzić, że PD zyskuje się za szybko. Nie będziemy cofać poziomów mini do tych sprzed zmiany. Możliwe jest jednak wprowadzenie rozwiązania, dzięki któremu będziemy mogli przyznawać nieco doświadczenia dla mini.

Alternatywne rozwiązania

Oprócz obecnego rozwiązania rozpatrywaliśmy różne podejścia do przechowywania uzyskiwanego doświadczenia i obliczania poziomu dla mini. Niektóre oznaczałyby dłuższe przestoje w celu zmiany doświadczenia graczy, a inne świetnie sprawdzały się w zapewnianiu dobrych doświadczeń z gry i nadążaniu z postępami graczy.

„Zawsze przechowuj poziom i PD mini do następnego poziomu”

A gdyby tak wykorzystać standardowy wzorzec SQL i użyć aktualizacji transakcyjnych? Pozwalają one zaktualizować dane w całości – wszystkie albo żadne. Jeśli jakaś część się nie zapisze, wszystkie wartości zostaną cofnięte do pierwotnej wartości. Zapewniają one zbiór właściwości A.C.I.D. – niepodzielność, spójność, izolację i trwałość.

Wykorzystują jeden wiersz, aby zachować doświadczenie każdego mini i całkowity poziom, dzięki czemu odczyt nie stanowi dużego obciążenia.

Gdy każda mini otrzymuje doświadczenie, jest aktualizowana do 2 PD z 8 PD do awansu na poziom 3. Taki rodzaj zmiany zmusza odczyt danych, ponowne obliczenie i zapis do bazy danych. Wzorzec ten nie sprawdza się z Cassandrą i jej silnymi cechami. Kolejnym problemem z takim podejściem są zmieniające się ilości potrzebne do następnego poziomu, które wymagałyby wyłączenie dostępu graczom do gry, abyśmy mogli zmodyfikować dane wszystkich mini dla graczy.

„Przechowywanie w formie procentowej”

Zastanawialiśmy się również nad przechowywaniem procenta niezbędnego do awansu na kolejny poziom, na przykład:

Po grze dokonujemy szybkich obliczeń. Na przykład Gnol wojownik otrzymuje +3 PD, procentowo to +3 / 10, dajmy Gnolowi wojownikowi 30% następnego poziomu, co skutkuje:

Zapewniłoby nam to elastyczność po zmianie krzywej poziomu mini, ale nie poskutkowałoby zmianą poziomu dla mini. Umożliwiłoby nam to również łatwiejszą wizualizację w interfejsie użytkownika w grze – wystarczy napełnić 30% paska, bez konieczności wykonywania obliczeń. Taki wzorzec poskutkowałby bardzo małymi wartościami procentowymi na wyższych poziomach. Gdy mini otrzymuje 10 PD za grę, a wymaga 100 000 PD do awansu, wartość byłaby przedstawiana jako 0,01%. Procesory poradzą sobie z liczbami zmiennoprzecinkowymi, ale precyzja i dokładność wiąże się z błędami, jeśli nie weźmiemy pod uwagę natury obliczeń zmiennoprzecinkowych.

Do następnego razu…

Rozpatrywaliśmy wiele możliwości w zakresie technologii baz danych, narzędzi oraz przechowywania i obliczeń. Jak ze wszystkim w fazie projektowania, może to jeszcze ulec zmianie, jeśli znajdziemy lepsze rozwiązanie, ale obecny mechanizm zdaje się być dobrym punktem wyjściowym.

Dziękujemy za lekturę!

~ Andy Lim