Calculadora de ticks de Minecraft

En Minecraft, a veces piensas el tiempo en segundos, mientras que el juego cuenta ticks por detrás. Una puerta de redstone se cierra dos pasos antes, una línea de hoppers se vacía más despacio de lo que esperabas, escribes un número en el comando /time set pero el sol no se queda donde querías. La mayoría de las veces el problema no es que el juego esté roto; es que estás tratando el tiempo real, el game tick y el redstone tick como si fueran lo mismo. Esta confusión ocurre mucho, sobre todo entre quienes empiezan con redstone.

El tiempo del juego no fluye como los segundos

El ritmo básico de Minecraft funciona con game ticks. En el juego vanilla, la velocidad objetivo es de 20 game ticks por segundo. Es decir:

$$
1 \text{ segundo} = 20 \text{ game tick}
$$

Un game tick equivale a 0,05 segundos.

$$
1 \text{ game tick} = 0{,}05 \text{ segundo}
$$

Sobre el papel, es bastante directo.

Si escribes 60 segundos, eso equivale a 1200 game ticks. 1 minuto también son 1200 game ticks. 10 minutos son 12000 game ticks. Que el ciclo completo de un día en Minecraft tenga 24000 ticks también resulta familiar por eso; en un mundo que funciona a 20 TPS, 24000 ticks son 20 minutos en la vida real.

Cuando bajan los TPS, las cosas cambian. 1200 game ticks duran 60 segundos a 20 TPS. Si el servidor cae a 10 TPS, esos mismos 1200 ticks se extienden esta vez a 120 segundos reales. Eso que miras en el juego pensando “¿por qué se retrasó?” a veces no viene del circuito, sino de que el servidor está sobrecargado.

La fórmula principal para calcular el tiempo es esta:

$$
\text{Game Tick} = \text{segundo} \times \text{TPS}
$$

Y la inversa se escribe así:

$$
\text{segundo} = \frac{\text{Game Tick}}{\text{TPS}}
$$

Para vanilla normalmente se toma TPS como 20. Si el servidor tiene lag y estás intentando entender el tiempo real de espera, debes escribir los TPS tal como son; de lo contrario, tu cálculo se quedará en lo teórico.

Esta diferencia molesta especialmente en granjas automáticas y circuitos de redstone. Un mecanismo que funciona bien en singleplayer puede comportarse de forma más lenta en un servidor concurrido. Porque el juego sigue necesitando la misma cantidad de ticks, solo que procesa esos ticks más despacio.

El redstone tick habla otro idioma

En Minecraft, la palabra “tick” por sí sola es un poco traicionera. Cuando alguien dice “pon un delay de 10 ticks”, primero hay que entender si habla de game ticks o de redstone ticks. En redstone, 1 redstone tick se considera igual a 2 game ticks. A velocidad vanilla, eso son 0,1 segundos.

$$
1 \text{ redstone tick} = 2 \text{ game tick}
$$

$$
1 \text{ redstone tick} = 0{,}1 \text{ segundo}
$$

10 redstone ticks equivalen a 20 game ticks. Pero 10 game ticks son solo 5 redstone ticks.

$$
\text{Game Tick} = \text{Redstone Tick} \times 2
$$

$$
\text{Redstone Tick} = \frac{\text{Game Tick}}{2}
$$

Si los mezclas, el tiempo del circuito se desvía al doble. En puertas de pistones, bloqueos de item sorters y cadenas de observers, esta diferencia se nota enseguida. La puerta se atasca donde debería cerrarse, un pistón no alcanza a agarrar un bloque, el sorter deja pasar demasiados ítems. Luego uno culpa al cableado. A veces el cableado es inocente.

Por eso el retraso del repeater se piensa aparte. Un repeater puede dar un retraso de 1, 2, 3 o 4 redstone ticks. Si quieres un retraso más largo, colocas repeaters en serie.

Supongamos que se quiere un retraso de 46 game ticks. Primero lo convertimos a redstone ticks:

$$
46 \text{ game tick} \div 2 = 23 \text{ redstone tick}
$$

Para construir 23 redstone ticks con repeaters hacen falta 5 repeaters completos de 4 ticks, y quedan 3 redstone ticks.

$$
23 = 5 \times 4 + 3
$$

Así que el montaje se lee así:

5 x 4-tick + 1 x 3-tick.

Aquí también entra en juego la lógica de redondear hacia arriba. Si el cálculo no cae exactamente en un redstone tick, es más seguro completar al valor superior en lugar de dar menos retraso. Al fin y al cabo, no existe una configuración de medio repeater. Es de 2 ticks o de 3 ticks. No hay punto intermedio.

La expresión práctica usada para repeaters es esta:

$$
\text{Repeater Redstone Tick} = \left\lceil \frac{\text{Game Tick}}{2} \right\rceil
$$

