Shapez.io #2: Postępy po ponad 300. godzinach gry

1. Omówienie zmian między częściami serii #1, a #2.

Na początku pierwszego artykułu byłem po około 200 godzinach gry. Od tamtego czasu minęło około 120 godzin, a więc tempo tej serii blogowej jest nadzwyczaj wolne.

Nie mniej jednak po takim czasie za pewne jak się można domyślić, wiele się zmieniło.

Przede wszystkim z tytułem Shapez.io miałem kilku miesięczną przerwę (mniej więcej, bo już tak dobrze nie pamiętam). Przerwa była związana z większym zainteresowaniem się w tamtym czasie innymi grami, innymi projektami oraz głównie tym, że zostałem bardzo zniechęcony do dalszej długiej gry po usunięciu 9/10 zmagazynowanych przedmiotów, gdy do gry został wprowadzony Wires Update.

Później pojawił się jeszcze jeden problem, który znacząco mnie do dalszej gry zniechęcił. Po wczytaniu zapisu, zauważyłem, że już w pełni zapełnionych magazynach zaczęły znikać przedmioty. Dla przykładu, w każdej kolumnie z sektorami, z magazynami, która przechowuje maksymalnie 500 000 kształtów, gdy ów kolumna nie jest podłączona do żadnej fabryki, po wczytaniu zapisu, w pierwszych dwóch magazynach (budynkach), które mogą zmieścić maksymalnie 5 000 przedmiotów, zamiast wartości “5tyś”, wartość zmienia się na “4.9tyś”. Nie ma pewności, czy na pewno jest to pełne 100 przedmiotów z uwagi na skrótową notację z dokładnością do około 100, oraz fakt, że przedmioty znikają w każdym początkowym magazynie to dla każdej kolumny po wczytaniu zapisu znika około 200 przedmiotów.

Po długiej przerwie odzyskałem znowu chęci do dalszej gry w Shapez.io. Jednak zastanawiałem się co zrobić z problemem znikających przedmiotów. I wpadłem na jakże prosty, ale też genialny w swej prostocie pomysł. Do każdej kolumny z magazynami dołączam fabrykę z danym kształtem, który znajduje się w danym składowisku. Nie we wszystkich składowiskach dołączam dodatkową fabrykę do każdej kolumny z magazynami, ponieważ niektóre kształty są na tyle skomplikowane, że do ich finalizacji potrzeba dużo szerszych fabryk niż wynosi szerokość pojedynczej kolumny, co powoduje, że w przyszłości i tak musiałbym zrezygnować z tej zasady i stosować np. jedną podtrzymującą fabrykę na kilka kolumn.

Zastosowałem już coś takiego w przypadku ostatnio założonego składowiska niepomalowanych gwiazdek.

Jak widać każda kolumna magazynów ma 4 kratki wysokości (bądź szerokości, w zależności od rotacji / perspektywy). Z przerwą między kolumnami można przyjąć, że jest to maksymalnie 5 kratek.

Natomiast kompaktowa pojedyncza fabryka gwiazdek ma wysokość aż 7 kratek. W tym przypadku nie jest możliwe dołączanie każdej podtrzymującej fabryki do każdego sektora. Jedynym wyjątkiem byłoby stworzenie struktury, w której doprowadzenie taśmociągów / tuneli do każdej kolejnej fabryki podtrzymującej jest coraz dłuższe, ale to nie jest optymalne rozwiązanie, a ponadto nie jestem pewien, czy na pewno nie niosłoby to za sobą wielu logistycznych problemów w przyszłości.

Z pierwszego screena można zobaczyć, że faktycznie jedna z fabryk jest połączona z kilkoma kolumnami magazynów i pomimo tego, że pustych kolumn z pojemnością do 500 000 przedmiotów w jednej raczej taka fabryka by nie zapełniła dość szybko. Czymkolwiek jest “szybko”, to już taka bardziej moja subiektywna, metaforyczna miara w tym przypadku. Jednak w przypadku, gdy kolumny już są zapełnione i chodzi jedynie o uzupełnienie chwilowych braków kilkuset elementów na kolumnę po wczytaniu zapisu, to wydaję mi się, że takie rozwiązanie jest niemal idealne.

