Warum ein SCUM-Server ruckelt – und woran es meistens liegt

Zuerst messen, dann ändern

Fast jede Leistungssuche auf einem SCUM-Server beginnt falsch: Jemand liest von einem Wert, setzt ihn höher, es wird nicht besser, er setzt den nächsten. Nach einer Woche steht in der Konfiguration ein Dutzend Änderungen, von denen niemand mehr weiß, warum sie da sind.

Der einzige verlässliche Anfang ist eine Beobachtung: Wann genau ruckelt es, und wo? Abends bei voller Besetzung ist etwas anderes als immer an derselben Stelle. Beim Cargo Drop ist etwas anderes als beim Erkunden. Und „der Server ruckelt“ ist etwas anderes als „mein Ping ist hoch“ – Letzteres liegt an der Strecke zwischen Spieler und Server und lässt sich durch keine Einstellung beheben.

Dazu gehört eine zweite Nüchternheit: Wenn dein Server auf einer Hardware läuft, die er sich mit anderen teilt, ist ein Teil der Antwort außerhalb deiner Konfiguration. Das ist kein Grund, nichts zu tun – aber ein Grund, nicht alles zu erwarten.

Die Tickrate ist ein Ergebnis, keine Einstellung

Die Tickrate sagt, wie oft der Server die Welt in einer Sekunde durchrechnet. Sinkt sie, wird alles zäh: Treffer zählen später, Fahrzeuge zucken, Gegner bewegen sich stockend.

Es gibt zwei Werte dazu, eine untere und eine obere Grenze, ab Werk 5 und 30. Beide werden regelmäßig missverstanden.

Die obere Grenze ist kein Wunsch, sondern ein Deckel. Sie höher zu setzen erzeugt keine höhere Tickrate, wenn die Hardware sie ohnehin nicht liefert – sie erlaubt dem Server nur, mehr zu versuchen, und das kann die Lage verschlechtern.

Die untere Grenze ist eine Notbremse: Darunter fällt der Server nicht, sondern verlangsamt stattdessen die Spielwelt. Sie anzuheben klingt nach mehr Qualität und heißt in Wahrheit, dem Server eine Zusage abzuverlangen, die er unter Last nicht halten kann.

Mit anderen Worten: Die Tickrate ist das Thermometer, nicht die Heizung. Wer sie verbessern will, muss die Last senken, die sie drückt.

Was tatsächlich Last erzeugt

Ein SCUM-Server rechnet nicht „die Insel“, sondern eine Menge einzelner Objekte. Vier Gruppen machen praktisch die ganze Last aus.

Bauteile. Jede Wand, jedes Fundament, jede Tür ist ein Objekt, das verwaltet, gesichert und an Spieler in der Nähe übertragen werden muss. Eine Karte mit fünfzig großzügigen Basen kostet messbar Tickrate. Das ist der Grund, warum die Bauteilgrenze je Flagge keine Geschmacksfrage ist.

Fahrzeuge. Sie sind teurer als Bauteile, weil sie sich bewegen können und aus vielen Einzelteilen bestehen. Ein Server, auf dem die Höchstzahlen großzügig stehen und die Untätigkeitsfrist lang ist, sammelt über Wochen Fahrzeuge an, die niemand mehr benutzt.

Figuren. Puppen, bewaffnete NPCs und Tiere. Sie sind die teuerste Gruppe, weil jede von ihnen denkt, sich bewegt und Geräusche wahrnimmt. Genau hier greifen die Begegnungs-Einstellungen ein.

Liegende Gegenstände. Der leiseste Posten und der, den man am häufigsten übersieht. Alles, was Spieler fallen lassen, bleibt eine Weile liegen – und auf einem Server, der Monate läuft, sind das Zehntausende.

Die Virtualisierung: warum der Server überhaupt durchhält