Después se encuentra la cantidad de repeaters de 4 ticks:

$$
\text{Cantidad de repetidores de 4 ticks} = \left\lfloor \frac{\text{Redstone Tick}}{4} \right\rfloor
$$

El retraso restante sale con el cálculo de módulo:

$$
\text{Restante} = \text{Redstone Tick} \bmod 4
$$

En redstone, estas pequeñas diferencias a veces se vuelven enormes. Sobre todo en mecanismos rápidos de pistones, una señal que dices “que llegue un tick más tarde” puede determinar si toda la estructura funciona o no. Esa es, en parte, la cara implacable del juego.

¿Por qué los valores de /time set parecen extraños?

Un día de Minecraft dura 24000 game ticks. El movimiento del sol, el ciclo día-noche y el comando /time set funcionan sobre esa línea. Cuando escribes 6000 en el comando, es mediodía. Alrededor de 12000 es el atardecer. 18000 puede considerarse medianoche.

Pero la lógica del reloj no empieza como en el mundo real a primera vista. El tick 0 se lee en el juego aproximadamente como las 06:00. Por eso 6000 ticks equivalen aproximadamente a las 12:00. Y 18000 ticks caen alrededor de las 00:00.

El cálculo del tick dentro del día mira el resto del valor introducido respecto a 24000:

$$
\text{Día Tick} = \text{Game Tick} \bmod 24000
$$

Es decir, aunque escribas 25000 ticks, el juego lo lee como el tick 1000 del nuevo día. Porque después de 24000 el ciclo vuelve a empezar.

El cálculo aproximado usado para su equivalente en hora es este:

$$
\text{Hora} = \left\lfloor \left(\frac{\text{Día Tick}}{1000} + 6\right) \bmod 24 \right\rfloor
$$

Para los minutos, el valor restante de ticks se multiplica por 0,06:

$$
\text{Minuto} = \text{round}((\text{Día Tick} \bmod 1000) \times 0{,}06)
$$

Para 6000 ticks, el cálculo da aproximadamente 12:00.

$$
\left(\frac{6000}{1000} + 6\right) \bmod 24 = 12
$$

Quienes hacen mapas lo usan mucho. También sirve al tomar capturas de pantalla. A veces incluso la dirección de la sombra cambia la escena; quienes fotografían dentro del juego lo saben, la luz de la mañana y la luz del mediodía no transmiten la misma sensación.

Esta lista corta es fácil de recordar:

Escribir 24000 o escribir 0 lleva al mismo resultado en la mayoría de los casos. El juego reinicia el ciclo.

Esperar a la velocidad del hopper es otro problema

El hopper es una de las piezas más silenciosas de Minecraft, pero también una de las que más cuellos de botella causa. Necesita 8 game ticks para transferir un ítem a otro inventario. A 20 TPS, eso equivale a 0,4 segundos.

$$
1 \text{ transferencia por hopper} = 8 \text{ game tick}
$$

$$
1 \text{ transferencia por hopper} = 0{,}4 \text{ segundo}
$$

La velocidad de transferencia por minuto de un solo hopper se calcula así:

$$
\text{Item / Minuto} = \frac{\text{TPS} \times 60}{8}
$$

Si TPS es 20:

$$
\frac{20 \times 60}{8} = 150
$$

Es decir, un solo hopper mueve aproximadamente 150 ítems por minuto.

Imaginemos un lote de 400 ítems. Primero encontramos su equivalente en ticks:

$$
400 \times 8 = 3200 \text{ game tick}
$$

Luego lo convertimos a segundos:

$$
\frac{3200}{20} = 160 \text{ segundo}
$$

160 segundos son 2 minutos y 40 segundos.

Ese número puede parecer pequeño, pero no se siente tan pequeño cuando esperas frente al cofre mientras la granja funciona. Sobre todo si el sistema produce 300 ítems por minuto y tú intentas recogerlos con un solo hopper, el atasco es inevitable. Los ítems se acumulan, luego se forma una cola de hoppers, y después empiezas a ver ítems en el suelo.

Ver ítems en el suelo es la forma que tiene el sistema de almacenamiento de decir: “no doy abasto”.

En el cálculo de hoppers no conviene caer en un error: esta velocidad es para un solo hopper. Si varias líneas funcionan en paralelo, el flujo aumenta. Si una cadena de hoppers es muy larga, cada transferencia añade su propio retraso. Si hay un canal de agua, una línea de droppers, un chest minecart o un sistema de transporte con mods, el tema cambia. Este cálculo sirve más bien para leer rápido el comportamiento vanilla de los hoppers.

Aquí los TPS también afectan el tiempo real. Mientras 400 ítems se transfieren en 160 segundos a 20 TPS, a 10 TPS se alargan a 320 segundos.

$$
\frac{3200}{10} = 320 \text{ segundo}
$$