Sytuacja inaczej wygląda jeśli chodzi o kolejne składowisko małych kwadratów, czy też wcześniej zwanych przeze mnie skrawków, elementów tego typu. Na każde 5 kratek szerokości kolumny może zmieścić się kompaktowa podtrzymująca fabryka, która również ma szerokość 5 kratek. Ponadto jako, że są to tylko pojedyncze, nie złożone elementy, to w ostatnim czasie byłem w stanie zaprojektować kilka wariantów fabryk, które zapełniają dwie linie transportowe w pełni na każdą daną kolumnę magazynową i nadal mieszczą się per kolumna. Może nie być to zbyt zrozumiałe, bo pisarz ze mnie nie najlepszy, ale screeny wydaje mi się, że rozwieją wszelkie wątpliwości.

Na powyższym screenie widać pierwsze kompaktowe fabryki mogące zapełnić maksymalnie jedynie jedną linię transportową. Do podtrzymania strat po wczytaniu zapisu jest to wystarczające. Natomiast opracowałem lepsze warianty, wspomniane wcześniej.

Tutaj widać kompaktowe fabryki, które są już wstawiane zarówno w celach zapełnienia całej kolumny oraz w celu późniejszego zwracania strat po wczytaniu zapisu. Co ciekawe nie dość, że zapełniają wspomniane dwie linie transportowe (maksymalne wejście dla pojedynczej kolumny magazynowej), to w dodatku mieszczą się idealnie w maksymalnej szerokości poszczególnej kolumny.

Jeśli chodzi o skrawki kwadratów ułożonych na ćwiartce “górnej-prawej” to stworzyłem trzy warianty kompaktowych fabryk. Na poniższych screenach są ukazane te fabryki w formie szablonów, które później wykorzystuję do duplikacji ich w odpowiednie miejsca, przy dalszej rozbudowie składowisk.

Trzy warianty: Gdy kwadratowa ćwiartka do obróbki jest w miejscu góra-lewo i dół-prawo. Drugi wariant: Lewo-dół i prawo-góra oraz prawo-góra i prawo-dół.

Dlaczego zawsze są to co najmniej dwa kwadratowe elementy? Z prostego powodu, aby zostały zapełnione dwie linie transportowe to na wejściu oryginalnie wygenerowany element, też musi mieć dwa takie elementy, tak aby jak najszybciej można było zapełnić daną szynę transportową.

Tak prezentuje się składowisko małych kwadratów, pierwsza część Składowiska Elementów Zapasowych przy maksymalnym oddaleniu (maksymalne oddalenie dla mojej konfiguracji gry).

Jak widać, każda kolumna magazynowa na tym kadrze posiada osobną kompaktową fabrykę.

Maksymalne oddalenie składowiska gwiazdek:

W tym wypadku widać wiele fabryk, które będą prawdopodobnie wielokrotnie zmieniane / przenoszone / usuwane / etc. Jest to jednak związane częściowo z tym o czym pisałem wcześniej z większym rozmiarem szerokości / wysokości fabryk niż szerokością / wysokością kolumn magazynowych.

2. Statystyki

- Usunięte / zarchiwizowane elementy z pierwszego artykułu serii:

29 209 390

1 892 800

- Aktualna produkcja kluczowych elementów:

- Zmagazynowane elementy w HUBie (HUB - Budynek Główny):

- Zmagazynowane elementy w Składowisku Elementów Zapasowych:

Metoda liczenia: Tylko pełne kolumny magazynowe po 500 000 elementów w każdym.

31 500 000

4 500 000

- Zmagazynowane elementy w Składowisku Wiatraków:

Bardzo przybliżone pomiary.

15 000 000

- Zmagazynowane elementy w Archiwum Zewnętrznym [przyszły, planowany projekt]:

0

0

3. Ewentualna przyszłość serii i problemy.

Dlaczego ewentualna? Ponieważ, nigdy nie wiadomo w pełni co tak naprawdę stanie się w przyszłości. I dlaczego ten podpunkt jest właśnie o tym?

Wraz z dodawaniem kolejnych fabryk, magazynów, itp., wirtualny czas gry zdaje się coraz bardziej zwalniać, zatem wydajność per fabryka w czasie bardziej rzeczywistym najprawdopodobniej jest coraz słabsza. Ponadto aktywne fabryki z tego co zauważyłem zabierają coraz więcej pamięci operacyjnej. W przypadku zapisu, tej pamięci jest używane jeszcze więcej, gdyż gra najprawdopodobniej przechowuje również wiele informacji w RAMie o całym zapisie, nawet struktur już nie używanych.

