Minecraft-Event-Timer: Was passiert bei sinkenden TPS?

Legt bei einem Timer für euer Minecraft-Event zuerst fest, wodurch die Zeit fortschreitet: durch Serverticks, tatsächlich verstrichene Zeit oder eine von der Organisation gesteuerte Pause. Soll eine Frist der realen Zeit folgen, muss das Plugin die Restdauer anhand der gewählten Uhr berechnen, statt bei jedem Aufruf einer wiederkehrenden Aufgabe eine Sekunde abzuziehen. Prüft anschließend Lag, Pausen und Wiederanlauf vor der Abnahme.

Dieser Leitfaden hilft bei der Beauftragung eines Event-Plugins für Paper. Das Rundenbeispiel ist eine vorgeschlagene Spezifikation, keine getestete Implementierung. Es richtet sich an Veranstalter von Turnieren und Creator-Serien, die Spielablauf und Produktionsplan miteinander abstimmen müssen.

Klärt, was „fünf Minuten“ bedeutet

Papers Scheduler verwendet Ticks. Die Dokumentation erklärt, weshalb eine Wartezeit in Ticks bei sinkenden TPS länger dauert. Sie warnt außerdem vor unsicheren Weltzugriffen außerhalb des Hauptthreads. Grundlage ist die Paper-Dokumentation zum Scheduling.

Nehmen wir eine Runde mit 6.000 Ticks an: Bei konstanten 20 TPS dauert sie 300 Sekunden, bei konstanten 10 TPS dagegen 600 Sekunden. Das sind Rechenbeispiele, keine Servermessungen. Ob diese Verlängerung zulässig ist, entscheidet das Regelwerk. Die Produktion kann einen festen Sendeplatz benötigen, während das Spieldesign eine bestimmte Menge simulierter Spielzeit vorsieht.

Schreibt die Regel auf, bevor ihr eine Timer-Bibliothek auswählt:

Anforderung	Zu vereinbarende Zeitregel
Die Runde folgt der Spielsimulation	Ticks zählen und die mögliche längere Echtzeitdauer erklären.
Die Anmeldung endet zu einem angekündigten Zeitpunkt	Einen absoluten Endzeitpunkt speichern und die maßgebliche Uhr festlegen.
Die Runde dauert fünf reale Minuten ohne Teampausen	Verstrichene Zeit messen und Pause sowie Fortsetzung ausdrücklich erfassen.

„Echtzeit“ beantwortet noch nicht alle Fragen zu Unterbrechungen. Legt zusätzlich fest, ob eine Serverabschaltung Restzeit verbraucht und ob ein Schiedsrichter bei starkem Lag die Runde pausieren oder für ungültig erklären soll.

Trennt Anzeige und Entscheidung

Das Scoreboard stellt den Timer dar; es sollte nicht selbst die maßgebliche Zeitquelle sein. Verlangt einen gemeinsamen Rundenzustand, den Teambefehle, Anzeige und Spielprüfungen verwenden. Seltenere Bildschirmaktualisierungen dürfen die Runde nicht unbemerkt verlängern.

Für einen festen Endzeitpunkt lautet eine nützliche Entwurfsregel: Restzeit ist Endzeitpunkt minus aktuelle Zeit, wobei die Anzeige nicht unter null fällt. Der Entwickler muss Uhr, Rundung und sichere Anwendung im Spiel konkretisieren. Eine auf null abgerundete Anzeige darf die Runde nicht vor dem tatsächlichen Ablauf schließen.

Kommt eine Anzeigeaktualisierung verspätet, soll sie die jetzt verbleibende Zeit zeigen, statt jede verpasste Sekunde nachzuholen. Entscheidet, welche Ansagen entfallen dürfen. „Noch zehn Sekunden“ nach dem Rundenende verwirrt Spieler, auch wenn die ursprünglich geplante Aufgabe irgendwann ausgeführt wird.

Auch die Verarbeitung einer Anmeldung oder Wertungsaktion muss den maßgeblichen Zustand und Zeitpunkt prüfen. Eine verspätete Abschlussaufgabe darf nicht die einzige Sperre gegen neue Aktionen nach Fristende sein. Definiert beispielsweise, ob der Verarbeitungszeitpunkt auf dem Server zählt. Vom Client übermittelte Zeitangaben zu akzeptieren würde ein eigenes Konzept zur Prüfung ihrer Vertrauenswürdigkeit verlangen.

Vereinbart das Verhalten nach einem Neustart

Javas System.nanoTime() misst verstrichene Zeit innerhalb einer JVM. Der Wert ist kein Kalenderzeitpunkt, den man nach einem Neustart weiterverwenden kann. Diese Abgrenzung beschreibt die Java-API für System.

