Nowy pomysł na optymalizację serwera Survival

Rzecz, która przyszła mi do głowy wczoraj. Bardzo prosta myśl, której materializacja prosta nie będzie, jednak wciąż osiągalna przed startem V edycji. Jest to podejście do problemu lagów od zupełnie innej strony. Realizacja pomysłu mogłaby pozwolić na utrzymanie nawet 100 graczy przy 20 TPS.


Pomysł zakłada podzielenie głównego świata Survival na ćwiartki. Każda z ćwiartek świata działałby na osobnym (pod)serwerze. Co to oznacza? Obciążenie pochodzące z jednej ćwiartki świata nie będzie wpływać na jakość gry na pozostałych ćwiartkach. Przy założeniu, że gracze osiedlają się mniej więcej równomiernie na każdej ćwiartce to każda ćwiartka (podserwer) obsługiwałaby w szczycie 20-30 graczy. To liczba, przy której stabilne 20TPS nie stanowi problemu. 
Pozwoliłoby to również na zwiększenie liczby slotów na Survivalu i być może poluzowanie niektórych ograniczeń (m.in. tych dotyczących mobów na chunkach).

Kilka szczegółów dotyczących realizacji pomysłu:

- Spawn znajdowałby się blisko skrzyżowania granic ćwiartek, na ćwiartce nr 1.
- Granice ćwiartek byłyby nietykalne przez graczy. Gracz, który przekroczy granicę, przenoszony jest na ćwiartkę (podserwer) pasującą do aktualnych koordynatów gracza.
- Obraz sąsiedniej ćwiartki widziany z oddali przed przekroczeniem granicy nie będzie odpowiadał rzeczywistości prezentowanej po przeniesieniu gracza na wybraną ćwiartkę. Gracz po drugiej stronie będzie widział teren tak jakby był cały czas domyślnie wygenerowany i nieruszony.
- Przed wprowadzeniem takiej zmiany potrzebne będą modyfikacje działania teleportacji (MWCore, RandomTP), modyfikacje w pluginie od PvP, które uniemożliwią ucieczkę na inną ćwiartkę podczas walki (zostałoby to potraktowane jak wyjście z serwera i skończyłoby się śmiercią). Modyfikacje te wyeliminują niedogodności zauważalne obecnie podczas przebywania na bossach czy arenach.


Poniżej zobrazowanie pomysłu, wraz z oznaczeniem zielonym prostokątem możliwego położenia spawnu na świecie. Liczby oznaczają numery ćwiartek.






To na razie tyle. Czekam na Wasze przemyślenia dotyczące tego pomysłu

Pomysł na pewno bardzo pomógł by w płynności gry, i jest to bardzo ważne dla wielu graczy. Mam jednak kilka pytań.
1. Można przeczytać że przejście z jednej ćwiartki na drugą będzie w walce uważane za wyjście z serwera. Na pewno znajdą się gracze którzy będą to wykorzystywać i celowo uderzać innych by ci przeszli przez granicę. Czy dało by radę ustawić to ustawić tak by podczas walki gracz próbujący przekroczyć granic zostanie odrzucony na niewielką odległość? Zniwelowało by to oburzenie graczy z powodu przypadkowego/ustawionego przejścia przez granice
2. Załóżmy że jeden gracz ma działkę stojącą na granicy(jest to czyste założenie). Było wspomniane że granica będzie nietykalna dla graczy, przez co mogło by wyjść że dany gracz nie miał by dostępu do części swojej działki która leży na lini granicy. Oczywiście problem ten pojawił by się tylko podczas tej edycji, zakładając że ćwiartki będą od początku edycji V. Pytanie brzmi co by było zrobione w takim przypadku?

Pomysł na pewno bardzo pomógł by w płynności gry, i jest to bardzo ważne dla wielu graczy. Mam jednak kilka pytań.
1. Można przeczytać że przejście z jednej ćwiartki na drugą będzie w walce uważane za wyjście z serwera. Na pewno znajdą się gracze którzy będą to wykorzystywać i celowo uderzać innych by ci przeszli przez granicę. Czy dało by radę ustawić to ustawić tak by podczas walki gracz próbujący przekroczyć granic zostanie odrzucony na niewielką odległość? Zniwelowało by to oburzenie graczy z powodu przypadkowego/ustawionego przejścia przez granice
2. Załóżmy że jeden gracz ma działkę stojącą na granicy(jest to czyste założenie). Było wspomniane że granica będzie nietykalna dla graczy, przez co mogło by wyjść że dany gracz nie miał by dostępu do części swojej działki która leży na lini granicy. Oczywiście problem ten pojawił by się tylko podczas tej edycji, zakładając że ćwiartki będą od początku edycji V. Pytanie brzmi co by było zrobione w takim przypadku?

1. Jest to uwzględnione w moim pierwszym poście. Ucieczka na inną ćwiartkę w walce byłaby niemożliwa.
2. Nie zakładam, że to wejdzie w tej edycji, ale nawet gdyby tak się stało to nie moglibyśmy nic zrobić poza ewentualnym przeniesieniem fragmentów działek do których dostęp został utracony.

Pomysł wydaje się być dobry, tylko pytanie czy nie pojawią się podobne problemy z komendami, petami i homami taka jak jest w przypadku /warp bossy?

Ja też mam kilka pytań:

1. Czy granica ćwiartek byłaby jakoś oznaczona?
2. Co jeżeli ktoś przeleci Elytrą pomiędzy dwoma Ćwiartkami.
3. Jak bardzo nowi gracze byliby powiadomieni o istnieniu ćwiartek
4. Co jeżeli ktoś przeszedłby przez środek (czyli jednocześnie przez kilka ćwiartek)?

Pomysł wydaje się być dobry, tylko pytanie czy nie pojawią się podobne problemy z komendami, petami i homami  taka jak jest w przypadku /warp bossy?

Tak jak napisałem w pierwszym poście, niedogodności znane z przebywania na bossach nie będą obecne. Istniejące pluginy zostałyby tak przerobione, by działanie komend /home, /tpa, /warp i kilku innych nie sprawiało problemów.
Konfiguracja zwierzaków pozwala na użycie bazy MySQL, więc z nimi też nie będzie problemu.

1. Czy granica ćwiartek byłaby jakoś oznaczona?

Byłaby widoczna tak jak granica świata w grze:

 Co jeżeli ktoś przeleci Elytrą pomiędzy dwoma Ćwiartkami.

Nie wiem. Jedna z możliwych opcji to sprowadzenie na ziemię przed przeniesieniem.

Jak bardzo nowi gracze byliby powiadomieni o istnieniu ćwiartek

Po wprowadzeniu zmiany pojawi się ogłoszenie tak jak w przypadku innych zmian. Gracz będzie wiedział, że wkracza na inną ćwiartkę - otrzyma informację na czacie i/lub na środku ekranu po przeniesieniu.

 Co jeżeli ktoś przeszedłby przez środek (czyli jednocześnie przez kilka ćwiartek)?

Nie będzie to możliwe. Można przejść z jednej ćwiartki na drugą. Środek będzie nieosiągalny dla gracza - tak więc np. gracz znajdujący się na ćwiartce 2 chcący przejść na ćwiartkę 4 najpierw przejdzie na ćwiartkę 3 (lub 1), a dopiero potem na 4.

tak ale przynajmniej 3-10 claimowanych miedzy spawnem a granica(bezpieczniej aby cos bylo jednak bo nie jestem pewien co do miejsca spawnu) aby ludzie wychodzacy ze spawna i biegajacy po okolicy nie trafili na nią odrazu a jeśli chodzi o elytry to troche się martwie bo jestem staromodny i lubie latać elytrą

tak ale przynajmniej 3-10 claimowanych miedzy spawnem a granica(bezpieczniej aby cos bylo jednak bo nie jestem pewien co do miejsca spawnu)    aby ludzie wychodzacy ze spawna i biegajacy po okolicy nie trafili na nią odrazu a jeśli chodzi o elytry to troche się martwie bo jestem staromodny i lubie latać elytrą

1. Wstępnie zakładam odstęp nie mniejszy niż 500 kratek. 
2. Jak masz fajerwerki to nie jest problem, bez fajerwerek raczej nikt nie lata, a przynajmniej nie na dłuższe dystanse. Wystarczy ponownie wystartować po przejściu na nową ćwiartkę i lecisz dalej. Poza tym jeśli zostałoby trochę czasu w trakcie przygotowań (a jeśli nie to już później po wprowadzeniu) to dałoby się ogarnąć żeby po przeniesieniu na nową ćwiartkę gracz zachowywał wysokość i przebywał w stanie szybowania.

Jak dla mnie Pomysł z ćwiartkami ma wiele wad i mógłby mylić wielu innych graczy. Zamiast podzielać jeden świat na cztery części... dlaczego by nie zrobić 4 światów, do których przechodziłoby się portalem/warpem/inną komendą? Nie ma problemu z Elytrą, granicami i brakiem widoczności zmian na innej połowie.
Spawn mógłby być w 1 świecie, a komenda rtp teleportowałaby również na inne światy (jeżeli to możliwe), bo w poszukiwaniu miejsca na bazę większość osób wybiera ten sposób.

Jak dla mnie Pomysł z ćwiartkami ma wiele wad i mógłby mylić wielu innych graczy. Zamiast podzielać jeden świat na cztery części... dlaczego by nie zrobić 4 światów, do których przechodziłoby się portalem/warpem/inną komendą? Nie ma problemu z Elytrą, granicami i brakiem widoczności zmian na innej połowie.
Spawn mógłby być w 1 świecie, a komenda rtp teleportowałaby również na inne światy (jeżeli to możliwe), bo w poszukiwaniu miejsca na bazę większość osób wybiera ten sposób.

Ta opcja też ma swój problem:

Powielanie tych samych koordynatów przez światy, co miałoby skutki w działaniu pluginu LogBlock i tym samym detektora X-Ray ( i tak byłyby z nimi problemy, ale mniejsze przy realizacji w sposób opisany przeze mnie ). Żeby tego uniknąć kolejne światy trzeba by wygenerować na bardziej odległych koordynatach lub nazwać inaczej każdy ze światów na docelowym serwerze, co zajęłoby jednak mniej czasu niż próba rozwiązania problemów z pierwszego sposobu realizacji pomysłu. 

W obu przypadkach RandomTP musiałby przejść dużą modyfikację. Mogłaby pozostać opcja ze standardowym losowaniem na obszarze aktualnego świata, a obok mogłaby pojawić się opcja losowania, gdzie dodatkowo losowany byłby świat.

Zgodziłbym się na sposób realizacji pomysłu przedstawiony przez Ciebie.