Jeśli chciałbym dalej rozwijać tę serię, muszę część elementów będących bezpośrednio z gry przenosić w pewien sposób poza nią, czyli coś w rodzaju rozszerzonego gameplayu, jak to było w przypadku chociażby takich gier jak Swords and Souls: A Soul Adventure, czy też RPG Shooter: Starwish, projektów typu MyOTS. Jednak z Shapez.io jest troszkę inna sytuacja. Nie ma mowy tu tylko o kilku, ciągle rosnących wartościach, tylko o ciągle rozbudowywanej infrastrukturze fabryk, magazynów, które to fabryki i magazyny mają swoje odrębne wartości, składające się dopiero w jedną całość poprzez moje wyliczenia oraz wyliczenia, które automatycznie wykonuje gra. To powoduje, że musiałbym wprowadzić wiele innych metod związanych z takim rozszerzonym gameplayem. Z drugiej strony jeśli tego nie wprowadzę w czas, to bardzo możliwe, że niedługo nie będę mógł dalej grać, gdyż zabraknie mi np. pamięci operacyjnej, bądź gra będzie przebiegać w swym wirtualnym tempie zbyt wolno. Jest to bardzo mało prawdopodobny scenariusz, ponieważ prowadzę kopie zapasowe zapisów gry z różnych okresów, ale jednak lepiej rozwinąć projekt również w nieco innym kierunku, gdyż to co robię w tej chwili i tak nie jest typowym gameplayem. Aczkolwiek o tym wspominałem już w pierwszej części tej serii blogowej. Oprócz tego chciałbym niektóre kształty gromadzić na jeszcze większą skalę.

4. Kilka słów na koniec artykułu (nie koniecznie serii).

W artykule pojawiło się wiele kwestii związanych z różnicami w progresie, wiele statystyk, omówienie ewentualnej przyszłości serii, natomiast nie wspomniałem o wszystkim, a więc aby za bardzo nie modyfikować już pierwszego punktu, wspomnę o tym tutaj.

Mianowicie wcześniej byłem bardzo poirytowany tym, że w pewnym momencie po wczytaniu zapisu gry znikają przedmioty w magazynach. W bardzo małej ilości, ale jednak znikają. Wspomniałem o tym niemal na początku tego wpisu, lecz zapomniałem dodać, że w ostatnim czasie, całkiem przypadkiem dowiedziałem się, iż w zależności od rozbudowy zapisu, pewne wartości (zmienne) tracą dokładność, tak aby ogólna wydajność gry została w miarę zachowana. Nie sprawdzałem tego dokładnie, ale bardzo możliwe, że stany magazynowe zaczęły znikać w pewnym momencie przez właśnie rozmiar zapisu, a więc jednak przez automatyczny zabieg optymalizacyjny, dzięki któremu możliwe, że w ogóle jestem w stanie jeszcze dalej ten save kontynuować.

Kolejna kwestia, o której zapomniałem wcześniej wspomnieć dotyczy ówczesnego systemu ulepszeń, który pozwala na upgrade do 1 000. poziomu. Nowy system jest zrobiony tak, że na coraz większy poziom trzeba coraz więcej kształtów zebrać, jednak bonus na każdy poziom, zdaje się być coraz mniejszy. Przy czym oczywiście sama suma bazowych wartości rośnie. Doszedłem do powiedziałbym wręcz pewnego kuriozum jeśli chodzi o system ulepszeń w momencie ulepszenia z poziomu 26 na 27.

Szybkość ma zmienić się z x10.00 na x10.0. Prosto matematycznie można by rzec, że jest to tyle samo. Natomiast tutaj dochodzi kwestia dokładności zmiennych, a dokładnie wartości zmiennoprzecinkowych i tego, w którym miejscu po przecinku dokonujemy przybliżenia. Przy pewnym przybliżeniu, które robi gra z punktu widzenia programistycznego ma to sens, gdyż zmniejsza się dokładność, a każdy kolejny poziom przyznaje coraz mniej szybkości, zatem wizualnie, bądź też nawet praktycznie w pewnym przybliżeniu znowuż czysto matematycznie wychodzi na to, że pewnie ulepszenia nie dodają nic do szybkości, natomiast warto zauważyć, że zmienia się precyzja tych wartości. Zatem jeśli dokładność wynosi teraz z 2 miejsc po przecinku na tylko jedno miejsce, a ulepszenie daje dajmy na to +0,04 to nic dziwnego, że gra zaokrągla to do +0,0 i wtedy mamy nawet przesłankę czysto matematyczną, że ma to w pewnym kontekście sens logiczny. Podana wartość 0,04 jest tu tylko przykładem, w rzeczywistości nie wiem ile dokładnie gra próbuje dodać do sumy szybkości. Próbowałem po prostu to zjawisko wyjaśnić w dość potoczny sposób.

Autor: Ynfi (Danys)

Rozpoczęcie artykułu: 13.06.2021

Opublikowano: 13.06.2021