Lasst erklären, welche Daten gespeichert werden: Rundenkennung, Zustand und die für das vereinbarte Wiederanlaufverfahren nötigen Zeitinformationen. Nur die angezeigte Zahl zu speichern lässt wesentliche Entscheidungen offen.

Läuft die Frist während einer Abschaltung weiter, kann ein absoluter Zeitstempel den Wiederanlauf unterstützen. Legt Zeitreferenz und Umgang mit Uhrkorrekturen fest. Soll die Runde hingegen pausiert wiederhergestellt werden, braucht das Team möglicherweise eine gespeicherte Restdauer und eine ausdrückliche Freigabe zur Fortsetzung. Dokumentiert, welche Zeitinformation bei einem abrupten Absturz verloren gehen kann. Eine regelmäßige Speicherung erfasst nicht zwangsläufig den letzten Moment.

Keine dieser Regeln stellt automatisch einen fairen Wettkampf wieder her. Haben Teilnehmer einen Teil der Runde verpasst, muss die Organisation über Fortsetzung, Abbruch oder Wiederholung entscheiden. Die Software soll diese Entscheidung sichtbar unterstützen, ohne stillschweigend zusätzliche Spielzeit einzuräumen.

Spielt einen Produktionsfall durch

Angenommen, die Anmeldung endet zu einem gespeicherten UTC-Zeitpunkt. Der Countdown informiert die Teilnehmer; jede Anmeldeverarbeitung prüft vor der Annahme die Frist. Startet der Server erst nach deren Ablauf wieder, bleibt die Anmeldung geschlossen. Das Team darf sie nur durch eine berechtigte Änderung verlängern, die neuen Endzeitpunkt und Begründung festhält.

Gebt jeder Änderung eine Versionskennung. Eine für den alten Endzeitpunkt geplante Aufgabe muss vor einer Zustandsänderung prüfen, ob sie noch zur aktiven Version gehört. Sonst könnte sie die Anmeldung schließen, obwohl das Team sie inzwischen bewusst verlängert hat. Prüft genau diese Abfolge zusätzlich zur ursprünglichen Countdown-Demonstration.

Keine Uhr kann einen blockierten Server dazu bringen, Spielaktionen sofort zu verarbeiten. Vereinbart, wie Verspätungen angezeigt werden und wie das Team vorgeht, wenn das Event nicht zuverlässig fortgesetzt werden kann. Eine korrekte Fristberechnung verhindert das schleichende Verlängern des Countdowns; sie garantiert weder Verfügbarkeit noch Reaktionszeiten.

Verlangt Nachweise aus einer getrennten Probe

Ergänzt die Abnahmekriterien für das Plugin um die folgenden vorgeschlagenen Prüfungen. Für diesen Artikel wurden sie nicht ausgeführt. Nutzt eine Testumgebung mit kontrollierbarer Uhr oder Aufgabenplanung, statt ein laufendes Event absichtlich zu stören.

1. Führt die Runde normal aus und vergleicht geplante Frist, Anzeige und tatsächlichen Zustandswechsel.
2. Verzögert Timer-Aufgaben. Die Echtzeitregel darf das verpasste Intervall nicht zusätzlich an die Runde anhängen.
3. Verarbeitet eine neue Anfrage nach Fristende, aber vor einer verspäteten Abschlussaufgabe. Prüft die vereinbarte Ablehnung.
4. Pausiert und setzt fort. Nur das vorgesehene Pausenintervall darf aus der Laufzeit herausgerechnet werden.
5. Startet vor und nach Ablauf neu, einschließlich abruptem Stopp, sofern vereinbart. Prüft Wiederanlauf und dokumentierte Grenzen eines Datenverlusts.
6. Verlängert oder storniert eine Runde, während eine alte Aufgabe noch aussteht. Diese darf den neuen Zustand nicht rückgängig machen.
7. Simuliert eine Uhrkorrektur mit der Testuhr. Vergleicht das beobachtete Verhalten mit der vorher festgelegten Erwartung.

Haltet Release-Versionen, Rundenkennungen, Zeitregeln, erwartete Ergebnisse und beobachtete Zeitpunkte fest. Vereinbart die zulässige Verspätung für euer konkretes Event; diese Checkliste gibt keinen universellen Grenzwert vor. Nehmt Teamansicht und Wiederanlaufschritte in die technische Eventprobe auf.

Für individuelle Minecraft-Entwicklung bringt ihr Rundenregeln, Produktionsplan, Unterbrechungskonzept und Abnahmefälle mit. Mineando kalkuliert kostenpflichtige Projekte nach dem vereinbarten Umfang; Wartung und Live-Betreuung werden gesondert abgestimmt.