Server! Wie funktioniert das?

[xsoh]

Guten Tag liebes Forum,

eine kurze Einleitung. Wir haben mit vier Mann bereits 1.5 Jahre Maps/Dungeons/Resourcepacks und die Minecraft Welt gebaut, um unser großes Projekt zu starten. Es ist ein MMORPG in Minecraft den wir Professionel aufziehen möchten und im deutschsprachigen Raum mehrere Hundert Spieler sehen wollen. Die finanziellen Mitteln sind bei vier berufstätigen ohne Probleme möglich.



Zu der Fassade gehören nun auch technische Dinge, wo wir leider nicht ganz im Bilde sind.

Wir haben vieles mit Ingame Commands und Scoreboards bereits eingestellt, um nicht bei jeder Kleinigkeit auf ein Plugin von dritten angewiesen zu sein und bei Minecraft Updates schnell nachziehen zu können.

Die eigentlichen Fragen wäre jetzt eigentlich..

Auf was müssen wir achten, wenn wir nicht wollen das der Server ab einer bestimmten Anzahl von Spielern laggt?

Was ist die bessere Wahl Bukkit, Spigot oder sogar PaperMC ?

Wir können wir am besten die Maps mit einander verbinden?



Mit freundlichen Grüßen

 

[xsoh]

Das komplett auszuschließen, ist nicht möglich. Der Minecraft-Server von Mojang und alles was darauf basiert (CraftBukkit und seine Forks, Forge/Sponge usw.) skaliert aufgrund fundamental schlechter Umsetzung nicht richtig. Er nutzt beispielsweise für die eigentliche Spielfunktionalität nur einen Thread. So liegen moderne CPUs größtenteils brach, da jede CPU irgendwann an die Grenzen ihrer Singlecore-Leistung kommt. Auch Dinge wie Chunkloading, -Generation, Redstone, Mob-KI und vieles mehr sind extrem ineffizient. Es wäre eine komplett neue oder zu großen Teilen veränderte Serversoftware nötig, um die tatsächliche Problemursache zu beheben. Das würde jedoch so viel Zeit und Geld kosten, dass es nur für die allerwenigsten Serverbetreiber infrage kommt.

Realistisch gesehen werdet ihr also ebenfalls mit Bukkit vorlieb nehmen müssen. Es ist aber durchaus möglich, den damit verbundenen Problemen aus dem Weg zu gehen und so viel Performance wie möglich herauszuholen:

1. Es nicht noch schlimmer machen. Plugins und andere Zusatzfunktionen so effizient wie möglich umsetzen, damit sie den Server nicht zusätzlich belasten.
2. Problematische Features einschränken, damit keine (absichtliche oder unabsichtliche) Überlastung durch die Nutzung der Spielmechaniken möglich ist. Dazu gehören beispielsweise Mob-Anzahlen, Redstoneschaltungen, TNT und ähnliches.
3. Die Slots auf eine vernünftige, der Serverleistung und dem Konzept angemessene, möglichst auch vorab getestete Zahl begrenzen. Unendlich viele Spieler wird der Server natürlich nie aushalten. Spieler kosten CPU-Leistung und Arbeitsspeicher; von beidem mehr je weiter sie tendenziell auseinander stehen.
4. Das Angebot des Servers nach Möglichkeit auf mehrere Minecraft-Instanzen ausweiten und diese dann mit BungeeCord verbinden. Es hat einen Grund, warum dieser Ansatz so beliebt ist: es ist meist der einzige Weg, den gesamten Server auf höhere Spielerzahlen zu skalieren. Je nach Serverkonzept und Hardware ist bei einem einzelnen Bukkit-Server nach 100-300 Spielern Schluss, egal was man tut.

Um bei Punkt 1 anzusetzen: Ich würde an deiner Stelle deine Umsetzung mit

noch einmal überdenken. Mit Befehlsblöcken, Redstone, den Vanilla-Befehlen und anderen "Mapmaker"-Features zu arbeiten, ist eine nette Spielerei, aber auch verglichen mit halbwegs brauchbar umgesetzten Plugins sehr ineffizient, instabil und von den Möglichkeiten her eingeschränkt. Auch bei Kleinigkeiten könnte sich da die höhere Belastung schnell bemerkbar machen.


Um das zu beantworten, hier erstmal eine kurze Begriffsklärung:
Bukkit: Programmierschnittstelle (API) zum Entwickeln von Plugins. An sich keine Serversoftware, man muss sie dafür erstmal implementieren.
CraftBukkit: Originale Implementation der Bukkit-API; gemoddete Version des Vanilla-Minecraft-Servers von Mojang, in die neben einigen Optimierungen und Bugfixes eben auch die API eingebaut wurde.
Spigot/PaperMC: Forks (von der ursprünglichen Software abgespaltene Varianten) von CraftBukkit bzw. Spigot (damit ist Paper ein "Fork vom Fork"), die ihrerseits dann wieder gegenüber der geforkten Software erweitert und optimiert wurden.

