Local OTS #1 - następca MyOTS
Ostatnie dwie edycje MyOTS polegały na gromadzeniu ryb. Na Local OTS dalej w ramach trybu single-player i blogowej formy / konwencji będę wykonywał grind, ale nie samych ryb, a nieco większej puli typów wartości. Do tego dojdzie wiele nowych wartości, których na ten moment nie widziałem jeszcze nigdy na jakimkolwiek OTS, wiele z nich jest już dodana.
Definicje, skróty ogólne i wewnętrzne
HP (ang. Health Points) – Punkty Życia.
MP (ang. Mana Points) – Punkty Many.
HP tier 2 – Punkty życia tieru 2, inaczej zapasowe punkty życia.
HP tier 3 – Punkty życia tieru 3, inaczej zewnętrzne punkty życia.
MP tier 2 – Punkty many tieru 2, inaczej zapasowe punkty many.
MP tier 3 – Punkty many tieru 3, inaczej zewnętrzne punkty many.
Tier 1 HP lub/i MP – Synonim dla HP/MP bez wymieniania tieru, a jeszcze inaczej HP/MP bazowe, tudzież użytkowe. Wszystkie te określenia będą używane w serii wymiennie.
NPC (ang. Non-Playable Character) – Bohater niezależny, niebędący graczem, z którym można wchodzić w interakcje.
Lvl (ang. level) – poziom.
Exp (ang. experience) – punkty doświadczenia, których odpowiednia ilość pozwala na zdobywanie kolejnych poziomów.
Gra dla pojedynczego gracza / gra jednoosobowa (ang. single-player) – gra / tryb gry dla jednego gracza.
Świątynia (ang. Temple) – w praktyce jest to główny budynek w grze, w którym postać może zalogować się na nowo po śmierci, ewentualnie po niektórych restartach serwerów (w zależności od konfiguracji danego serwera) więc nie ma potrzeby dosłownie rozumieć tego budynku jako spełnianie jakiś fantastyczno-religijnych funkcji w ramach fabuły gry, a raczej jako taką ogólnie utartą, przyjętą nazwę własną istniejąca w szerokim uniwersum OTSów, tudzież oficjalnych serwerów od co najmniej kilkunastu lat. W szerszej społeczności graczy najlepszym synonimem na Tibijskie Temple jest po prostu termin hub.
Bignum (skrót ang. big number) - Wielkie liczby, arbitralna precyzja, wielka precyzja to ogólne nazewnictwo na wszystkie liczby wykorzystywane w programowaniu, których zakres przechowywania wartości jest większy niż pojedyncza zmienna 32, lub 64-bitowa lub inna zależna od platformy. Metody wdrażania i powstawania bignumów są zależne od języka programowania, danej aplikacji, środowiska programistycznego i tego, czy dana wielka precyzja jest już zaimplementowana natywnie do danego języka / środowiska, czy nie (ponieważ, gdy istnieje już natywna alternatywa, wówczas mniejsza presja programistów działających w obrębie danego języka, aby dodać dodatkowe biblioteki na coś, co już jest wdrożone). Obecnie w wielu popularnych językach programowania istnieją natywne bignumy, natomiast równie w wielu istnieją jedynie biblioteki, które trzeba samemu wdrożyć do danej aplikacji.
Wprowadzenie do Local OTS
Całe uniwersum Local OTS podzielone jest na ten moment na dwa światy: s1 (świat 1) i s2 (świat 2).
Świat 1 podobnie jak w przypadku MyOTS stanowi świat główny, na którym najwięcej się dzieje.
Świat 2 to świat zawierający wiele wykluczonych elementów testowych ze świata pierwszego i inne pozostałe zasoby, którymi nie chciałem zaśmiecać świata pierwszego.
Zdecydowaną różnicą między poprzednim projektem, a ówczesnym jest fakt, iż rozgrywka jest modyfikowana nie tylko z poziomu skryptów LUA, plików XML i konfiguracyjnych, ale również poprzez edycję silnika gry.
Możliwość wprowadzania zmian w silniku stwarza prawie nieograniczone możliwości rozwoju projektu, dzięki temu już obecnie dzięki modyfikacjom mojego znajomego oraz moich własnych głównym maincorem gry jest możliwość transferowania HP oraz MP.
Transfer HP oraz MP
HP i MP dalej jest ograniczone do 2147483647, natomiast poprzez transfery można magazynować większą ilość, nieużytkowego HP/MP niż wartość 2147483647, ponieważ ów transfery zamieniają w jedną lub w drugą stronę daną wartość na tak zwane HP/MP tieru 2. Tier 2 jest bignumem opartym o bibliotekę GMP (mpz). Przy 32-bitowym aplikacjach oraz użyciu funkcji typu mpz można w praktyce przechowywać wartości o długości między ~500 milionów, a ~1,1 miliarda cyfr (przynajmniej według publikacji oraz dyskusji w internecie, na które się natknąłem sprawdzając wszelkie możliwe informacje na temat limitów tejże biblioteki w tym zakresie). Natomiast ów potencjalny limit przeszkadzał mi na tyle, że postanowiłem stworzyć jeszcze większą abstrakcję w abstrakcji. Innym tematem jest rozdzielenie na mpz, a mpn oraz aplikacje 64-bitowe, ale to temat prawdopodobnie na inny czas, gdyż aby omówić go naprawdę dokładnie, musiałbym zrobić bardzo dokładny research w związku z tym zagadnieniem, a nie chcę aby ów biblioteka bignumów była jakimś szczególnym motywem tego artykułu. Zapewne będzie okazja aby w serii Local OTSowej i o tym szerzej opowiedzieć.
Tier 3 jako przekraczanie kolejnych granic
Wspomniany limit funkcji typu mpz w bibliotece GMP spowodował, że zapragnąłem czegoś jeszcze mniej limitowanego, pomimo, że już przy tej programistycznej bibliotece, naprawdę ciężko w praktyce dojść do ów limitu. Z tego powodu powstał tier 3 dla HP (dla MP jest on planowany w przyszłości). Polega to na transferze HP tieru 2 do HP tieru 3, przy czym z tieru 2 wartość w znaczniku w pliku postaci jest technicznie zabierana, natomiast tier 3 tworzy się za pośrednictwem bilansu logów. Podczas wykonania transferu tworzony jest wpis w pliku tekstowym, z ilością transferowanego HP oraz nicku postaci, którego transfer dotyczy.
Przykład:
2022-10-22 16:26 Przeniesiono 10 000 HP tieru 2 do HP tieru 3 (A Tester 1)
Następnie wartość przenoszona będzie poza grą sumowana i dalej przetwarzana, jednak na warstwie opisowej będzie dalej związana z postacią.
Transfery w praktyce
Zanim jednak bardziej zagłębię się w kwestię tieru 3, wpierw dla lepszego zrozumienia pokażę w praktyce jak przebiegają na ten moment transfery z podstawowych wartości HP/MP (tieru 1) do tieru 2 i odwrotnie.
Transfer najlepiej wykonać przed i po odrodzeniu, ponieważ po odrodzeniu wartość HP i MP jest resetowana do wartości 1000 jednostek.
Transfery wykonywane są za pośrednictwem NPC’tów.
Transfer HP do HP tieru 2 (HP zapasowego):
Każdy transfer z HP do HP tieru 2 kosztuje 10 cc dla 100 000 HP.
Transfer HP zapasowego (tieru 2) do HP:
Każdy transfer z HP tieru 2 do HP kosztuje 10 cc dla 100 000 HP.
Transfer HP tieru 2 do zewnętrznego HP (tier 3) (stara wersja):
Każdy transfer z HP tieru 2 do HP tieru 3 kosztuje 10 cc dla 100 000 HP (dla starszej wersji).
Transfer HP tieru 2 do zewnętrznego HP (tier 3) (nowa wersja):
W nowszej wersji tego rodzaju transferu, każde przeniesienie HP tieru 2 do HP zewnętrznego wynosi 100 cc dla 10 000 HP.
Jest również kilka wersji testowych / eksperymentalnych NPC’tów, które transferują HP:
Brakuje transferu odwrotnego, mianowicie z HP zewnętrznego do HP zapasowego, ale to prawdopodobnie będzie wprowadzone w kolejnych aktualizacjach serii i serwera.
Alternatywnie, w bardzo podobny sposób działają warianty z NPC transferujące MP. Nie będę ich jednak pokazywał tak wnikliwie jak HP, gdyż działają na bardzo podobnej zasadzie, lecz transferują rzecz jasna punkty many zamiast życia.
Zwiększanie HP lub MP dla poszczególnych tierów
HP i MP dla prawie wszystkich trzech tierów (nie wszystko jeszcze działa w obie strony oraz dla MP) można zwiększać bezpośrednio, poprzez NPC oraz w jednym przypadku poprzez przedmioty.
Każda gruszka zwiększa maksymalną ilość punktów życia o 250 jednostek. Początkowo zwiększały o 5000, ale uznałem, że jest to zbyt OP (overpowered).
Gruszki można kupić u NPC Sprzedawca Gruszek. Jednak można uzyskać dużo więcej HP w inny sposób, a mianowicie również poprzez NPC, lecz zwiększając zapasowe HP, a nie zwykłe.
Zakup 100 000 HP tieru 2 to koszt 100 cc.
Alternatywnie wszystko działa w podobny sposób również dla MP.
Aby było bardziej przyrostowo, stworzyłem również warianty NPC, u których można zwiększyć HP/MP tieru 2 o +1% do łącznej wartości.
Tier 3: Plany i przechodzenie z tieru 2
Wartość zewnętrzna zapisana jako log w pliku tekstowym staje się częścią całej zewnętrznej wartości dla danej postaci. Następnie wszystkie logi są sumowane (bilans eksportu i importu) i ów suma będzie mogła być dalej przetwarzana poprzez aktualizację ów bilansu oraz mnożona przez mechanikę kupowania zwiększenia wartości procentowo.
Jednak zwiększenie wartości procentowo tak naprawdę z każdym kolejnym tierem (zagnieżdżeniem abstrakcji) jest coraz mniej dokładne.
Wpierw utrata dokładności po raz pierwszy bezpośrednio w grze zachodzi poprzez dodawanie wartości procentowej zapasowego HP (tier 2).
mpz_div(jeden_procent, x, y);
mpz_add(result, x, jeden_procent);
Powyższy fragment kodu C++ pochodzi z funkcji pozwalającej na procentowe zwiększenie wartości. Zastosowałem tu podobne uproszczenie we wzorze skutkując przy tym natychmiastową utratą precyzji dla wielu wariantów obliczeń, jak w przypadku BigIntowego kalkulatora obliczającego potrzebną ilość prób na dany poziom łowienia.
Najpierw dzielona jest wartość łączna HP tieru 2 przez 100 (w przypadku, gdy dodawaną wartością ma być 1% całej poprzedniej wartości).
Następnie 1% całej poprzedniej wartości jest dodawany do zaktualizowanej łącznej wartości. Nawet przy wartościach zmiennoprzecinkowych i tak, w którymś miejscu po przecinku trzeba przestać obliczać kolejne rozszerzenia ułamka (a właściwie sam w sobie limit zmiennej zmiennoprzecinkowej za to odpowiada), natomiast w tym przypadku następuje to jeszcze szybciej i jest to bardziej przewidywalne, bowiem ułamek się nigdy nie pojawia, zatem precyzja jest jeszcze mniejsza.
Przykład teoretyczny użycia biblioteki obsługującej bignumy użytej do wyżej przedstawionego kodu z obliczaniem 1% łącznej wartości i jej dodaniem do wcześniejszej wartości:
123 123 * 1% = 1 231,23 = ~1 231
123 123+1 231 = 124 354
Utrata wartości: 0,23
Przykłady w praktyce:
Obliczenia na kalkulatorze bez bignumów:
132 035 978*1,01 = 133 356 337,78
Wartość podniesiona bezpośrednio w grze:
132 035 978 -> 133 356 337
Utrata: 0,78. Przy zwykłym zaokrągleniu do liczb całkowitych w przypadku przybliżonym wynikiem byłoby 133 356 338, a więc wręcz nadwyżka o 0.22. Jednak tutaj trzeba mieć na względzie wzór i sam typ arbitralnej precyzji użyty w funkcji wyliczającej, która to funkcja nie zaokrągla według standardowej powszechnie znanej matematyki, tylko ucina możliwy ułamek.
Największa na tym etapie obserwowana strata to 0,99.
Obliczenia na kalkulatorze bez bignumów:
9 999 999 999 999*1,01 = 10 099 999 999 998,99
Wartość podniesiona bezpośrednio w grze:
9 999 999 999 999 -> 10 099 999 999 998
O ile bezpośrednio przy każdorazowym zwiększeniu wartości o 1% nie zaobserwowałem utraty większej niż 0,99 to trzeba pamiętać, że przy dalszym zwiększaniu wartości realna strata będzie znacznie większa, ponieważ łączna wartość z uwzględnieniem zaokrąglonej ostatniej cyfry byłaby większa przy dalszym mnożeniu procentowym niż bez takowego zaokrąglenia, tylko całkowitemu usunięciu części ułamkowej.
Jest to jednak wciąż niewielka strata w porównaniu z korzyściami jakie niesie za sobą wdrożenie arbitralnej precyzji do HP i MP tieru 2.
Pierwszy etap minimalnych strat jak widać powyżej następuje już w tierze 2, natomiast w planowanym tierze 3 możliwe, że utrata precyzji będzie jeszcze większa, bowiem przy mnożeniu procentowym planuję do pewnego momentu używać odpowiednich kalkulatorów w JS, które będą obliczać wcześniej ustaloną sumę eksportowanych i importowanych ilości HP, natomiast również z uwagi na możliwe ograniczenia praktyczne BigInta JavaScriptowego, możliwe, że mnożenie procentowe będę skracał do uwzględnienia jedynie pierwszych n-ilości cyfr, przykładowo dla wartości 1200202020, mnożone przez 101% (*1,01) byłaby jedynie wartość 120, natomiast reszta byłaby przepisywana. Oczywiście w rzeczywistości nastąpiłoby to zapewne przy dużo większych liczbach, ale na potrzeby przykładu wybrałem stosunkowo małą liczbę dla łatwiejszego zrozumienia.
Wcześniej użyłem terminu ograniczenie praktyczne BigInta Javascriptowego. Otóż jako ograniczenie praktyczne rozumiem tu oczekiwany czas na wynik, który dla liczb przekraczających milion cyfr na obecnie głównie używanym przeze mnie komputerze powoduje już widoczne opóźnienia około-sekundowe, rzecz jasna przy jeszcze większych wartościach czas oczekiwania wzrasta tym bardziej. Przekroczenia jakiegokolwiek ograniczenia twardego (limitu natywnej biblioteki BigInta) raczej się tu nie spodziewam, aczkolwiek i w przypadku praktycznych ograniczeń też jestem dość sceptycznie nastawiony, ale cały ten projekt chcę aby był urzeczywistnieniem moich największych obaw i prognoz co do potencjalnych limitów nawet używanych w projekcie bignumów (czy to BigInta w JS dla wartości zewnętrznych, ale też dla GMP mpz w C++ w samym silniku gry).
W trakcie pisania z przerwami tego rozdziału wpadłem na pomysł eksportu/importu HP/MP z mnożnikami zależnym od danego poziomu NPC, który ów eksport/import może dokonać. Byłaby to mechanika, która mogłaby zastąpić częściowo mnożenie procentowe zewnętrznych wartości, aczkolwiek jednocześnie mogłaby to być również mechanika, która jednoznacznie zmniejszy tempo przyrostu dla wartości tieru 3.
Teoretyczny przykład, możliwy do wdrożenia:
NPC Transfer do HP tier 3 [2], gdzie [2] w nicku, tudzież ogólnym nazewnictwie/definicji NPCa będzie oznaczało jego poziom. NPC tego typu z drugim poziomem oprócz samego transferu dodaje również mnożnik dla eksportowanej wartości (co do importu musiałby być oddelegowany osobny typ takiej postaci i zapewne inne zasady z uwagi na ograniczenie nieskończonego powielania HP tieru 2 małym kosztem). Mnożnik będzie zależny bezpośrednio od poziomu NPC transferującego HP z tieru 2 do tieru 3. Zasada ustalenia mnożnika może być bardzo prosta i jednocześnie bardzo przyrostowa, bowiem 2 lvl oznacza mnożnik x100 (2 zera po jedynce), co odpowiada w zapisie z notacją wykładniczą z indeksem górnym: 10^2 lub bez niego wykorzystując (e - ang. exponent): 1e2. Wartość bazowa wynosiła by na podstawie pierwszego poziomu transferu tieru 3, 10 000 HP, a więc przeniesienie 10 000 HP tieru 2, powodowałoby dodanie końcowe do tieru 3 aż 1 000 000 HP (10 000*100).
System odrodzeń
System, którego zdecydowanie zabrakło w MyOTS, aczkolwiek biorąc pod uwagę specyfikę poprzedniego projektu przyznać trzeba, że nie była to też rzecz najbardziej priorytetowa. Wcześniej z uwagi na brak możliwości edycji silnika ciężko było zmienić cokolwiek, co wykracza poza LUA/XML. W Local OTS już taka możliwość zaistniała i wdrożyłem ze znajomym system odrodzeń bazujący na systemie autorstwa Xelixa, aczkolwiek nie wprowadzony 1:1, gdyż zawiera pewne małe zmiany.
Bazowo system wprowadza możliwość wykonania odrodzenia po przekroczeniu ustalonego maksymalnego poziomu za pomocą komendy !reborn. Reborn może zwiększać procentowo obrażenia magiczne (o ustaloną wartość), natomiast ilość punktów doświadczenia i poziom zostaje zresetowany do ustalonej wartości w konfiguracji systemu.
Zmiany podczas wdrożenia tego systemu do Local OTSa z poziomu silnika są następujące:
- HP i MP również ulega zresetowaniu i jest aktualizowane na wartością równą 1000 zarówno dla HP i MP dla każdej profesji.
- Odrodzenie nie wylogowuje postaci.
Konfiguracja:
Wymagany poziom do odrodzenia: 820 000 (po około tysiącu poziomów powyżej następuje zminusowanie wartości punktów doświadczenia z uwagi na ograniczenie zmiennej przechowującej wartość expa). Dodatkowy procent do obrażeń na każde zdobyte odrodzenie: 2%.
Powodem, dla którego HP/MP ulega zresetowaniu po wykonaniu odrodzenia jest główny, dotychczasowy motyw przewodni serii. HP i MP można eksportować/importować do różnych tierów, dzięki czemu zaraz po odrodzeniu można wykorzystać zapasowe HP/MP poprzez transfery, tak samo w odwrotnym kierunku - HP/MP można przelać do wyższych tierów przed odrodzeniem, aby zachować jeszcze więcej punktów życia i many.
Zabezpieczenia transferu, luki w bezpieczeństwie transferów oraz w balansie
Transfer HP do HP tieru 2 jest zabezpieczony poprzez warunek sprawdzający, czy wartość HP nie jest niższa 101 000 HP, tak aby nie wykonać transferu z HP na minusie, gdyż taki błąd pozwalałby dopóki są możliwe środki do wydania na ciągłe zwiększanie zapasowego HP. Podobne zabezpieczenie jest na MP. Luką w ów zabezpieczeniu jest fakt, iż transfer w drugą stronę nie jest w ten sposób sprawdzany, ponieważ wówczas trzeba by było porównywać wartości oparte o bibliotekę GMP, a nie jest to tak proste do wdrożenia jak w przypadku zwykłych zmiennych, przynajmniej mnie się to na ten moment jeszcze nie udało.
Innym problemem jest możliwość czasami jednak przejścia na wartość minusową przy transferze z HP do HP tieru 2, gdy bardzo szybko wykonuje się interakcje z NPC (na serwerze nie ma systemu dodatkowo opóźniającego wysyłane przez gracza wiadomości).
W przypadku tieru 3 będą dochodziły luki w braku balansu po wprowadzeniu dodatkowych mnożników z transferami, które będzie można naprawić poprzez odpowiednio drogie transfery w odwrotnym kierunku lub poprzez wprowadzenie kolejnych bardziej wartościowych tierów HP/MP.
Trzeba też pamiętać, że wpierw wprowadzane są zmiany HP, a więc niektóre rodzaje transferów/zwiększania wartości dla MP są dodawane później niż dla HP.
Unifikacja punktów życia i many
Jednym z planów rozwoju projektu jest wprowadzenie wartości, w której będą przechowywane zarówno punkty życia jak i many, natomiast transfer do bazowej wartości HP lub MP będzie odbywał się przy pomocy wyboru, którą wartość gracz chce importować. Wartość stanowiącą połączenie HP i MP będzie można połączyć z nowymi mechanikami wprowadzającymi ogólny balans we wszystkich tierach powyżej tieru 1, aczkolwiek z uwagi na wprowadzenie w pierwszej kolejności tieru 3 może utrudnić ewentualny balans, aczkolwiek dużo bardziej zależy mi na odpowiednim stopniu przyrostowości, niż na balansie, zwłaszcza, że gra ma charakter single-playerowy.
Temple
Podczas wstępnej modyfikacji mapy, przeniosłem większość NPC do Temple, które zostało znacząco zmodyfikowane w porównaniu do wcześniejszej wersji mapy stanowiącej części podstawki data packa, na którym bazuje Local OTS.
Piętro 1:
Piętro 2:
Piętro 3:
Podziemia:
W kolejnym artykule planuję dokładniej pokazać temple oraz jego następne modyfikacje. W tym wypadku nie pokazałem Temple z perspektywy gry przez co na powyższych screenach nie widać rozstawienia NPC. Jest to zabieg celowy, bowiem ów budynek nie jest jeszcze w +/- finalną wersją, którą mam zamiar dokładniej zaprezentować dopiero, gdy uznam to za stosowne.
Mapa
Podczas prac nad serwerem zastałem mapę dołączoną do data packa jednego z forków Yurotsa 7.6. Została ona znacznie zmodyfikowana, aczkolwiek rozstawienie kilku podstawowych wysp może być zauważalne, dla osób, które miały już styczność z podstawką, której nie będę tutaj przedstawiał.
Mapa Local OTSa, świat 1 (30.10.2022) - wysokość 7:
Do części lokacji z nowymi mobami można dostać się jedynie pieszo, natomiast do innych kluczowych miejsc związanych i przystosowanych pod obecną rozgrywkę, można dostać się za pośrednictwem teleportów ulokowanych w Temple.
Nowa waluta
Jeden z przedmiotów (gold nugget) został zakodowany w skryptach zmieniających waluty (LUA) oraz w samym silniku gry (C++) na nową walutę. Jeden gn (gold nugget) to 100 cc (crystal coins).
Podsumowanie znanych na ten moment ograniczeń
Wszystkie poniższe ograniczenia mają lub mogą mieć wpływ na przebieg rozgrywki. Nie każde ograniczenie zostało poznane dokładnie.
- Limit HP/MP wynoszący 2147483647 (int32).
- Limit poziomu: ~821000 (int64 punktów doświadczenia).
- Limit wykorzystanej pamięci operacyjnej dla całego serwera (dla aplikacji 32-bitowej): ~2,1 GB (int32?).
- Limit wykorzystanej pamięci operacyjnej dla pojedynczej postaci (dla aplikacji 32-bitowej): poniżej 2,1 GB (int32?).
- Limit mapy: ~65535 x 65535 sqm (uint16?).
- Limit pojedynczej wpłaty/wypłaty: ~2147483647 gp (podstawowej wirtualnej waluty) dla int32 (niezbadane dokładne).
- Limit arbitralnej precyzji biblioteki GMP dla funkcji typu mpz dla aplikacji / wdrożenia 32-bitowego: od ~500 milionów do ~1,1 miliarda cyfr dla pojedynczej wartości (niezbadane dokładne, potencjalny limit bazuje na szczątkowym sprawdzeniu i researchu).
- Limit długości pojedynczego stringa dla 32-bitowych aplikacji / wdrożenia: 1 073 741 820 znaków (źródło informacji z kodem na podstawie którego, można sprawdzić samemu ów limit w zależności od wykorzystywanej platformy kod .
- Praktyczny limit: Coraz dłuższy czas oczekiwania na obliczanie coraz dłuższych liczb (dotyczy zarówno samej gry jak i obliczania wartości zewnętrznych przy użyciu dedykowanych kalkulatorów planowanych w przyszłości).
Planowany sposób prowadzenia serii, a więc gameplay w praktyce
Im wyższy numer pozycji w tym rozdziale, tym mniej prawdopodobne urealnienie danego planu (najbardziej prawdopodobne są pozycje 1 i 2, pozycja 3 mniej, a na czwórkę nikła szansa).
Artykuły – Będą dotyczyć głównie aktualizacji i planów związanych ściśle z rozwojem gry.
Załączniki – Będą dotyczyć głównie archiwizacji progresu na wybranych postaciach w formie dołączonych screenów oraz stylizowanych pod interfejs gry statystyk z licznymi modyfikacjami treści ów interfejsów, tak aby były jak najbardziej dopasowane do obecnej całej modyfikacji gry / gameplayu.
Filmy – na YT (na kanałach Danys lub Danys Archiwum) mam zamiar publikować treści audiowizualne zarówno związane z gameplayem jak i aktualizacjami.
Kontynuacja MyOTS – Niektóre mechaniki dotyczące gromadzenia ryb mogą być przeniesione do obecnego projektu, aczkolwiek jaki byłby ich sens dla obecnego sposobu rozgrywki? Ciężko stwierdzić, same w sobie ryby również musiałby być jakoś zmodyfikowane, tak aby je dopasować pod nowe standardy.