Minecraft Server World Border & Kartengröße optimieren: Welt begrenzen ohne Spieler zu verlieren

# Minecraft Server World Border & Kartengröße optimieren: Welt begrenzen ohne Spieler zu verlieren

Eine der wirkungsvollsten — und am häufigsten übersehenen — Performance-Entscheidungen, die du als Minecraft-Serveradmin treffen kannst, ist die Kontrolle der Weltgröße. Eine unbegrenzte Welt bedeutet unbegrenzte Chunk-Generierung, unbegrenzten Festplattenverbrauch und unbegrenzte Lag-Spikes. Dennoch überspringen viele Admins diesen Schritt aus Angst, dass Spieler sich beschweren.

Dieser Guide zeigt dir, wie du eine World Border sinnvoll setzt, dein Terrain vorberechnest und deinen Server so konfigurierst, dass die Weltbegrenzung das Spielerlebnis verbessert statt es zu ruinieren.

---

Warum die Kartengröße direkt die Server-Performance beeinflusst

Jedes Mal, wenn ein Spieler neues Terrain erkundet, muss dein Server:

1. Neue Chunks generieren — Biom-, Terrain- und Struktur-Algorithmen ausführen
2. Diese Chunks auf die Festplatte schreiben — Disk-I/O-Spikes verursachen
3. Nahegelegene Chunks geladen halten — RAM verbrauchen
4. Entities und Block-Updates ticken — CPU-Zyklen aufwenden

Auf einem Survival-Server ohne World Border verteilen sich Spieler natürlich über tausende Blöcke. Nach einigen Monaten kann dein World-Ordner leicht 50–200 GB erreichen, das Laden von Chunks wird träge, und deine Karte ist weder vorberechnbar noch effizient sicherbar.

Das Setzen einer World Border ist der effektivste einzelne Schritt, um diese Kosten zu begrenzen.

---

Schritt 1: Eine sinnvolle World Border setzen

Der Vanilla-Minecraft-Befehl für die World Border ist bereits eingebaut:

/worldborder set <Durchmesser>
/worldborder center <x> <z>

Um zum Beispiel eine 10.000 × 10.000 Blöcke große Welt um den Spawn zu erstellen:

/worldborder center 0 0
/worldborder set 10000

Das gibt Spielern einen 5.000-Block-Radius zum Erkunden — mehr als genug für die meisten Survival-Server.

Empfohlene Größen nach Servertyp:

| Servertyp | Empfohlener Durchmesser |

|---|---|

| Survival SMP (klein) | 5.000 – 10.000 Blöcke |

| Survival SMP (groß) | 10.000 – 20.000 Blöcke |

| Skyblock / Minigames | Pro Insel/Arena, oft < 1.000 |

| RPG / Adventure | Benutzerdefiniert, fertige Kartengröße |

Die World Border wird in level.dat gespeichert und bleibt daher nach Neustarts bestehen.

---

Schritt 2: Welt mit Chunky vorgenerieren

Eine Border setzen bringt für die Performance wenig, wenn Spieler beim Erkunden noch immer Chunk-Generierung auslösen. Vorgenerierung des gesamten spielbaren Bereichs eliminiert Generierungs-Lag vollständig.