Tatsächlich gibt es auch bei jedem dieser Forks (relativ betrachtet) bemerkbare Verbesserungen in Sachen Performance. Somit ist Paper im Allgemeinen die beste Wahl, aber natürlich kein Allheilmittel; auch bei Nutzung von Paper sind für einen stabilen Betrieb mit vielen Spielern die oben genannten Punkt zu beachten.

Wie genau ist das gemeint? Wie man von einer Map auf die andere kommt? Worin besteht bei euch eine Map?

Ich danke dir vielmals für die ausführliche Antwort! Wir werden uns wohl noch mit der ganzen Technik auseinander setzen müssen.

Wir haben stark darauf geachtet abgesehen von Commandblöcken KEIN Redstone zu verbauen, da diese wie du angesprochen hast sehr hungrig sind. Des Weiteren sind die Commandblöcke auf der ganzen Map verteilt und nicht auf einem Fleck, da wir die Befürchtung hatten, dass diese nicht zuverlässig werden, wenn die Chunks nicht geladen sind... Das hat sich wohl leider erledigt mit den Commandblöcken, wenn diese nicht gut funktionieren auf einen Server.

Wir werden wohl noch eine Weile brauchen.

Wir haben eine sehr große Map, um "Open World Feeling" zu geben, aber möchten um Laggs zu vermeiden nicht alle Spieler gleichzeitig auf der selben Welt halten. Es gibt daher noch 3 weitere Maps die wir aktuell zu großen Dungeons gebaut haben.

Unser Ziel ist es nur ein ruckelfreies Gameplay zu bieten, auch bei 1000 Spielern. Sei es durch "Channels" oder sonstige Schnittstellen.

Liebe Grüße

 

[xsoh]

Die wären ineffizient, egal wo sie stehen. Commandblöcke werden über die Redstone-Logik ausgelöst, dafür müssen sie zusammen mit den anderen Blöcken im jeweiligen Chunk getickt werden, der Befehl wird geparst, der Code des entsprechenden Befehls wird mit den übergebenen Parametern ausgeführt, und erst dann passiert etwas. Das ist um mehrere Größenordnungen langsamer, als Programmcode eines Plugins direkt auszuführen.


Wie erklärt macht eine Minecraft-Instanz nahezu alles in einem Thread, daran ändern mehrere Welten nichts - die werden einfach nur sequenziell abgearbeitet. Lags können ab einer gewissen Spielerzahl nur vermieden werden, wenn die Last sinnvoll auf mehrere Instanzen auftgeteilt wird.

Das Ziel ist, die maximale Spielerzahl auf jeder Instanz im Bereich von 200 bis 300 zu halten. Das sollte mit einer leistungsstarken CPU und hinreichend optimierter Software ohne bemerkbare Lags möglich sein; die genaue Maximalzahl kann aber letztendlich nur durch Tests mit Sicherheit ermittelt werden.

Somit wäre es naheliegend, Welten, in denen voraussichtlich viele Spieler gleichzeitig spielen werden, auch auf einer separaten Instanz zu betreiben. Ein Teleport zwischen den unterschiedlichen Servern, die Synchronisierung von Spielständen, Tabliste und Chat sind über Plugins möglich, sodass aus Spielersicht kein Unterschied zum Betrieb einer Instanz mit mehreren Welten besteht.

Auf einer Minecraft-Instanz ist das ein Ding der Unmöglichkeit. Solche Zahlen machen die Nutzung mehrerer Instanzen in Verbindung mit einer Lösung wie BungeeCord zwingend erforderlich.

Vielen lieben Dank für deine ausführliche Antworten. Das hat gut weitergeholfen.

Aus dem Text zieh ich heraus das wir wohl für die Größe auch einen Root Server brauchen, wenn ich mich nicht Irre.
Wir haben aktuell einen Gameserver gemietet, das nur für das Bauen der Maps völlig ausreichend war. Das wird aber höchstwahrscheinlich nicht ausreichen, da wir dort nur mehr RAM kaufen können und wenig mit der Technik dahinter in Verbindung gehen.

 

[Chrisliebär❤️]

Man sollte bei dem Vorschlag von @LapisMC allerdings erwähnen, dass du auch eine kompetente Person brauchst, die sich dann um den Server kümmert. Genau dafür zahlst du bei einem Gameserver nämlich auch und das vergessen Viele gerne, wenn sie dir blind einen Rootserver empfehlen. Es gibt hier unzähliche Threads im Forum, in denen die neuen Besitzer eines Monsterservers plötzlich feststellen, dass man das nicht einfach zusammenklicken kann.

Wenn du so eine Person hast und das Projekt ernsthaft betreiben willst, dann hat @LapisMC auf jeden Fall recht. Andernfalls bleibt dir gar nicht viel Auswahl als ein Gameserver, wobei ich eh der Meinung bin, dass jedes ernsthafte Projekt irgendwann einen kompetenten Techniker braucht. Probleme kommen immer wieder und da muss sich schnell jemand drum kümmern, der nicht nur rät wo das Problem liegen könnte.