Damit diese Mengen überhaupt tragbar sind, führt SCUM die meisten Objekte virtualisiert: Sie existieren als Eintrag, werden aber nicht laufend durchgerechnet. Erst wenn ein Spieler nah genug kommt, wird aus dem Eintrag ein echtes Objekt in der Welt.

Dieses System hat eigene Stellschrauben, und sie gehören zu den wirksamsten überhaupt. Der Takt sagt, wie oft geprüft wird, wer in der Nähe ist; das Zeitbudget begrenzt, wie lange der Server je Durchlauf dafür aufwenden darf; der Umkreis legt fest, wie weit dabei geschaut wird.

Der wichtigste Gedanke daran: Eine großzügige Virtualisierung bedeutet, dass mehr Dinge fertig sind, wenn jemand ankommt – aber auch, dass der Server dauernd mehr zu tun hat. Eine sparsame Virtualisierung entlastet ihn, lässt dafür aber sichtbar werden, wie Dinge erscheinen.

Fast alle Beschwerden über „Gegner, die aus dem Nichts auftauchen“ und „Kisten, die erst nach ein paar Sekunden da sind“ führen hierher – und nicht zu einem Fehler.

Die Reihenfolge, in der man sucht

1. Ruckelt es überall oder an einer Stelle? An einer Stelle heißt fast immer: dort steht zu viel. Eine sehr große Basis, ein Fahrzeuglager, ein Ort, an dem seit Monaten Sachen liegen.

2. Ruckelt es zu einer bestimmten Zeit? Abends bei voller Besetzung ist eine Frage der Spielerzahl. Immer zur selben Uhrzeit ist ein Hinweis auf etwas Geplantes – ein Neustart, eine Sicherung, ein Ereignis.

3. Ruckelt es bei Ereignissen? Dann ist es die Ballung: viele Spieler an einem Punkt, dazu die Gegner, die das Ereignis mitbringt. Das ist die anspruchsvollste Lage, die ein SCUM-Server kennt.

4. Wie viel steht auf der Karte? Bauteilgrenze je Flagge, Fahrzeug-Höchstzahlen, Verfallswerte. Das sind die Werte mit der größten Wirkung und der längsten Vorlaufzeit – sie helfen nicht heute, aber sie verhindern, dass es in einem Monat schlimmer ist.

5. Wie viele Figuren sind gleichzeitig unterwegs? Der Erwachensabstand der Zonen, die Mengen je Begegnung und die Obergrenzen für Puppen, NPCs und Tiere. Hier wirkt eine Änderung sofort.

6. Erst ganz zum Schluss die Virtualisierung. Sie ist wirksam, aber jede Änderung ist auch im Spiel sichtbar. Wer hier anfängt, tauscht Leistung gegen Erlebnis, ohne es zu merken.

Was nicht hilft

Die obere Tickrate anheben. Sie erlaubt mehr, sie erzeugt nichts.

Den erlaubten Höchstping senken. Das wirft Spieler mit schlechter Verbindung heraus und ändert nichts an der Last des Servers. Unter 100 schließt man halbe Kontinente aus.

Sichtweiten für Puppen, NPCs und Tiere senken. Das spart tatsächlich Übertragung – und führt zu genau der Beschwerde, dass Gegner erst auftauchen, wenn sie schon nah sind. Als Notmaßnahme brauchbar, als Dauerzustand unangenehm.

Die Gegnermenge global senken. Das macht die Insel leer, nicht schnell. Der Zonen-Erwachensabstand wirkt in dieselbe Richtung und lässt die Welt dort voll, wo tatsächlich jemand steht.

Den Sondermodus für wenige Spieler einschalten. Er tut das Gegenteil von dem, was hier gebraucht wird, und der Hersteller warnt in Großbuchstaben davor.

Das Netzwerkobjekt-Protokoll dauerhaft anlassen. Es beantwortet genau die Frage, welche Objekte die Last erzeugen – aber es schreibt auf einem belebten Server binnen Stunden mehrere Gigabyte. Einschalten, reproduzieren, ausschalten, auswerten.