Podstawy generowania świata w rodzinie Bukkit, Spigot, Paper i Purpur
Gdzie kończy się rola Mojang, a zaczyna rola silnika serwera
Minecraft Java ma wbudowany generator świata po stronie gry-klienta i serwera vanilla. To on decyduje o układzie biomów, kształcie terenu, strukturach takich jak wioski, świątynie, bastiony czy miasta w Endzie. Forki Bukkit/Spigot/Paper/Purpur nie piszą całego generatora od zera – korzystają z kodu Mojang, ale mocno wpływają na to, kiedy i w jaki sposób ten generator jest uruchamiany i obsługiwany.
Silnik typu Spigot czy Paper to serwer, który przejmuje kontrolę nad:
kolejnością zadań związanych z chunkami (tworzenie, ładowanie, zapisywanie, odśmiecanie),
organizacją pracy w wątkach (synchronicznie vs asynchronicznie),
częścią logiki populacji świata (ile struktur, ile rud, ile dekoracji na tick),
zasadami trzymania chunków w pamięci lub ich rozładowywania.
Samo „jak wygląda góra” czy „gdzie jest biom sawanna” pochodzi w ogromnej większości z kodu Mojang, ale to, jak płynnie ten świat powstaje i zachowuje się podczas eksploracji, to już zasługa (albo wina) konkretnego forka.
Standardowy generator świata – chunk, sekcje i populacja
Kluczowym pojęciem jest chunk – obszar 16×16 bloków w poziomie, rozcięty na pionowe sekcje (w nowych wersjach świata od głębokiego y-64 aż po wysoki sufit, zwykle do y 320). Serwer musi:
Stworzyć pusty chunk (albo załadować istniejący z dysku).
Wypełnić go blokami: teren, woda, jaskinie, rudę.
Populować: roślinność, jeziora lawy, drzewa, struktury, spawnery w dungeonach.
Zapisać zmiany na dysku, gdy chunk nie jest już aktywnie używany.
Ta sekwencja zawsze istnieje, niezależnie czy używasz Spigota, Papera czy Purpura. Różnica tkwi w szczegółach:
czy chunk jest generowany synchronicznie na głównym wątku (lag podczas eksploracji),
czy część pracy da się przerzucić na inne wątki (asynchronicznie),
jak agresywnie serwer czyści pamięć z nieużywanych chunków,
jak duże „batch’e” chunków są obrabiane na tick.
Co dziedziczy każdy fork po Spigocie, a co dodaje od siebie
Spigot jest bazą dla Papera, a Paper dla Purpura. W uproszczeniu:
Spigot – lekkie optymalizacje względem vanilli, minimalne ingerencje w sam wygląd świata, prosta konfiguracja.
Paper – agresywniejsze usprawnienia wydajności, asynchroniczne i zbatchowane operacje na chunkach, rozszerzone API do generatorów.
Purpur – Paper + ogrom rozszerzonych opcji gameplay i szczegółowa kontrola nad zachowaniem świata, mobów i struktur.
Dominujący cel tych forków to nie „zmienić świat na inny”, ale sprawić, żeby ten sam świat był generowany i obsługiwany szybciej, stabilniej i z większą kontrolą. Purpur dodaje do tego jeszcze warstwę „serwerowego balansu” – można zmusić świat, by reagował wyraźnie inaczej na gracza.
Dlaczego w ogóle ruszać generowanie świata
Admini grzebią w generowaniu świata z kilku powodów:
Wydajność – serwer ginie przy locie na elytrze po świeżo generowanym świecie, TPS spada, gracze widzą „void” przed sobą.
Kontrola – ograniczenie eksploracji (np. przez pre-generację i blokady granic), panowanie nad ilością struktur czy mobów.
Balans – wpływ na gęstość rud, spawn mobów w określonych biomach, wyłączenie niektórych farm „eksploatujących” mechanikę chunków.
Estetyka i klimat – integracja z custom generatorami (RTP, świat RPG), inne tempo narastania struktur, inne rozmieszczenie mobów.
Właśnie tu zaczynają się realne różnice między Spigotem, Paperem i Purpurem. O ile sam kształt gór i oceanów pozostaje ten sam, o tyle Twoje doświadczenie z eksploracji i to, jak mapa „oddycha”, potrafi mocno się zmienić między tymi silnikami.
Spigot jako punkt odniesienia – jak generuje świat
Spigot vs vanilla: gdzie są ingerencje w generator
Spigot startuje z kodu Mojang, ale nakłada na niego swoje usprawnienia. W generowaniu świata:
Nie zmienia algorytmu kształtu świata – biome layout, typy struktur, podstawowe zasady generacji biomów pozostają takie same jak w vanilla.
Dodaje ograniczenia czasowe – ile zadań związanych z chunkami może zostać wykonanych na tick.
Optymalizuje IO – nieco lepiej zarządza zapisem i odczytem chunków z dysku.
Dzięki temu świat na Spigocie wygląda dla gracza praktycznie identycznie jak na serwerze Mojang, ale serwer ma mniejszą tendencję do dramatycznych lagów przy nagłym skoku aktywności (np. kilku graczy lecących na elytrze w różnych kierunkach).
Domyślne zachowanie przy ładowaniu i zapisywaniu chunków
Spigot utrzymuje chunk w pamięci dopóki jest w zasięgu view-distance gracza lub wymaga tego logika gry (np. redstone, tile entity). Po spełnieniu warunków:
chunk jest oznaczany jako kandydat do rozładowania,
w odpowiednim momencie jest zapisywany na dysk,
następnie usuwany z pamięci.
Generowanie nowych chunków odbywa się synchronicznie: gdy gracz wchodzi w obszar nieistniejącego chunka, serwer musi wykonać generację na głównym wątku, zanim klient zobaczy teren. Przy małej liczbie graczy i niewielkiej eksploracji nie jest to problem, ale przy większej skali serwer potrafi „zamarzać” przy gwałtownym odkrywaniu mapy.
Kluczowe parametry w spigot.yml i bukkit.yml wpływające na świat
Spigot nie ma dedykowanego pliku do generowania świata jak Paper, ale kilka ustawień w spigot.yml i bukkit.yml pośrednio wpływa na sposób, w jaki świat się „zachowuje”:
view-distance (bukkit.yml) – ile chunków w każdą stronę serwer będzie utrzymywał wokół gracza. Im więcej, tym większe obciążenie generowaniem i ładowaniem.
simulation-distance (w nowszych wersjach) – ile chunków jest aktywnie symulowanych (ticking), co wpływa na spawny mobów, wzrost roślin, działanie farm.
ticks-per w bukkit.yml (np. ticks-per.monster-spawns, ticks-per.animal-spawns) – jak często wykonywane są określone typy działań w świecie, co przekłada się na obciążenie związane z populacją.
entity-activation-range i entity-tracking-range (spigot.yml) – jak daleko od gracza serwer będzie śledził i aktywował moby, co wiąże się też z liczbą aktywnych chunków.
Te parametry nie zmieniają samego algorytmu generowania, ale mocno wpływają na to, jak wiele chunków musi być w danym momencie aktywnych, a więc jak często serwer musi je tworzyć, ładować i populować.
Skutki dla wydajności i odczucia gracza
Spigot jest stabilniejszy niż vanilla przy standardowej rozgrywce survivalowej, jednak:
przy dużej eksploracji, elytrach, fast-travelach w Netherze – chunk generation dalej blokuje główny wątek,
nie ma tak agresywnych optymalizacji jak Paper w kwestii kolejkowania i batchowania chunków,
nie oferuje per-światowej konfiguracji generowania czy zaawansowanych limitów populacji.
Spigot to rozsądny punkt wyjścia, ale przy serwerach publicznych, dużych SMP czy projektach RPG, Paper i Purpur wchodzą do gry właśnie na poziomie generowania i obsługi świata.
Jak Paper modyfikuje generowanie świata względem Spigota
Kierunek zmian: ta sama mapa, inna wydajność
Paper ma jedną główną ideę: świat ma wyglądać i generować się jak w vanilli, ale serwer powinien radzić sobie z obciążeniem dużo lepiej. Chodzi tu zarówno o pierwsze generowanie chunków, jak i ich późniejsze ładowanie, zapisywanie oraz populację.
W praktyce Paper:
przenosi część logiki dot. chunków do asynchronicznych wątków,
wprowadza mechanizmy kolejkowania zadań chunków i ich grupowego przetwarzania,
pozwala kontrolować ilość chunków generowanych/ładowanych na tick,
udostępnia per-world konfigurację, co daje możliwość precyzyjnego zachowania dla każdego świata.
Async i parallel chunk loading – co faktycznie jest asynchroniczne
W teorii „asynchroniczne generowanie chunków” brzmi jak magia, jednak w praktyce wygląda to tak:
Część czynności związanych z ładowaniem chunków z dysku i przygotowaniem danych może działać poza głównym wątkiem.
Nie cała generacja (wypełnianie blokami, struktury) jest w pełni asynchroniczna – trzon musi nadal przejść przez wątek główny ze względu na bezpieczeństwo danych i API.
Paper organizuje te zadania w kolejki i „batch’e”, dzięki czemu główny wątek nie jest blokowany jednym dużym zadaniem, tylko większą liczbą mniejszych porcji pracy.
Efekt z perspektywy gracza:
mniej gwałtownych przycięć przy doczytywaniu chunków,
płynniejsze wczytywanie terenu przed lecącym graczem,
łatwiejsze skalowanie na większą liczbę graczy eksplorujących świat równocześnie.
Caching, batching i ograniczanie populacji świata
Kolejna różnica to sposób, w jaki Paper zarządza „zadaniami chunków”. Zamiast generować, populować i zapisywać każdy chunk osobno i natychmiast, Paper:
buforuje zadania generacji/ładowania chunków i wykonuje je paczkami,
kontroluje ilość chunków przetwarzanych na tick (np. max-chunk-sends-per-tick),
pozwala zmniejszyć częstotliwość niektórych działań populacji (np. generowanie struktur, dekoracje roślinne w niektórych sytuacjach).
Taki model działania oznacza, że serwer lepiej znosi „pikowe” obciążenia – zamiast próbować natychmiast przetworzyć 200 chunków generowanych przez pięciu graczy, rozciąga pracę na kilka ticków, trzymając TPS bliżej 20.
Rozszerzone API generatorów światów w Paperze
Paper dodaje też istotne zmiany w API, z których korzystają pluginy od generatorów światów:
lepsze wsparcie dla niestandardowych generatorów chunków,
możliwość kontrolowania pewnych aspektów generacji w hookach „pre” i „post” (przed i po generacji),
dodatkowe eventy, które pozwalają np. anulować populację chunku lub ją modyfikować.
Dzięki temu pluginy typu RPG world generator, niestandardowe światy Skyblock czy ułożone pod serwer minigier, działają stabilniej i wydajniej na Paperze niż na czystym Spigocie. Ma to znaczenie szczególnie tam, gdzie świat jest częścią rozgrywki, a nie tylko „tłem”.
Czym dokładnie wyróżnia się Purpur w generowaniu świata
Purpur jako „konfigurowalny Paper” z naciskiem na gameplay
Purpur startuje z kodu Papera, a następnie dodaje masę opcji konfiguracyjnych, z których wiele dotyczy właśnie świata. Sam algorytm generowania terenu nadal bazuje na Mojang + optymalizacje Papera, ale Purpur:
daje więcej przełączników dotyczących spawnów, struktur, zachowania bloków i entity,
pozwala granulatowo zmieniać zachowanie świata per-świat, często nawet per-biome,
wprowadza dodatkowe limity i zasady, których Paper nie oferuje „out of the box”.
Cel Purpura nie jest tylko wydajnościowy. Chodzi o to, by admin miał pełną władzę nad zachowaniem świata bez potrzeby pisania custom pluginów na wszystko.
Dodatkowe parametry w purpur.yml i per-world settings
Plik purpur.yml jest znacznie większy niż standardowy paper.yml. W kontekście generowania świata i chunków znajdziesz tam m.in.:
zaawansowane ustawienia spawnów mobów (np. różne kapy, odległości, zachowania w poszczególnych wymiarach),
przełączniki dotyczące generowania i częstotliwości struktur (np. twierdze w Netherze, end cities, struktury w Overworldzie),
opcje modyfikujące zachowanie bloków wpływających na wydajność (np. zasięg rozchodzenia się płynów, częstotliwość tików redstone),
reguły dotyczące farm, grinderów i mob switchy (np. twarde limity na liczbę entity w chunku, agresywne despawnowanie, osobne ustawienia dla mobów z jajek, spawnerów czy naturalnych).
Do tego Purpur rozwija koncepcję ustawień per-świat, łącząc je z konfiguracją Papera. Można zbudować świat „farmowy” z bardzo agresywną optymalizacją (małe zasięgi śledzenia, niskie kapy mobów, ucięte generowanie części struktur), obok świata survivalowego o dużo bardziej „vanillowym” charakterze. Dla serwerów lobby czy minigier praktyczne jest wręcz wyłączenie części elementów populacji świata bez pisania pluginu.
Wpływ na stabilność i kompatybilność generatorów
Ponieważ Purpur bazuje na Paperze, większość generatorów świata, które wspierają Paper, działa na nim bez zmian. Problem może się pojawić dopiero przy bardzo agresywnych zmianach w purpur.yml, gdy admin wyłączy lub ograniczy mechanizmy, na których dany generator polega (np. specyficzne zachowania populacji, limity entity, niestandardowe tikowanie bloków). Dobrym nawykiem jest:
najpierw uruchomić generator na „czystym” Paperze,
dopiero potem krokowo włączać zmiany z Purpura i obserwować świat w praktyce,
testować zwłaszcza netherowe i endowe struktury oraz wszelkie custom biomy.
Przy rozsądnym podejściu Purpur nie psuje generatorów, tylko daje więcej dźwigni do strojenia serwera pod konkretny styl gry: od hardcorowego survivalu z mocno przyciętymi farmami po serwery RPG z dużą ilością dekoracyjnych mobów, ale ograniczoną aktywnością w niewidocznych chunkach.
Dobrze ustawiony Spigot zapewnia stabilną bazę, Paper wyciska z niej dużo więcej wydajności na etapie generowania i obsługi chunków, a Purpur pozwala jeszcze „dokręcić śrubki” pod własne potrzeby. Świadome wykorzystanie tych różnic daje w efekcie świat, który nie tylko wygląda jak w vanilli, ale też zachowuje się dokładnie tak, jak wymaga tego konkretny serwer i jego społeczność.
Generowanie chunków – ładowanie, tworzenie, populacja (Spigot vs Paper vs Purpur)
Cykl życia chunku w praktyce
Niezależnie od silnika, chunk przechodzi podobny cykl:
Żądanie chunku – gracz zbliża się, plugin prosi o dostęp lub system spawnów musi znać zawartość obszaru.
Ładowanie z dysku – jeśli chunk istnieje w plikach, serwer odczytuje go i deserializuje.
Generacja – gdy chunk nie istnieje, uruchamia się generator terenu (biomy, szum, powierzchnia, jaskinie itd.).
Populacja – dekoracje, struktury, rudy, drzewka, jeziora lawy i wody, rośliny.
Zapis / wyładowanie – chunk znika z pamięci, stan ląduje na dysku (lub w kolejce do zapisu).
Różnice między Spigotem, Paperem i Purpurem wynikają głównie z tego, jak te etapy są planowane, kolejkowane i ograniczane.
Ładowanie chunków z dysku
Spigot ma prosty model: chunk jest potrzebny – chunk jest ładowany. Im więcej graczy na granicach mapy, tym większa szansa na blokady I/O.
Spigot – odczyty w dużej mierze synchroniczne, dłuższe „piki” przy masowym przemieszczaniu się graczy.
Paper – część logiki I/O przeniesiona do wątków roboczych, chunk trafia do głównego wątku „przygotowany”. Zmniejsza to czas, kiedy główny wątek czeka na dysk.
Purpur – korzysta z modelu Papera, ale pozwala inaczej dociąć pozostałe etapy (np. agresywniejsze wyładowywanie i limity entity), przez co realne obciążenie I/O bywa niższe.
Na serwerach z dużą mapą i wolniejszym dyskiem HDD przejście z czystego Spigota na Papera daje często zauważalny spadek krótkich, losowych lagów przy teleportach i lataniu.
Generowanie nowych chunków
Tu różnice jeszcze wyraźniej wpływają na odczucia graczy:
Spigot – generacja mocno sklejona z wątkiem głównym. Gdy kilku graczy wyleci elytrami w „nieznane”, serwer może mieć serie przycięć.
Paper – generacja rozbita na mniejsze porcje i lepiej rozplanowana; część przygotowania chunku odbywa się asynchronicznie, a sam proces jest limitowany parametrami w konfiguracji.
Purpur – ten sam podstawowy kod co Paper, ale ze szerszym zestawem bezpieczników: można zmniejszyć agresywność generowania, ograniczyć niektóre elementy populacji, dostosować kapy mobów w świeżych chunkach.
Przy mapach RPG, gdzie gracze nie „lecą w nieskończoność”, ale intensywnie eksplorują w promieniu kilku tysięcy bloków, dobrze ustawiony Paper często wystarcza. Przy publicznym survivalu z kilkoma setkami aktywnych graczy Purpur pomaga „przyciąć” najbardziej obciążające elementy świeżych chunków bez psucia wyglądu świata.
Populacja – struktury, rudy, dekoracje
Populacja chunków jest kosztowna, bo angażuje wiele drobnych operacji. Tu widać podejście każdego z silników:
Spigot – bardzo blisko vanilli. Ograniczenia wynikają głównie z configu bukkit.yml / spigot.yml (np. zasięgi, limity potworów), ale sam proces populacji jest niemal nietknięty.
Paper – optymalizuje scenariusze, w których populacja byłaby uruchamiana wielokrotnie lub niepotrzebnie. Oferuje też parametry, które kontrolują tempo populacji przy dużym obciążeniu.
Purpur – dodaje przełączniki specyficzne dla elementów populacji (np. osobne limity struktur, możliwość „wycięcia” części dekoracji w określonych światach lub biomach).
Dobrym przykładem jest Nether z dużą liczbą fortec. Na Spigocie generuje się je dokładnie wg zasad Mojang. Paper pozwala zarządzać wydajnością przy ich generowaniu. Purpur daje jeszcze możliwość ograniczenia lub zmiany częstości struktur na poziomie konfiguracji, jeżeli admin chce od razu przyciąć wydajnościowo najbardziej „ciężkie” elementy.
Wyładowywanie chunków i zapisywanie zmian
Ostatni etap to moment, kiedy chunk wypada z pamięci. Dla wydajności znów kluczowe są szczegóły:
Spigot – chunk jest zapisywany i wyładowywany zgodnie z prostym harmonogramem. Przy dużej liczbie zmian (farmy, masowe budowanie, TNT) potrafi to generować sporą presję na I/O w krótkim czasie.
Paper – reorganizuje zapisy, grupuje je i stara się ograniczyć ich „szczyty”. Dawkuje też wyładowania chunków, aby uniknąć sytuacji, w której jednocześnie znika ich zbyt wiele.
Purpur – umożliwia m.in. agresywniejsze czyszczenie nieużywanych chunków i cięcie ilości entity przed ich zapisem. W połączeniu z odpowiednim limitem mobów daje to znacznie lżejsze zapisy.
Na praktycznym przykładzie: serwer survival z dużą farmą żelaza w oddalonym świecie technicznym na Spigocie potrafi mieć nierówne czasy zapisu regionów. Po migracji na Papera i lekkim „docięciu” ustawień wyładowywania chunków, problem zwykle zanika bez ingerencji w samą farmę. Purpur pozwoliłby jeszcze ograniczyć ilość zombi w chunkach farmy, dodatkowo odciążając zapis.
Ustawienia generowania świata w konfiguracjach – spigot.yml, paper.yml, paper-world-defaults, purpur.yml
spigot.yml – podstawowe hamulce i przyspieszacze
W spigot.yml świat dotykają głównie ustawienia pośrednio związane z generacją i obsługą chunków. Do kluczowych należą:
view-distance (czasem także w server.properties) – ile chunków w promieniu gracza musi być załadowanych; im większy promień, tym więcej generacji i ładowania.
entity-activation-range – zasięg aktywacji mobów, wpływa na to, ile entity w świeżo wygenerowanych chunkach faktycznie „żyje” i jest tickowane.
ticks-per (np. ticks-per.monster-spawns, ticks-per.water-spawns) – pośrednio powiązane z tym, jak często świat „próbkuje” nowe spawny w chunkach.
mob-spawn-range – ile chunków od gracza jest brane pod uwagę przy spawnach; mniejsza wartość to mniejsza presja na generowanie i ładowanie okolicy.
Te parametry nie zmieniają samego algorytmu generacji terenu, ale kształtują realny koszt „żyjącego” świata. Na małym serwerze survival wystarczy zwykle rozsądnie zbić view-distance i dopasować entity-activation-range, aby spadki TPS przy eksploracji były marginalne.
paper.yml – sterowanie obciążeniem chunków
paper.yml jest zdecydowanie bogatszy pod kątem świata. W kontekście generacji i obsługi chunków często używa się:
max-auto-save-chunks-per-tick – ile chunków może być zapisywanych w jednym ticku; ustawienie zbyt wysokie generuje „piki”, zbyt niskie – opóźnia zapis przy ogromnych mapach.
chunk-loading (lub podobne sekcje zależnie od wersji) – limity chunków ładowanych oraz generowanych na tick.
despawn-ranges i entity-per-chunk-save-limit – pośrednio wpływają na koszt populacji oraz zapisów.
optimize-explosions, use-faster-eigencraft-redstone – nie są stricte „generacyjne”, ale mocno redukują koszt świata w chunkach z ciężkim redstone i TNT.
Prosty schemat przy przejściu ze Spigota na Papera:
Przenieść config z domyślnymi wartościami Papera.
Obniżyć nieco max-auto-save-chunks-per-tick, jeśli widać piki lagów przy zapisie.
Ustawić konserwatywne limity ładowania/generowania chunków na tick.
Stopniowo luzować te limity, obserwując TPS i zachowanie przy eksploracji.
paper-world-defaults i per-world konfiguracja
paper-world-defaults pozwala ustawić „szablon” dla światów, ale też indywidualnie dociąć każdy wymiar. To kluczowe, gdy Overworld, Nether i End służą różnym celom.
Typowe zastosowania:
Overworld – bardziej „vanilla”, normalne zasięgi i spawn mobów, umiarkowane limity chunków na tick.
End farmowy – bardzo niskie zasięgi śledzenia i aktywacji entity, mocno docięte spawny, ale wysoki priorytet zapisu, by nie tracić progresu farm.
Zamiast jednego kompromisu „dla całego serwera”, admin ma zestaw pokręteł dla każdego świata, co wprost przekłada się na to, jak świat generuje i obsługuje nowe obszary pod obciążeniem.
purpur.yml – „panel sterowania” generacją i populacją
purpur.yml idzie krok dalej niż Paper i dotyka wielu elementów, które w Spigocie/Paperze wymagałyby pluginu. W części światowej spotkasz m.in.:
szczegółowe limity entity per typ, często per-świat, a nawet z podziałem na źródło (spawner, naturalny spawn, jajko),
opcje typu „disable-xyz” dla konkretnych cech generacji lub zachowań bloków, które mocno obciążają CPU lub I/O,
ustawienia spawnów w stylu „no-phantoms-in-dimension” albo ograniczenia spawnów w określonych biomach,
modyfikatory rozchodzenia się płynów, zasięgów redstone, prędkości tikowania określonych bloków.
Przykładowe podejście do konfiguracji Purpura na dużym SMP:
Skopiować stabilną konfigurację Papera.
Wyłączyć najbardziej zbędne elementy w światach lobby (np. część spawnów, twarde limity entity).
W świecie farmowym ustawić agresywne despawny i capy mobów w chunku.
Overworld zostawić bliżej vanilli, zmieniając głównie parametry jakości życia (np. zachowania łóżek, portali), bez grzebania w generacji terenu.
Taki podział sprawia, że „ciężkie” światy techniczne są maksymalnie tanie w utrzymaniu, a światy survivalowe nie cierpią na zbyt agresywne optymalizacje, które psułyby klimat.
Spawn i rozkład mobów a generowanie świata
Dlaczego spawny tak mocno obciążają generację
Silnik mobów stale pyta świat: „gdzie mogę postawić nowego moba?”. Jeżeli w zasięgu gracza brakuje odpowiednich miejsc (np. wszystko zalane, oświetlone, zabudowane), logika spawnów zaczyna „szukać dalej”. W praktyce oznacza to:
konieczność trzymania większego promienia chunków w pamięci,
częstsze żądania generacji chunków w okolicy, jeżeli gracze przesuwają się po granicach mapy,
wzrost kosztu obliczeń przy każdej próbie spawnu.
Im większy mob-spawn-range i im bardziej surowy świat (np. dużo ciemnych jaskiń), tym intensywniej spawny „ciągną” generację w nowe miejsca.
Spigot – proste limity, proste konsekwencje
Spigot w bukkit.yml i spigot.yml pozwala określić:
ticks-per.*-spawns – jak często próbuje się nowe spawny danego typu,
mob-spawn-range – w ilu chunkach od gracza podejmować próby spawnu.
Zmniejszenie mob-spawn-range i lekkie przycięcie spawn-limits powoduje, że serwer:
rzadziej sięga po chunk „daleko na granicy widoczności”,
rzadziej generuje zupełnie nowe chunki tylko po to, by dodać kilka mobów.
Na typowym survivalu często wystarcza obniżenie mob-spawn-range o 1–2 jednostki względem vanilli, by zauważyć spadek ilości sytuacji, gdzie generacja nagle przyspiesza przez „gonienie” spawnów.
Paper – inteligentniejsze zarządzanie spawnami
Paper rozwija temat, dodając m.in.:
bardziej elastyczne despawn-ranges – duża ilość mobów w dalekich chunkach nie musi blokować slotów spawnów bliżej graczy,
dodatkowe parametry kontroli ilości mobów per chunk czy per typ,
mechanizmy priorytetyzacji spawnów bliżej graczy, co zmniejsza presję na utrzymywanie dalekich chunków w pamięci,
ograniczanie liczby prób spawnu na tick oraz lepsze zarządzanie „burstami” mobów, np. przy farmach.
Dobrze ustawiony Paper potrafi utrzymać wysoką ilość mobów w aktywnej bazie, jednocześnie nie zasysając w nieskończoność kolejnych chunków na obrzeżach. Działa to szczególnie dobrze, gdy połączysz rozsądne despawn-ranges z umiarkowanym mob-spawn-range i niezbyt agresywnymi limitami per typ moba. W praktyce serwer mniej „skacze” po mapie, a bardziej skupia się na obszarze faktycznie używanym przez graczy.
Przy migracji ze Spigota na Papera opłaca się zacząć od domyślnych wartości i dopiero potem dociąć spawn-limits i despawn-ranges w światach technicznych. W survivalu lepiej ruszać te parametry ostrożnie, bo zbyt niskie limity szybko zabiją klimat jaskiń i nocy. Dobrą metodą jest tworzenie profili: inny zestaw ustawień dla Overworlda graczy, inny dla „świata farm”, jeszcze inny dla lobby.
Purpur – pełna kontrola nad ekosystemem mobów
Purpur dorzuca do tego bardzo szczegółowe pokrętła: limity per-typ i per-świat, osobne limity dla mobów ze spawnerów, naturalnych, z jajek czy komend. Możesz praktycznie wyłączyć naturalne spawny w lobby, przyciąć agresywnie moby ze spawnerów w świecie farmowym i zostawić prawie wanilliowy rozkład w Overworldzie survivalowym. To bezpośrednio odbija się na tym, ile chunków musi być stale aktywnych i jak często silnik dorzuca nowe generowane obszary.
W konfiguracji Purpura dobrze działa prosty schemat:
w światach „ozdobnych” (lobby, hub) – minimalne spawny, twarde limity na chunk, wręcz wyłączone niektóre typy mobów,
w światach technicznych – bardzo niskie limity dla mobów naturalnych, czytelne capy na moby ze spawnerów, ograniczone mob-spawn-range,
w głównym survivalu – tylko lekkie korekty, głównie przeciw nadprodukcji konkretnych typów mobów (np. ryb, netherowych potworów w farmach złota).
Dzięki temu generacja świata nie jest sztucznie napędzana przez farmy i „puste” spawny w dalekich chunkach, a tam, gdzie gracze rzeczywiście grają, rozkład mobów nadal wygląda naturalnie. Serwer po prostu przestaje marnować ticki na podtrzymywanie ekosystemu tam, gdzie nikt nie zagląda.
Świat generowany przez Spigota, Papera i Purpura może wyglądać niemal identycznie, ale inaczej zachowa się pod obciążeniem, inaczej będzie dociążał CPU i dysk, a także inaczej rozłoży moby w przestrzeni. Świadome użycie dostępnych przełączników – od view-distance, przez limity chunków na tick, po szczegółowe capy mobów – pozwala dopasować serwer do konkretnego stylu gry zamiast walczyć z lagami dopiero po fakcie.
Praktyczne profile konfiguracji – różne silniki, różne światy
Świat survivalowy z eksploracją – „blisko vanilli”
W świecie nastawionym na eksplorację i budowanie lepiej nie przesadzać z cięciami, bo gracze szybko poczują sztuczność świata. Dobrze sprawdza się podejście:
Spigot – lekko obniżony view-distance i mob-spawn-range, standardowe limity generacji chunków na tick,
Paper – domyślne ustawienia z delikatnie niższymi limitami max-chunk-sends-per-tick i max-chunk-loads-per-tick, brak agresywnego przycinania aktywnych chunków,
Purpur – większość opcji generacji terenu i spawnów zostawiona podobnie do Papera, włączone tylko „jakości życia” (np. zachowanie portali, minimalne limity specyficznych mobów jak ryby czy nietoperze).
Taki profil trzyma generację w ryzach (brak gigantycznych „wystrzałów” TPS przy locie elytrą), a jednocześnie nie miesza się mocno w strukturę i gęstość świata. Gracze widzą praktycznie wanilliowy teren, ale serwer nie dławi się przy każdym większym wypadzie w nieznane.
Świat techniczny / farmowy – „maksymalna dyscyplina chunków”
W świecie farmowym generacja świata i rozkład mobów mają służyć jednemu celowi: wydajności. Wygląd terenu schodzi na dalszy plan. Typowy pakiet zmian:
Spigot – bardzo niski view-distance, obniżony simulation-distance (jeśli na warstwie hostingu), małe mob-spawn-range i wyraźnie przycięte spawn-limits,
Paper – mocno zredukowane limity generacji i ładowania chunków na tick, niższe limity entity na świat, agresywne despawn-ranges dla większości mobów,
Purpur – twarde capy na moby ze spawnerów, ograniczenia spawnów w konkretnych wymiarach i biomach, wyłączone zbędne mechaniki (np. niektóre random-ticki dla rzadko używanych bloków).
Dobrą praktyką jest ręczne wygenerowanie obszaru używanego przez farmy (pregeneracja) i „zamknięcie” dalszej generacji, np. pluginem blokującym wychodzenie poza określony promień. Wtedy Spigot/Paper/Purpur nie muszą już praktycznie niczego nowego generować, a cała zabawa toczy się w obrębie istniejących chunków.
Lobby / hub – dekoracja z minimalną generacją
Lobby zwykle nie potrzebuje aktywnej generacji ani dynamicznego ekosystemu mobów. Z punktu widzenia silnika to idealny kandydat na „świat statyczny”.
Paper – minimalne limity chunków do ładowania/generacji (bo mapa jest gotowa), wyłączone lub ograniczone autosave chunków, jeśli backupy robi panel/hosting,
Purpur – wyłączone naturalne spawny, twarde capy entity, opcje „no-phantoms”, „disable-wandering-trader” itd. ustawione na blokadę.
Takie ustawienia powodują, że lobby praktycznie nie generuje nowych chunków i nie wykonuje drogich operacji na świecie. Jego koszt sprowadza się głównie do obsługi graczy (ruch, GUI, komendy), a nie samego terenu.
Źródło: Pexels | Autor: panumas nikhomkhai
Różnice w debugowaniu i monitorowaniu generacji świata
Logi i informacje diagnostyczne w Spigocie
Spigot skupia się na podstawowych logach. Przy problemach z generacją świata można liczyć przede wszystkim na:
ogólne logi błędów przy ładowaniu/generowaniu chunków,
ostrzeżenia o przeciążeniu głównego wątku,
proste dane z komend typu /timings (jeśli włączone).
Do diagnozy problemów z generacją (np. nagłe piki przy eksploracji) zwykle dochodzi jeszcze plugin profilujący lub zewnętrzne narzędzia. Sam Spigot rzadko podaje wprost, że „chunk generation” jest głównym winowajcą – widać to pośrednio w timingsach.
Rozszerzone timings i narzędzia w Paperze
Paper dodaje rozbudowaną sekcję timings, która wyraźniej pokazuje:
czas spędzany na generacji chunków vs ich ładowaniu,
wpływ flushowania danych na dysk,
koszt poszczególnych etapów populacji chunków (np. dekoracje, struktury).
Dzięki temu łatwiej sprawdzić, czy to faktyczna generacja nowego terenu „zabija” ticki, czy raczej zapis tysięcy zmodyfikowanych chunków. Paper ma też kilka komend i debug-flag, które pozwalają tymczasowo spowolnić generację albo ją „przesunąć” (np. przez modyfikację limitów per tick), by zobaczyć reakcję serwera.
Drobiazgowa obserwacja zachowań w Purpurze
Purpur często rozwija mechanizmy debugowania Papera, dodając własne przełączniki. W części dotyczącej świata i mobów można spotkać m.in.:
dodatkowe wpisy debug-logów dla specyficznych typów spawnów,
większą szczegółowość w raportach timings dla niestandardowych funkcji,
opcje tymczasowego logowania niektórych operacji na chunkach (np. nietypowe unloady).
Przy złożonych konfiguracjach (różne capy mobów, ograniczenia spawnów per biom) te logi bywają jedynym miejscem, gdzie jasno widać, dlaczego dany obszar nagle „wysuszył się” ze spawnów lub dlaczego chunk nie chce się rozładować.
Wpływ pluginów na generację w zależności od silnika
Pluginy generatorów światów na Spigocie
Na czystym Spigocie każdy plugin wchodzący w generację (niestandardowe biomy, nowe struktury, całkowicie inne światy) wykonuje zwykle sporo pracy w głównym wątku. Jeżeli dodatkowo:
kilku graczy jednocześnie eksploruje różne kierunki,
plugin dorzuca ciężkie struktury i dodatkowe dekoracje,
to serwer szybko wpada w zauważalne spadki TPS. Spigot nie daje tu zbyt wielu natywnych opcji, by tę pracę „rozsmarować” po czasie czy przenieść do wątków pomocniczych, więc główną dźwignią staje się ograniczenie eksploracji lub pregeneracja całego mapy.
Pluginy generujące teren na Paperze
Paper zapewnia lepiej zoptymalizowane API i wewnętrzne ścieżki generacji. Niektóre pluginy potrafią:
wykorzystać asynchroniczne elementy generowania danych wstępnych,
lepiej współpracować z limitami max-chunk-generation i max-chunk-loads,
używać mechanizmów cache’owania chunków przez Papera.
W praktyce ten sam generator świata potrafi na Paperze zachowywać się znacznie stabilniej niż na Spigocie, bo silnik lepiej kontroluje „wybuchy” generacji. Nadal jednak pluginy intensywnie modyfikujące każdy generowany chunk mogą wymagać regulacji limitów per tick, by uniknąć micro-freezów.
Generatory i modyfikatory w Purpurze
Purpur nie zmienia podstawowego API dla pluginów w tyle, by łamać kompatybilność, ale sposób, w jaki świat jest zarządzany (limity entity, ograniczenia spawnów, specyficzne zachowania bloków), wpływa na działanie wielu pluginów:
plugin liczący na określoną ilość spawnów w chunku może „przegrać” z agresywnymi capami Purpura,
generator struktur bazujący na konkretnych typach bloków / warunkach światła może trafić na „podcięte” zachowania (np. zmienione tikowanie bloków),
zbyt ostre cięcia despawnów potrafią złamać logikę pluginów symulujących „żyjące” miasta czy NPC.
Przed wdrożeniem skomplikowanego generatora warto przetestować go na domyślnych ustawieniach Purpura, a dopiero potem dokładać agresywne optymalizacje w purpur.yml. Odwrotna kolejność często kończy się dziwnymi, trudnymi do odtworzenia bugami.
Strategie migracji między silnikami a istniejącymi światami
Przejście ze Spigota na Papera bez psucia świata
Migracja samego silnika nie zmienia istniejących chunków – świat wizualnie pozostanie taki sam. Problem pojawia się na granicy starych i nowych obszarów, zwłaszcza po większych aktualizacjach Minecrafta. Kilka kroków, które ułatwiają życie:
przed zmianą zrobić pełny backup folderów world, world_nether, world_the_end,
po uruchomieniu na Paperze nie włączać od razu radykalnych limitów generacji – najpierw sprawdzić, jak serwer znosi typową eksplorację,
w razie potrzeby ustalić „strefę buforową”, w której pregenerujesz nowe chunki już na Paperze, tak aby granica wersji/generatora była dalej od baz graczy.
W praktyce dobrze działa podejście: najpierw przejście „1:1” z minimalnymi zmianami konfiguracji, dopiero po kilku dniach gry – korekta limitów chunków, spawnów i odległości widzenia.
Dodanie Purpura na istniejący świat Paper/Spigot
Purpur jest forkiem Papera, więc migracja z Papera bywa prawie bezbolesna – różnice leżą głównie w dodatkowych opcjach. Przy przejściu ze Spigota trzeba natomiast pamiętać, że:
Purpur zakłada obecność i logikę Papera – dotychczasowa konfiguracja Spigota może nie pokrywać wielu nowych przełączników,
domyślne ustawienia Purpura mogą inaczej traktować część spawnów i zachowań bloków,
pluginy zależne od specyficznych „niedoróbek” Spigota mogą zachowywać się inaczej.
Bezpieczna ścieżka:
Uruchomić Purpura z wygenerowaniem nowych konfiguracji, nie ruszać purpur.yml poza absolutnym minimum.
Sprawdzić w praktyce: farmy mobów, generatory świata, zachowanie struktur, wydajność przy typowej eksploracji.
Dopiero potem zacząć włączać „smaczki” Purpura – wyłączenia mobów, zmiany capów, modyfikacje zachowań bloków.
Im starszy świat i im więcej „wynalazków” technicznych zbudowali gracze, tym ostrożniej trzeba dawkuwać nowe opcje Purpura. Każda zmiana wpływająca na spawn, despawn albo aktywność chunków może realnie zmienić wydajność lub działanie istniejących konstrukcji.
Świadome kształtowanie granic świata
Border świata a wydajność generowania
Ścisłe granice świata (WorldBorder, regiony pluginów, własne skrypty) mają ogromny wpływ na to, jak silnik radzi sobie z generacją. Różnice między silnikami:
Spigot – brak zaawansowanych natywnych mechanizmów kontroli granic, większość logiki przerzuca na pluginy,
Paper – lepsza współpraca z popularnymi pluginami typu WorldBorder i wydajniejsze obchodzenie się z chunkami „tuż przy granicy”,
Purpur – dodatkowe ustawienia spawnów i entity sprawiają, że obszary przy granicy można mocniej „uspokoić”, praktycznie zamrażając tam ekosystem.
Nakładając border ograniczasz nie tylko ilość generowanego terenu, ale także zasięg, w jakim spawny i logika świata muszą „myśleć”. Na Spigocie to często jedyny skuteczny sposób na zatrzymanie lawiny nowych chunków przy dużej ilości graczy latających elytrami. Na Paperze/Purpurze nadal ma sens, ale można sobie pozwolić na większy promień dzięki lepszej kontroli generacji.
Pregeneracja – kiedy ma sens, a kiedy szkodzi
Pregeneracja całego obszaru świata bywa kusząca: „raz się przemęczymy, potem będzie spokój”. Rzeczywistość zależy od silnika:
na Spigocie pomaga uniknąć ciągłego generowania w szczycie, ale może wywołać duże jednorazowe obciążenie i gigantyczny rozrost folderu świata,
Paper lepiej znosi pregenerację dzięki optymalizacjom zapisu i ładowania chunków,
Purpur pozwala dodatkowo „zubożyć” ekosystem w pregenerowanych regionach, jeśli mają pełnić rolę czysto techniczną.
Przy pregeneracji:
Ustaw niski view-distance i brak graczy na serwerze (tryb offline lub whitelist).
Na czas procesu możesz zwiększyć limity generacji chunków na tick, ale pilnuj temperatury CPU i dysku.
Po zakończeniu wróć do normalnych limitów i zrób pełny backup – odtwarzanie uszkodzonego, pregenerowanego świata to koszmar.
Na małych serwerach survivalowych często wystarcza pregeneracja „korytarzy” pod autostradami netherowymi i głównych kierunków eksploracji, zamiast pełnego koła o ogromnym promieniu.
Balans między jakością świata a wydajnością na różnych silnikach
Jak mocno „przycinać” generację na Spigocie
Na Spigocie każdy dodatkowy element świata ma wymierny koszt. Im prościej, tym stabilniej. Przy serwerach publicznych lepiej zrezygnować z części wodotrysków w zamian za stabilne 20 TPS.
Podstawowe zasady przy mocno obciążonych serwerach Spigot:
unikać złożonych custom-generatorów, które dokładają warstwy dekoracji (szczególnie w Overworldzie),
ograniczyć ilość struktur z pluginów – np. rzadsze miasta, mniejsze dungeony, mniej losowych budowli na powierzchni,
unikać generacji wymagającej częstych odwołań do dysku (wczytywanie szablonów struktur z plików przy każdym chunku),
jednoznacznie kontrolować zasięg świata (border) i nie liczyć, że serwer „jakoś przeżyje” masową eksplorację.
Gdy pojawiają się dropy TPS przy generacji nowych terenów, pierwszym krokiem na Spigocie jest uproszczenie świata, a dopiero potem kombinowanie z optymalizacją kodu pluginu.
Paper – gdzie leży realna granica „ładnego” świata
Paper udźwignie więcej: cięższe struktury, większe biomy, bardziej rozbudowane jaskinie. Nadal jednak istnieje punkt, w którym każdy tick generacji staje się problemem. Granicę łatwo rozpoznać w timings – rosnące czasy chunk generation i chunk population.
Rozsądne podejście przy Paperze:
cięższe elementy (rozbudowane struktury, miasta) generować rzadko, ale „konkretnie” – np. co kilkaset bloków,
proste dekoracje (drzewka, kamienie, małe ruinki) przerzucić do tańszych faz populacji, jeśli to możliwe,
trzymać się rozsądnych limitów max-chunk-generation i max-chunk-loads – brak limitów kusi, ale zemści się przy locie elytrą,
testerów prosić o „zajeżdżanie” świata w locie – to najszybszy sposób wychwycenia krytycznych spike’ów generacji.
Jeżeli generator świata korzysta z wielu losowych próbek per chunk (setki sprawdzeń wysokości, biomów, sąsiednich chunków), lepiej ograniczyć promień wpływu takich operacji lub keszować wyniki na większych blokach (np. siatka 4×4 chunków).
Purpur – kiedy agresywne cięcia nie psują klimatu
Purpur zachęca do maksymalnego „odchudzenia” ekosystemu. Kuszące jest drastyczne zejście z capów mobów, wyłączenie części struktur czy mocne cięcia w spawnach. Jeśli świat ma jednak wyglądać naturalnie, lepiej ustawiać te parametry warstwowo.
Sprawdzone kroki przy mocnej optymalizacji Purpura:
Na start tylko lekkie obniżenie globalnych capów i delikatne skrócenie odległości aktywacji mobów.
Obserwacja: jak wygląda „gęstość” świata przy normalnej eksploracji – ile mobów gracza faktycznie otacza.
Dopiero potem celowane cięcia: osobno hostile, osobno passive, osobno wodne i ambient.
Na końcu dopieszczanie generatorów: redukcja spawnów w specyficznych biomach, cięcia w spawnach struktur.
Jeżeli celem jest techniczny serwer z dużą ilością maszynek, Purpur pozwala prawie „wyjałowić” teren poza farmami. Gdy jednak priorytetem jest survival z klimatem, lepiej nie przesadzać – puste lasy i oceany szybko zabijają wrażenie żywego świata.
Diagnostyka problemów z generacją świata na różnych silnikach
Typowe objawy problemów z generacją na Spigocie
Na Spigocie problemy z generacją świata objawiają się głównie jako:
długie przycinki przy pierwszym wejściu gracza w nowy kierunek,
niedoczytywanie świata przed graczem lecącym na elytrze (gracz widzi pustkę lub brak chunków),
nagłe skoki opóźnienia między akcją a reakcją (otwieranie skrzyń, walka).
Podstawowe narzędzia diagnostyczne na Spigocie to:
/timings on / /timings paste – szukanie sekcji związanych z generacją i populacją chunków,
logi z crashy / watchdogów – długie stacktrace’y w funkcjach generatora,
czasowe wyłączanie custom-generatorów i testy na czystym świecie.
Przy pluginowych generatorach dobrym trikiem jest założenie tymczasowego świata testowego z tym samym konfigiem i obciążanie go jednym graczem w locie. Pozwala to odseparować problemy świata od problemów z innymi pluginami.
Czy generacja naprawdę winna? Analiza Papera
Na Paperze konflikt jest często subtelniejszy – generacja sama w sobie jest szybsza, ale wąskim gardłem bywa interakcja z pluginami lub dyskiem. Zanim wini się sam generator, trzeba rozdzielić kilka warstw.
Rzeczy do sprawdzenia w pierwszej kolejności:
sekcja world - chunk task executors w timings – czy nie widnieje jako topowy pożeracz czasu,
czas zapisu chunków na dysk – wysokie wartości sugerują problemy I/O, nie samą generację,
pluginy wywołujące masowo operacje na blokach podczas generacji (np. światła, regiony, logika claimów).
Częsta sytuacja: goły Paper z custom-generatorem trzyma 20 TPS, ale po dołożeniu pluginu regionów/townów generacja zaczyna chrupać. Na logach i timings widać wtedy, że to nie generator, tylko masowe sprawdzanie uprawnień per blok przy populacji chunków.
Purpur i „niewidzialne” skutki zmian w konfiguracji
Na Purpurze kłopotem bywa nie tyle sama generacja terenu, co zmienione zachowania światów i mobów, które modyfikują obciążenie pośrednio. Przykłady:
inne despawny powodują utrzymywanie większej ilości mobów w pamięci w określonych biomy,
zmiana aktywności chunków wokół graczy generuje więcej/natychmiast spawnów w mniejszym obszarze,
modyfikacje zachowania bloków (tiki, rozlewanie cieczy) zmieniają ilość obliczeń w świeżo wygenerowanych jaskiniach.
Do diagnostyki przydają się:
porównanie logów timings między „gołym” Paperem a Purpurem z tym samym zestawem pluginów,
czasowe przywrócenie domyślnego purpur.yml i obserwacja, czy problem zniknie,
odkładanie zmian w Purpurze małymi porcjami, zamiast od razu włączać kilkanaście optymalizacji naraz.
Jeżeli świat po migracji na Purpura „dziwnie się zachowuje” (inne spawny, inne obciążenie, losowe freezy w jaskiniach), pierwszym podejrzanym powinny być ustawienia, a dopiero później sam generator.
Projektowanie nowych światów pod konkretny silnik
Świat pod Spigota – minimalizm i przewidywalność
Świat tworzony z myślą o Spigocie powinien być możliwie przewidywalny. Im mniej wyjątków i wynalazków w generatorze, tym lepiej. Przy publicznym survivalu prostota przekłada się na mniejszą ilość dziwnych bugów na styku pluginów.
Przy projektowaniu generatora na Spigota opłaca się:
trzymać się zbliżonej gęstości struktur do vanilla lub nieco mniejszej,
rezygnować z generacji opartej na intensywnym skanowaniu sąsiednich chunków,
unikać zbyt dużej ilości customowych typów bloków i metadanych – zmniejsza to ilość operacji per blok,
wybrać 1–2 wyróżniki świata (np. specyficzne jaskinie, niestandardowe biomy), zamiast dziesięciu różnych systemów naraz.
Dobry test: kilkukrotny lot elytrą w promieniu kilkunastu tysięcy bloków od spawnu. Jeśli TPS nie zjeżdża, a świat „nadąża”, generator jest akceptowalny dla Spigota.
Świat pod Papera – więcej logiki, ale z głową
Paper pozwala zaszaleć bardziej z logiką generatora. Można wprowadzić:
biomy bazujące na złożonych regułach (wysokość, odległość od centrów, temperatura złożona z kilku funkcji),
większe, wielopoziomowe struktury (podziemne miasta, ogromne jaskinie, customowe dungeony),
dodatkowe etapy populacji chunków zależne od sąsiedztwa.
Mimo tego warto trzymać się kilku zasad:
ciężkie obliczenia robić jak najrzadziej – lepiej używać preobliczonych map noise/bucketów,
nie przeliczać skomplikowanej logiki osobno dla każdego bloku, tylko dla większych segmentów (np. sekcje chunków),
pozostawić możliwość „odchudzenia” konfiguracji – np. niższa gęstość struktur jednym parametrem, bez przebijania się przez kod.
Jeżeli generator ma być publicznie dostępny, dobrym nawykiem jest przygotowanie predefiniowanych profili konfiguracyjnych: „Lite”, „Standard”, „Full” – admin od razu wie, czego się spodziewać na słabszym hostingu.
Świat pod Purpura – planowanie pod agresywną optymalizację
Tworząc świat z myślą o Purpurze, można zakładać, że wielu adminów będzie celowo dusić spawny, cięć tikipów bloków i mocno ograniczać moby. Generator powinien to znosić bez psucia „grywalności”.
Praktyczne założenia przy projektowaniu świata pod Purpura:
klimat świata nie może opierać się wyłącznie na ilości mobów – część „życia” warto przerzucić na elementy środowiska (struktury, roślinność, efekty świetlne),
ważne struktury (miasta NPC, ruiny) nie powinny wymagać dużej stałej ilości mobów, by wyglądać „pełne”,
generator musi wyglądać sensownie nawet przy ściętych capach – puste, ale dobrze zaprojektowane tereny są akceptowalne, puste „nic” w losowej plątaninie bloków już nie,
logika świata powinna być możliwie niezależna od vanilla’owych zachowań mobów, bo te często są modyfikowane w purpur.yml.
Dobrym testem jest odpalenie świata na Purpurze z mocno zredukowanymi mobami (hostile + passive) i sprawdzenie, czy eksploracja nadal daje frajdę. Jeśli tak – generator dobrze dogaduje się z mentalnością Purpura.
Bezpieczne eksperymenty z generatorami na serwerach produkcyjnych
Oddzielny świat testowy a właściwa mapa
Największy błąd przy eksperymentowaniu z nowymi generatorami na Spigot/Paper/Purpur to testowanie ich od razu na głównym świecie. Znacznie bezpieczniej:
Utworzyć osobny świat testowy (inna nazwa folderu, inny generator w bukkit.yml lub pluginie).
Ograniczyć do niego dostęp tylko dla administracji i kilku testerów.
Przemierzyć duże dystanse w różnych kierunkach (lot elytrą, nether, end).
Obserwować timings i zachowanie serwera przy maksymalnie obciążonej generacji.
Dopiero gdy świat testowy zachowuje się stabilnie, można myśleć o użyciu tego samego generatora przy nowym sezonie albo nowym wymiarze na produkcji.
Stopniowe włączanie generatorów per wymiar
Przy przechodzeniu ze Spigota na Papera lub Papera na Purpura nie trzeba od razu zmieniać generatora wszystkiego naraz. Lepiej robić to stopniowo:
najpierw nowy Overworld (np. osobny świat typu „exploration” z custom-generatorem),
później dopiero Nether – z reguły mniejsza powierzchnia, ale większa intensywność ruchu (autostrady, farmy),
na końcu End – zwykle stosunkowo prosty generator, ale duże skoki obciążenia przy masowej eksploracji wysp.
Taki etapowy model pozwala szybciej zawrócić z błędnej drogi. Jeśli np. Nether z nowym generatorem zacznie zabijać TPS, można tymczasowo wrócić do vanilla, nie ruszając Overworldu.
Kontrola „szwów” między różnymi generatorami
Przy aktualizacjach wersji i migracjach między silnikami często pojawiają się „szwy” między starymi a nowymi chunkami: urwane góry, dziwne krawędzie biomów, płaskie ścianki w oceanach. Różne silniki radzą sobie z tym różnie:
Spigot – z powodu mniejszej ingerencji w generator vanilli różnice między wersjami MC często są wyraźniejsze.
Paper – lepiej znosi przejścia wersyjne, ale nadal przy dużym skoku (np. 1.16 → 1.18) pojawiają się radykalne przepaście.
Purpur – sam w sobie nie naprawia „szwów”, ale dodatkowe opcje spawnów i aktywności chunków mogą sprawić, że granice stają się mniej dokuczliwe (np. mniej mobów na starych terenach, więcej aktywności na nowych).
Przy dużych projektach pomaga:
wygenerowanie „bufora” nowymi chunkami za pomocą narzędzi typu WorldBorder czy Chunky,
oznaczanie granic starych terenów (np. ścieżki, tabliczki informacyjne, krótkie ogrodzenia), żeby gracze nie pytali co chwilę „skąd ta ściana?”,
rozsądne użycie pluginów do blendowania terenu – tylko w newralgicznych miejscach (spawn, główne szlaki), a nie na całej mapie,
planowanie nowych „hubów” eksploracyjnych dalej od starego świata, by ruch naturalnie odpłynął w stronę nowego generatora.
Przy przesiadce między Spigotem, Paperem i Purpurem dobrze działa prosty schemat: najpierw techniczne testy (timings, profilowanie przy locie elytrą), później oględziny wizualne szwów z perspektywy zwykłego gracza, na końcu dopiero kosmetyczne poprawki terenu. Odwrotna kolejność często kończy się tym, że poprawia się ładne klify, a pomija realne problemy z wydajnością chunków.
Dobrą praktyką jest też zamrożenie starych światów po dużej zmianie generatora – wyłączyć nowe generowanie poza ustaloną granicą, pozwolić tam tylko na budowanie i farmy. Eksplorację pchać wyłącznie w nowe wymiary lub świeże mapy. Na Spigocie ogranicza to kolejne „ząbki” na styku generatorów, na Paperze i Purpurze ułatwia utrzymanie stabilnego TPS przy rosnącej bazie graczy.
Najczęściej zadawane pytania (FAQ)
Czym się różni generowanie świata w Spigot, Paper i Purpur?
Sam kształt świata (biomy, góry, oceany, struktury) pochodzi głównie z kodu Mojang i jest bardzo podobny na wszystkich tych silnikach. Różnice dotyczą tego, jak serwer zarządza chunkami: kiedy je tworzy, ładuje, zapisuje i wyrzuca z pamięci oraz ile zadań wykona na tick.
Spigot dodaje lekkie optymalizacje i limity czasowe, Paper mocno usprawnia wydajność (asynchroniczne operacje, kolejkowanie i batchowanie chunków), a Purpur dokłada do tego bardzo rozbudowane opcje konfiguracji zachowania świata, mobów i struktur.
Który silnik lepiej radzi sobie z lagami przy generowaniu nowych chunków?
Najprostszy jest Spigot – generuje chunki głównie synchronicznie na głównym wątku. Przy intensywnej eksploracji (elytry, szybkie podróże w Netherze) może to powodować wyraźne przycinki, bo generowanie blokuje cały serwer.
Paper przenosi część pracy z chunkami do wątków asynchronicznych i przetwarza je w paczkach, więc znacznie lepiej znosi duże obciążenie. Purpur bazuje na optymalizacjach Papera, więc w praktyce zachowuje się podobnie lub lepiej, jeśli dobrze ustawisz jego zaawansowane opcje.
Czy Paper i Purpur zmieniają wygląd świata w porównaniu do Spigota?
Domyślnie nie. Wszystkie te silniki bazują na tym samym generatorze Mojang, więc układ biomów, jaskinie czy miasta w Endzie będą takie jak w vanilli. Różnice pojawiają się głównie w „zachowaniu” świata: jak szybko się generuje, jak długo chunki siedzą w pamięci, ile struktur/mobów jest aktywnych naraz.
Dopiero użycie niestandardowych generatorów (pluginy, datapacki, dedykowane światy RPG) może faktycznie zmienić sam wygląd terenu. Paper ma tu bogatsze API do integracji z takimi generatorami, Purpur nad tym nie przeszkadza i dorzuca dodatkową warstwę konfiguracji gameplayu.
Na jaki silnik postawić przy publicznym serwerze survival z dużą eksploracją?
Przy większej liczbie graczy i intensywnej eksploracji lepszym wyborem od gołego Spigota jest Paper albo Purpur. Dzięki asynchronicznej i zbatchowanej obsłudze chunków serwer mniej „zamiera”, gdy kilku graczy jednocześnie leci na elytrach w różne strony.
Jeśli zależy Ci głównie na wydajności i stabilności – Paper. Jeśli oprócz tego chcesz bardzo szczegółowo kontrolować balans świata (spawn mobów, struktury, zachowanie farm) – Purpur, który opiera się na Paperze, ale ma dużo więcej przełączników zachowań.
Jakie ustawienia Spigota najmocniej wpływają na obciążenie generowaniem świata?
Najbardziej odczuwalne są:
view-distance (bukkit.yml) – im większy zasięg widoku, tym więcej chunków musi być jednocześnie wygenerowanych i w pamięci,
simulation-distance – ile chunków wokół gracza jest aktywnie „tickowanych” (moby, farmy, wzrost roślin),
ticks-per.* (bukkit.yml) – częstotliwość spawnów mobów i innych akcji w świecie,
entity-activation-range / tracking-range (spigot.yml) – jak daleko od gracza serwer trzyma moby aktywne i śledzone.
Przy realnym serwerze praktyka jest prosta: obniż nieco view-distance, ustaw rozsądne simulation-distance i dopiero potem szukaj dalszych optymalizacji w pluginach czy zmianie silnika.
Czy przejście ze Spigota na Paper lub Purpur wymaga regeneracji mapy?
Nie. Ponieważ wszystkie te silniki bazują na tym samym generatorze Mojang, gotowa mapa z serwera Spigot będzie działała poprawnie na Paperze i Purpurze. Nowe chunki wygenerują się w tym samym stylu, więc gracze nie zobaczą nagłej zmiany kształtu świata na granicy starych i nowych terenów.
Przed migracją zrób jednak pełną kopię świata. Po zmianie silnika zwróć uwagę na konfigurację view-distance, simulation-distance i limitów mobów – na Paper/Purpur możesz pozwolić sobie na inne ustawienia niż na Spigocie.
Do czego praktycznie przydaje się większa kontrola nad generowaniem w Purpurze?
Purpur umożliwia precyzyjne dostrojenie zachowania świata: gęstości mobów i rud, działania farm opartych na mechanice chunków, intensywności populacji struktur czy reakcji świata na duże skupiska graczy. Przy serwerach z ekonomią lub customowym survivalem daje to sporą przewagę.
Przykład z praktyki: możesz osłabić pewne typy farm (np. XP lub żelaza), ograniczając spawny w konkretnych warunkach, bez ruszania samego układu biomów czy terenu. Świat wygląda „vanilla”, ale zachowuje się pod Twoje zasady.
Najważniejsze wnioski
Generator terenu (biomy, kształt gór, struktury) pochodzi z kodu Mojang, a forki Spigot/Paper/Purpur głównie zmieniają sposób, w jaki i kiedy ten generator jest uruchamiany oraz jak zarządzane są chunki.
Kluczowe różnice między silnikami dotyczą kolejkowania zadań chunków, pracy w wątkach (synchronicznie vs asynchronicznie), agresywności odśmiecania pamięci i wielkości partii chunków obrabianych na tick.
Spigot jest punktem wyjścia: praktycznie nie zmienia wyglądu świata względem vanilli, ale wprowadza limity czasowe na operacje chunków i lekkie optymalizacje IO, dzięki czemu zmniejsza ryzyko twardych lagów przy eksploracji.
Paper idzie dalej: mocniej optymalizuje wydajność, przerzuca część pracy nad chunkami poza główny wątek, korzysta z batchowania i daje rozszerzone API do generatorów, co pozwala lepiej kontrolować generowanie przy dużej liczbie graczy.
Purpur bazuje na Paperze i dodaje rozbudowaną konfigurację gameplayu oraz zachowania świata, mobów i struktur, co pozwala m.in. stroić balans ekonomii, trudność farm czy „reakcję” świata na gracza.
Różnice między silnikami najmocniej widać w praktyce przy szybkiej eksploracji (np. loty na elytrze) oraz przy dużym obciążeniu serwera – ten sam świat może wtedy wczytywać się płynnie albo powodować zamrożenia.
Admin ma realny wpływ na „oddychanie” mapy poprzez ustawienia takie jak view-distance, zasady trzymania chunków w pamięci czy pre-generację świata, co pomaga kontrolować wydajność, eksplorację i balans rozgrywki.