Das beste Tool dafür ist [Chunky](https://modrinth.com/plugin/chunky), ein Paper/Spigot-Plugin:

/chunky world world
/chunky center 0 0
/chunky radius 5000
/chunky start

Dies generiert alle Chunks innerhalb eines 5.000-Block-Radius (passend zu einer 10.000-Block-Border). Führe dies vor der Öffnung für Spieler durch.

Tipps zur Vorgenerierung:

• Führe sie außerhalb der Stoßzeiten oder vor dem Launch durch
• Nutze /chunky status zur Fortschrittsüberwachung
• Rechne mit 1–4 Stunden für eine 10.000-Block-Welt, je nach Hardware
• Die Generierung beansprucht viel CPU — nicht während aktiver Spieler durchführen

Nach der Vorgenerierung sinken Disk-Writes durch neue Chunks auf nahezu null, und Spieler erleben keinerlei Chunk-Lade-Ruckler beim Erkunden.

---

Schritt 3: Papers Chunk-Lade-Einstellungen anpassen

Selbst mit einer vorgenerierten Welt muss das *Laden* von Chunks von der Festplatte optimiert werden. In paper-world.yml (Paper 1.19+) oder config/paper-world-defaults.yml:

chunks:
  auto-save-interval: 6000          # Alle 5 Minuten speichern (Standard: 6000 Ticks)
  delayed-chunk-unloads:
    delay: 10s                       # Chunks kurz nach Spieler-Weggang geladen halten
  entity-per-chunk-save-limit:
    experience_orb: 16
    snowball: 8
    arrow: 16

In spigot.yml:

world-settings:
  default:
    view-distance: 8               # Von Standard 10 reduzieren falls nötig
    simulation-distance: 6         # Tickt Entities nur in Spielernähe

Und in server.properties:

view-distance=8
simulation-distance=6

Mit einer vorgenerierten Welt ist das Senken von view-distance auf 8 und simulation-distance auf 6 für Spieler meist nicht spürbar, reduziert aber den Chunk-RAM-Verbrauch deutlich.

---

Schritt 4: Nether und End ebenfalls begrenzen

Viele Admins setzen eine Border für die Überwelt und vergessen Nether und End. Da der Nether im Verhältnis 1:8 skaliert, können Spieler bei einer Überwelt-Border von 10.000 Blöcken theoretisch 1.250 Blöcke im Nether erreichen — ohne eigene Nether-Border aber auch weit mehr.

/execute in minecraft:the_nether run worldborder set 2500
/execute in minecraft:the_end run worldborder set 3000

Wenn du Multiverse-Core oder MyWorlds verwendest, hat jede Welt eigene Border-Einstellungen. Stelle sicher, dass du alle drei Dimensionen vorgenerierst.

---

Schritt 5: Welt- und Chunk-Wachstum langfristig überwachen

Selbst mit gesetzter Border wächst die Welt auf unerwartete Weise — Spieler bauen riesige Farmen, erzeugen Tausende von Entities und verteilen Tile Entities über die gesamte Karte. Die Border kontrolliert die *Größe*, nicht die *Dichte* des Inhalts.

Tools wie [PulseNode](https://pulsenode.tech) helfen dir, die Performance-Entwicklung deiner Welt im Zeitverlauf zu beobachten und dich zu warnen, wenn TPS-Einbrüche mit bestimmten Bereichen oder Tageszeiten zusammenhängen. Das ist besonders nützlich, um von Spielern gebaute Lag-Maschinen oder Chunk-Lade-Hotspots innerhalb deiner Welt zu erkennen.

---

Schritt 6: Purpur für besseres Border-Verhalten konfigurieren (optional)

Wenn du Purpur verwendest, gibt es in purpur.yml zusätzliche Quality-of-Life-Optionen für das Weltmanagement:

world-settings:
  default:
    gameplay-mechanics:
      disable-pillager-patrols: false
    entities:
      spawning:
        all-chunks-are-slime-chunks: false

Purpur unterstützt außerdem nativ per-Welt-Simulation-Distance, sodass du deine Ressourcenwelt mit geringerer Simulation-Distance betreiben kannst als deine Haupt-Survivalwelt — ohne zusätzliche Plugins.

---

Den Effekt messen

Hier siehst du, was du nach Implementierung von World Border und Vorgenerierung realistisch erwarten kannst:

| Kennzahl | Vorher | Nachher |

|---|---|---|

| World-Ordner-Größe | Unbegrenzt (50+ GB) | Vorhersehbar (5–15 GB) |

| Chunk-Gen-Lag-Spikes | Häufig | Eliminiert |

| Disk-I/O während des Spielens | Hoch | Nahezu null |

| Backup-Dauer | 30–60+ Min | 5–15 Min |

| RAM-Verbrauch (Chunks) | Wächst unbegrenzt | Stabiles Maximum |

Allein die Verbesserung der Backup-Geschwindigkeit rechtfertigt eine World Border für viele Admins, die sie noch nicht eingerichtet haben.

---

Zusammenfassung: Die World-Border-Optimierungs-Checkliste

• ✅ Passende World Border für deine Spielerzahl setzen
• ✅ Alle Chunks mit Chunky vorgenerieren, bevor Spieler beitreten
• ✅ Borders auch für Nether und End setzen
• ✅ view-distance und simulation-distance in spigot.yml und server.properties anpassen
• ✅ auto-save-interval und Chunk-Unload-Einstellungen in paper-world.yml konfigurieren
• ✅ Laufende Performance überwachen, um dichtebasierten Lag innerhalb der Border zu erkennen

Eine gut dimensionierte, vorberechnete Welt ist das Fundament jedes leistungsstarken Minecraft-Servers. Kombiniert mit Entity- und Tick-Optimierung gibt sie deiner Hardware die bestmögliche Chance, stabile 20 TPS zu halten — egal wie viele Spieler online sind.

---

*Du möchtest wissen, ob deine World-Border- und Chunk-Einstellungen wirklich helfen? [PulseNode](https://pulsenode.tech) überwacht TPS, Arbeitsspeicher und Performance-Trends deines Servers in Echtzeit — damit du den Unterschied deiner Optimierungen direkt siehst.*