Chunky i inne pluginy do pregeneracji mapy – szczegółowy test wydajności

0
4
Rate this post

Z tego artykuły dowiesz się:

Gdzie zaczyna się problem – prawdziwy ból admina przy braku pregenu

Scena z życia: pregen odpalony „na żywca”

Wyobraź sobie: świeży wipe, nowy survival, kilkanaście osób wbija punkt 18:00. Gracze wybiegają ze spawnu, część teleportuje się na /rtp, inni od razu lecą w różne strony. TPS zaczyna siadać, konsola zasypuje logi „Can’t keep up!”, Discord wybucha: „lagi”, „cofnęło mi itemy”, „wywaliło mnie przy wejściu do Netheru”. Ty w panice odpalasz pregenerację mapy pluginem, który „ktoś polecił”. Przez chwilę jest lepiej, po chwili serwer stoi na 5 TPS, pojawiają się timeouty, kilka osób traci całe ekwipunki po crashu.

Po godzinie gasisz serwer, robisz rollbacka, a na czacie dalej wylewa się sól. Problem wcale nie znika – pierwsza większa eksploracja na nowej mapie za każdym razem wysadza wydajność, bo serwer próbuje na bieżąco generować masę nowych chunków. Za każdym nowym światem, Netherem czy Endem ta sama historia wraca jak bumerang.

Ten scenariusz jest powodem, dla którego w ogóle szukasz narzędzia do pregeneracji mapy typu Chunky czy alternatyw. Chcesz mieć wygenerowany teren zanim wejdą gracze, tak żeby serwer podczas gry zajmował się głównie obsługą ticków, a nie ciężkim liczeniem terenu i struktur.

Co się dzieje bez pregeneracji albo z źle ustawionym pregenem

Bez pregeneracji świat powstaje „na żądanie” – kiedy gracz zbliża się do granicy dotychczas wygenerowanego terenu, silnik generuje kolejne chunki: teren, jaskinie, struktury, populację (moby, rośliny). To jedna z najcięższych operacji CPU i I/O po stronie serwera Minecraft. Jeśli kilka osób jednocześnie eksploruje w różnych kierunkach, generacja chunków potrafi położyć TPS nawet na mocnej maszynie, jeśli dzieje się to nagle i masowo.

Z kolei źle ustawiony pregen (np. zbyt agresywne tempo na produkcji) może zrobić to samo, tylko w bardziej „skomprymowanej” formie: plugin generuje tyle chunków na tick, że serwer nie nadąża. Efekt z punktu widzenia gracza jest podobny: teleporty, gumkowanie postaci, opóźnione otwieranie skrzynek, znikające bloki kopane kilka sekund temu.

Do tego dochodzi jeszcze problem nowych wymiarów. Pierwsze wejście do Netheru lub Endu bez pregenu to klasyczny trigger: serwer równocześnie tworzy nowy folder świata, generuje struktury (fortece, end cities), zapisuje pierwsze regiony i próbuje obsłużyć ruch gracza. Jeśli ten moment nastąpi przy większym obciążeniu, łatwo o timeout lub crash.

Dlaczego ten problem wraca przy każdym wipe

Nawet jeśli uda się przetrwać start mapy bez większej katastrofy, temat wraca przy następnym resecie. Nowy seed, nowy świat, znowu dziesiątki graczy ruszają w nieznane. Bez pregeneracji albo z nieprzemyślanym pregenem za każdym razem powtarzasz ten sam stres: „czy tym razem serwer to zniesie?”.

Im większa sieć serwerów, tym bardziej boli to organizacyjnie. Każdy nowy tryb (kolejny survival, freebuild, skyblock z customowym Overworldem), nowe światy eventowe, farmowe Nether/End – wszystko wymaga wygenerowania terenu. Jeśli robisz to „na żywo”, administracja zamiast skupiać się na kontencie, siedzi i gasi pożary wydajnościowe.

Do tego dochodzi presja graczy. Raz doświadczone lagi przy starcie sezonu zostają w pamięci. Serwery, które przy otwarciu mapy nie radzą sobie z generacją chunków, szybko zyskują łatkę „lagowni”. W efekcie tracisz nie tylko g