La cantidad de ticks dentro del juego es la misma, pero el tiempo real de espera se duplica. A veces esa es la razón por la que en un servidor alguien pregunta “¿se rompió el hopper?”. No se rompe, simplemente el mundo se ha vuelto pesado.

¿Qué modo debe usarse y cuándo?

Si tienes la pregunta “¿cuántos segundos?”, una conversión directa basta. Por ejemplo, si dices “que la puerta se cierre después de 5 segundos”, 5 segundos equivalen a 100 game ticks.

$$
5 \times 20 = 100 \text{ game tick}
$$

Saber esto es suficiente para command blocks o trabajos simples de retraso.

Si estás construyendo un circuito de redstone, mira el retraso del repeater. Porque lo que colocarás en el juego no son segundos, sino ajustes de repeater. Un retraso de 2 segundos equivale a 40 game ticks, es decir, 20 redstone ticks.

$$
2 \times 20 = 40 \text{ game tick}
$$

$$
40 \div 2 = 20 \text{ redstone tick}
$$

20 redstone ticks pueden construirse con 5 repeaters de 4 ticks.

Para el tiempo de Minecraft necesitas el valor de /time set. Si quieres que sea mediodía, usa 6000; si quieres que sea medianoche, alrededor de 18000. Aquí no se habla de segundos, sino de la posición del tick dentro del día.

En el lado del hopper, la pregunta es completamente distinta: “¿Cuánto tardan en fluir tantos ítems?”. Tiene más sentido escribir la cantidad de ítems y ver el tiempo. Se usa especialmente para entender si un solo hopper basta en las salidas de granjas automáticas.

La elección de la unidad importa. Aunque game tick, redstone tick, segundo, minuto, transferencia de hopper y día de Minecraft parezcan distintas caras de lo mismo, en el juego se usan para decisiones diferentes. Puedes pensar en los segundos como el tiempo de la persona, en el game tick como el tiempo del juego y en el redstone tick como el tiempo del circuito.

Es un poco aproximado, pero funciona.

Si el cálculo es correcto, ¿por qué el juego se comporta distinto?

Aunque el cálculo de ticks sea correcto, el resultado dentro del juego puede no coincidir exactamente. Hay varias razones.

La primera es TPS. Si el servidor no funciona a 20 TPS, el tiempo real se alarga. Hasta que el juego diga “han pasado 1200 ticks”, puede que hayas esperado más de 60 segundos en el mundo real. El comando, el redstone o el cálculo del hopper no se rompen; simplemente terminan más tarde.

La segunda es la carga de chunks. Si un chunk no está cargado, algunos sistemas allí no funcionan como esperas. Línea de hoppers, granja, reloj de redstone; todo depende de que el mundo permanezca activo. Un mecanismo que dejaste lejos no siempre seguirá funcionando tal como lo imaginas.

La tercera es el orden de actualización de redstone. Redstone no es solo un cálculo de tiempo. También entran en juego de dónde viene la señal, qué bloque se actualiza primero, la orientación del repeater, el comportamiento del comparator y qué ve el pistón en cada momento. A veces 4 ticks es el valor correcto, pero la disposición del circuito es incorrecta.

También están las diferencias entre Java y Bedrock. Aunque la mayoría de las proporciones básicas de tiempo parezcan iguales, las diferencias de versión en el comportamiento de redstone pueden dar muchos dolores de cabeza. No es sorprendente que un circuito de Java visto en YouTube no funcione igual al construirlo en Bedrock.

La calculadora no hace magia en este punto. Te da limpia la parte del tiempo. El resto lo determina la disposición física del juego.

Algunos hábitos pequeños pero útiles

Primero aclara a qué “tick” se refiere la palabra. ¿Game tick o redstone tick? Entrar al cálculo de un circuito sin preguntar eso es un poco como colocar bloques sin medir.

En líneas largas de hoppers, no confíes solo en la velocidad de un hopper. Si una granja produce más de 150 ítems por minuto, una sola línea acabará atascándose en algún punto. Si hacen falta dos líneas, si conviene más un flujo de agua o si hay que montar un reloj de droppers, eso ya depende del diseño.

En los comandos /time set, en lugar de memorizar números, conoce unos pocos puntos clave: 0 mañana, 6000 mediodía, 12000 tarde, 18000 medianoche. El resto se ajusta a ojo. Minecraft, al fin y al cabo, también es un juego de estimación visual.

En el retraso de repeaters, pensar en bloques de 4 ticks ayuda. Primero convierte el retraso a redstone ticks y luego divídelo en partes de 4. Si queda 1, 2 o 3, colocas un repeater más al final.

Y no olvides por completo los TPS. En un mundo de un solo jugador, la suposición de 20 TPS suele bastar. Si las cosas empiezan a comportarse raro en un servidor, mirar primero los TPS suele ser más inteligente. Antes de desmontar la línea de redstone, quiero decir.