Temporizadores en eventos Minecraft: qué pasa cuando baja el TPS

Antes de encargar un temporizador para un evento de Minecraft, acuerda qué hace avanzar el tiempo: los ticks del servidor, el tiempo real transcurrido o una pausa controlada por la organización. Si el plazo debe seguir el tiempo real, el plugin debe calcular lo que queda a partir del reloj elegido, en vez de restar un segundo cada vez que se ejecuta una tarea repetitiva. Después, ensaya el lag, las pausas y la recuperación antes de aceptar la entrega.

Esta guía sirve para definir un plugin de eventos en Paper. Incluye un ejemplo de especificación, no una implementación probada. Está pensada para torneos y series de creadores que deben coordinar la partida con un horario de producción y necesitan reglas claras ante las interrupciones.

Decide qué significa «cinco minutos»

El planificador de Paper utiliza ticks. Su documentación explica que, al bajar el TPS, una espera en ticks tarda más; también advierte de que ejecutar una tarea fuera del hilo principal no hace seguro el acceso al mundo. Consulta la guía de planificación de Paper.

Imagina una ronda de 6.000 ticks. A 20 TPS constantes dura 300 segundos; a 10 TPS constantes, 600. Son ejemplos aritméticos, no mediciones de un servidor. Que esa ampliación sea aceptable depende del reglamento. Producción puede necesitar una franja fija de emisión, mientras que el diseñador del juego puede querer una cantidad fija de simulación.

Escribe la regla antes de elegir una biblioteca:

Necesidad del evento	Regla que debes acordar
La ronda avanza con la simulación del juego	Contar ticks y explicar que la duración real puede aumentar.
Las inscripciones cierran en un instante anunciado	Guardar un plazo absoluto y definir qué reloj manda.
La ronda dura cinco minutos reales, sin contar las pausas del equipo	Medir tiempo transcurrido y registrar expresamente las pausas y reanudaciones.

«Tiempo real» no resuelve qué hacer durante una interrupción. Decide por separado si el tiempo con el servidor apagado consume el plazo y si un episodio grave de lag obliga al árbitro a pausar o anular la ronda.

Separa la cuenta atrás de la decisión

El marcador muestra el temporizador; no debe ser su única fuente de verdad. Pide un estado de ronda común que consulten los comandos del equipo, la interfaz y las comprobaciones del juego. Actualizar el marcador con menos frecuencia no debería alargar la partida de forma implícita.

Para un cierre fijo, una regla de diseño útil es calcular el tiempo restante como la diferencia entre el plazo y la hora actual, mostrando como mínimo cero. El desarrollador debe concretar el reloj, el redondeo y cómo aplicar el resultado al juego de forma segura. Redondear hacia abajo y mostrar cero no debe cerrar la ronda antes de su vencimiento real.

Si una actualización de pantalla llega tarde, debe mostrar el tiempo que queda entonces, en lugar de reproducir cada segundo perdido. Decide qué avisos se pueden omitir. Un mensaje de «quedan diez segundos» después del cierre confunde a los participantes, aunque su tarea pendiente acabe ejecutándose.

Exige también que el código que acepta una inscripción o puntuación consulte el estado y el tiempo autorizados. Una tarea de cierre retrasada no debe ser la única barrera contra acciones nuevas fuera de plazo. Especifica si cuenta el instante en que el servidor procesa la acción; aceptar una hora enviada por el cliente exigiría diseñar aparte cómo se verifica su fiabilidad.

Define qué ocurre al reiniciar

System.nanoTime() de Java mide tiempo transcurrido dentro de una JVM; no es una fecha reutilizable tras reiniciar. La diferencia está documentada en la API System de Java.

Pide que se explique qué se guarda: identificador de ronda, estado y datos temporales necesarios para la recuperación acordada. Guardar solo el número que aparece en el marcador deja sin resolver decisiones importantes.

Si el plazo continúa durante la parada, una fecha absoluta puede servir para recuperarlo. Concreta la referencia horaria y el tratamiento de las correcciones del reloj. Si la recuperación debe quedar pausada, el equipo puede necesitar una duración restante guardada y una aprobación expresa para reanudar. Documenta cuánto detalle temporal puede perderse ante una caída brusca; un guardado periódico no tiene por qué capturar el último instante.

Ninguna de esas reglas devuelve automáticamente la equidad a una partida. Si los participantes se han perdido parte de una ronda competitiva, la organización debe decidir si se reanuda, se cancela o se repite. El programa debe hacer visible esa decisión sin inventar tiempo adicional de juego.

Recorre un ejemplo de producción

Supón que las inscripciones cierran en un instante UTC registrado. La cuenta atrás es informativa y cada solicitud comprueba el plazo antes de aceptarse. Si el servidor vuelve a arrancar después del vencimiento, las inscripciones siguen cerradas. El equipo solo puede ampliarlas mediante una acción autorizada que deje constancia del nuevo plazo y su motivo.

Asigna un identificador a cada revisión. Una tarea programada para el plazo anterior debe comprobar que sigue correspondiendo a la revisión activa antes de cambiar el estado. De lo contrario, podría cerrar las inscripciones después de que el equipo las haya ampliado deliberadamente. Ensaya esa secuencia concreta, además de la cuenta atrás inicial.

Ningún reloj hace que un servidor bloqueado procese el juego inmediatamente. Acuerda cómo se muestra el retraso y qué debe hacer el equipo si el evento no puede continuar con fiabilidad. Calcular bien el plazo evita que la cuenta atrás acumule desfase; no garantiza disponibilidad ni tiempos de respuesta.

Pide pruebas en un ensayo aislado

Añade estas comprobaciones propuestas a los criterios de aceptación del plugin. No se han ejecutado para este artículo. Utiliza un entorno de pruebas y un reloj o una ejecución de tareas controlados; no provoques lag en un evento real.

1. Ejecutar la ronda normalmente y comparar plazo previsto, cuenta atrás y cambio efectivo de estado.
2. Retrasar las tareas del temporizador y verificar que la regla de tiempo real no añade a la ronda el intervalo perdido.
3. Procesar una solicitud después del plazo, pero antes de una tarea de cierre retrasada, y comprobar su rechazo según la regla acordada.
4. Pausar y reanudar, verificando que solo se excluye el intervalo de pausa previsto.
5. Reiniciar antes y después del vencimiento, incluyendo una parada brusca si está en el alcance. Comprobar la recuperación y el límite de pérdida de datos documentados.
6. Ampliar o cancelar una ronda con una tarea antigua pendiente. Verificar que esta no revierte el nuevo estado.
7. Simular una corrección horaria en el reloj de pruebas y contrastar el resultado con lo especificado.

Conserva versiones, identificadores de ronda, regla temporal, resultados esperados y horas observadas. Acuerda el retraso admisible para ese evento; esta lista no ofrece un umbral universal. Incluye la pantalla del equipo y los pasos de recuperación en el ensayo técnico del evento.

Para encargar desarrollo de Minecraft a medida, lleva las reglas de las rondas, el horario de producción, la política de interrupciones y las pruebas de aceptación. Mineando presupuesta cada proyecto de pago según su alcance; el mantenimiento y la cobertura en directo se acuerdan por separado.